Help with automated stitching (for scanned images)
Ognjen Bezanov
I've been very happy with Hugin (and tools) so far, while dealing with
photo stitching of holiday panoramas.
Now I need to see if I can make use of it for a non-standard job.
I am trying to stitch together a poster that was scanned in sections. As
these are not photo's they don't have any lens aberrations that need to
be corrected, or a Field of view/focal length.
The hugin wiki had a nice article on how to do this with hugin
(http://hugin.sourceforge.net/tutorials/scans/en.shtml) and with that
and some other online sources I was able to come up with the following
commands to auto-stitch:
autopano-sift-c --projection 0,10 project.pto ./*.tiff
celeste_standalone -i project.pto -o project.pto
ptoclean -v --output project.pto project.pto
autooptimiser -a -l -s -o project.pto project.pto
nona -m TIFF_m -o project project.pto
enblend -w -o project.tif project*.tif
While this works, the resulting file is horribly warped. How can I
disable the attempts to warp the image and just have it stitch plainly?
Am I missing some commands/arguments to do this?
Unless I'm mistaken stitching without having to make these corrections
should be easier? Just a plain match of blocks?
Any help appreciated! Thanks!
Yuval Levy
On October 20, 2010 07:09:58 pm Ognjen Bezanov wrote:
> I am trying to stitch together a poster that was scanned in sections.
...
> The hugin wiki had a nice article
the article was written before the introduction of the mosaic mode. Have you
tried mosiac mode (new in Hugin 2010.2.0) [0]?
Yuv
[0] http://hugin.sourceforge.net/tutorials/Mosaic-mode/en.shtml
James Legg
On Thu, 2010-10-21 at 00:09 +0100, Ognjen Bezanov wrote:
> I am trying to stitch together a poster that was scanned in sections.
>
> I was able to come up with the following
> commands to auto-stitch:
>
> autopano-sift-c --projection 0,10 project.pto ./*.tiff
> celeste_standalone -i project.pto -o project.pto
> ptoclean -v --output project.pto project.pto
>
> autooptimiser -a -l -s -o project.pto project.pto
>
> nona -m TIFF_m -o project project.pto
> enblend -w -o project.tif project*.tif
>
> While this works, the resulting file is horribly warped. How can I
> disable the attempts to warp the image and just have it stitch plainly?
> Am I missing some commands/arguments to do this?
It needs rectilinear output projection, but it is possible autooptimiser
may have picked another projection when you used -s. Try
pano_modify --projection=0 -o project.pto project.pto
after autooptimiser.
The mosaic features are unnecessary for images from a flatbed scanner,
since the angle to the image plane never changes. They help if shooting
something flat freehand with a camera however.
-James
Ognjen Bezanov
Thanks for the tip! One thing though, I don't seem to have pano_modify
on my installation. Where can I find this program/script?
Thanks,
Ognjen
Ognjen Bezanov
to get it. Now I have a new issue.
after setting projection to rectilinear, nona fails with "caught
exception: std::bad_alloc"
This seems to happen with or without the addition of pano_modify.
Any ideas what might be causing this? Could there be a bugin the latest
version of Hugin?
James Legg
> Never mind, I found out that I had to update hugin to 2010.2.0 in order
> to get it. Now I have a new issue.
>
> after setting projection to rectilinear, nona fails with "caught
> exception: std::bad_alloc"
>
> This seems to happen with or without the addition of pano_modify.
> Any ideas what might be causing this? Could there be a bugin the latest
> version of Hugin?
This can happen when Nona is trying to stitch to an image that is so big
it doesn't fit in memory. Try using pano_modify with --center --fov=AUTO
--canvas=AUTO --crop=AUTO to get a sensible size, or fixing it with the
Hugin GUI.
I guess it is a bug if the output is automatically way too big. Also, if
the size is sane but nona crashes anyway, there is a bug in nona.
-James
Tom Sharpless
I also recently had Nona crash with "bad allocation", while trying to
reproject a 300 Mpix equirectangular image on a Win32 box with 3 GB
RAM using Hugin version 2010-5063. Nona succeeded when I reduced the
output dimensions from 23000 x 13000 to 20000 x 9600.
PTGui had no trouble doing this job at the original size, so I would
have to suspect there is a bug or design flaw in the current version
of Nona. I didn't try PTMender, but that might be interesting.
Cheers, Tom
Ognjen Bezanov
Yet again I am thankful for your help! I tried running pano_modify with
the settings you gave, but now I get a segfault in pano_modify!
#>> pano_modify --center --fov=AUTO --canvas=AUTO --crop=AUTO
--projection=0 -o project.pto ./project.pto
Setting projection to Rectilinear
Center panorama
Fit panorama field of view to best size
Setting field of view to 179 x 178
Caluclate optimal size of panorama
Setting canvas size to 2086957 x 1043374
Searching for best crop rectangle
Run called
Down to Algorithm
Calculate the cropping region
Original Image: 2086957x1043374
Segmentation fault
How much memory do I need? I have 3GB on my box atm (Running Gentoo
Linux 2.6.31).
What I don't understand is, why is it segfaulting now? It would process
the image before just fine. Logically the image before should be larger
than the cropped one, so it should have segfaulted back then?
And why is the image so large? Each scan is 1578x935 and there are 15 of
them. Assuming they are put end to end (which is not the case, as there
is like 70% overlap between them) we'd get a maximum size of 1578x14025
This is far less than "2086957x1043374". Where on earth is that number
coming from?
James Legg
> #>> pano_modify --center --fov=AUTO --canvas=AUTO --crop=AUTO
> --projection=0 -o project.pto ./project.pto
>
> Setting projection to Rectilinear
> Center panorama
> Fit panorama field of view to best size
> Setting field of view to 179 x 178
I think this should be lower for scans.
> Caluclate optimal size of panorama
> Setting canvas size to 2086957 x 1043374
This should definitely be much lower.
> How much memory do I need? I have 3GB on my box atm (Running Gentoo
> Linux 2.6.31).
That should be more than enough.
> And why is the image so large? Each scan is 1578x935 and there are 15 of
> them. Assuming they are put end to end (which is not the case, as there
> is like 70% overlap between them) we'd get a maximum size of 1578x14025
> This is far less than "2086957x1043374". Where on earth is that number
> coming from?
I think your optimised panorama is wrong if this is happening. You need
to optimise roll, x shift and y shift for each image to align scans. The
the yaw and pitch should remain 0 degrees. Since you have set the
images' field of view to 10 degrees, the field of view of the panorama
should therefore be much less than 179 by 178 degrees. The huge size
comes from having images spread out too far.
You'll need to set the right variables to optimise in the pto file, then
run autoptimiser with -n instead of -a.
In PTO file, a line beginning with v indicates variables to optimise.
There is a letter code for the variable, followed by a number for the
image. Images are numbered from 0. The code for roll is r, d and e are x
and y shift respectively, v is the field of view. This is useful if the
scans are different sizes.
So "v d3" indicates the x shift of the forth image should be optimised.
Don't optimise any variables for one of the images, this image will
remain fixed so the other images can be positioned around it.
It also seems automatically setting the field of view ignores the
shifted images, so they don't fit in the output. (Bug?)
Autocrop finds a reasonable crop, but takes longer. So I would set a
slightly too large field of view then autocrop (assuming the first image
has a reasonable rotation).
The attached bash script should stitch scan images.
-James
Yuval Levy
> And why is the image so large? Each scan is 1578x935 and there are 15 of
> them. Assuming they are put end to end (which is not the case, as there
> is like 70% overlap between them) we'd get a maximum size of 1578x14025
> This is far less than "2086957x1043374". Where on earth is that number
> coming from?
rectilinear projection with 179x178 FOV. the question is why --fov AUTO
yields such a FOV. Can you post the original project.pto?
Yuv
Ognjen Bezanov
Could have been stripped by a filter at some point. Perhaps try sending
it to me directly. I'd love to have a look at how you did it!
Yuval Levy
> On 23/10/10 04:45, Yuval Levy wrote:
yes it does! looking at the yaw values, the panorama has been centered around
the 0°/360° seam line instead of the 180° middle line.
a numeric transform of yaw +180 and then auto-fov and auto-crop should fix this
specific project.
and I think you just found a bug (or rather a feature request) in the --
fov=AUTO functionality of pano_modify.
around line 348 of tools/pano_modify.cpp we need to check if if the images are
on the seam line and fix accordingly.
around line 374 we could introduce a warning like James has introduced
recently to Hugin when stitching an excessive size canvas.
congratulations.
Yuv
James Legg
> On 23/10/10 03:17, James Legg wrote:
> > The attached bash script should stitch scan images.
> >
>
> Could have been stripped by a filter at some point. Perhaps try sending
> it to me directly. I'd love to have a look at how you did it!
I found it on the Google groups web interface. Here's the link:
https://groups.google.com/group/hugin-ptx/attach/0377b885067fa3b4/scan_stitch.sh?part=2
Ognjen Bezanov
yay! I found a bug! lol. I guess that's a good thing, right?
Thanks for your help! Quick question though, how can I do a numeric
transform from the command line? While I've used Hugin a lot in it's GUI
form I just now learning about the scripting possibilities behind it.
Ognjen Bezanov
Thanks! I tried out the script, and it *almost* works. The top half
seems almost perfectly stitched, but the bottom half is still warped.
Any idea what could have caused that?
I'm not trying altering the FOV to see if that makes any difference.
Yuval Levy
> yay! I found a bug! lol. I guess that's a good thing, right?
yes, good thing. it's the first half to a fix :)
> how can I do a numeric
> transform from the command line?
you can probably do this with ptocentre [0] before running pano_modify.
however I have bad news for you: I was to quick jumping to conclusions. On a
second look there is more that is wrong in the pto file than just the images
overlapping the 360° seam. Have you tried to open it in the Hugin GUI and
verify how it looks? images are rolled all over the place, and they are
clustered, some of them around the 360° seam and some of them in the center. a
numeric transform of 180° yaw would just bring the central cluster to the edge
and the edge cluster to the center, not resolving the problem. sorry.
is this the pto resulting from pano_modify, or the one you feed into it?
Yuv
[0] http://search.cpan.org/dist/Panotools-Script/bin/ptocentre
Ognjen Bezanov
> On October 23, 2010 01:50:50 pm Ognjen Bezanov wrote:
>> yay! I found a bug! lol. I guess that's a good thing, right?
>
> yes, good thing. it's the first half to a fix :)
That is good :) I'd offer to help but I don't have a clue where to
start as far as C coding code. :(
>
>
>> how can I do a numeric
>> transform from the command line?
>
> you can probably do this with ptocentre [0] before running pano_modify.
>
> however I have bad news for you: I was to quick jumping to conclusions. On a
> second look there is more that is wrong in the pto file than just the images
> overlapping the 360° seam. Have you tried to open it in the Hugin GUI and
> verify how it looks? images are rolled all over the place, and they are
> clustered, some of them around the 360° seam and some of them in the center. a
> numeric transform of 180° yaw would just bring the central cluster to the edge
> and the edge cluster to the center, not resolving the problem. sorry.
Damn, I loaded it into hugin, and the thing is totally warped, it's like
it was flattened into a pancake,very wide and very short.
>
> is this the pto resulting from pano_modify, or the one you feed into it?
It's the pto before pano_modify, as pano_modify would segfault while
trying to use that massive resolution for a canvas.
I could however easily rectify the situation in hugin manually, and have
attached the altered project file, if it helps you see how the end
result should (more or less) come out.
Thanks!
Yuval Levy
> I could however easily rectify the situation in hugin manually, and have
> attached the altered project file, if it helps you see how the end
> result should (more or less) come out.
The altered project file won't be useful for me but you will need it to compare
between your command line manipulations and the expected result when fine-
tuning your process.
Yuv
Ognjen Bezanov
Ok, thank you so much for you help! :-)
Ognjen Bezanov
Just to say that I managed to get it to work! I thought I'd post the
code here in case someone else wants to automatically stitch scans from
the command line.
The below works for me on all the scans, which is excellent!
#!/bin/bash
FOV=10
autopano-sift-c --projection 0,$FOV project.pto ./*.tiff
sync
ptoclean -v --output project.pto project.pto
sync
autooptimiser -a -l -s -o project.pto project.pto
sync
ptocentre -r -p -y -o project.pto ./project.pto
sync
pano_modify --center --fov=AUTO --canvas=AUTO --crop=AUTO--projection=0
-o project.pto ./project.pto
sync
nona -m TIFF_m -o project project.pto
sleep 1 #seems that enblend can start reading before nona finishes (?!)
sync
sleep 2
enblend -w -o project.tif project*.tif
#END CODE
I had to add a lot of syncs and sleeps, because otherwise I'd get random
exceptions and errors.
Once again, thanks for your help, and thanks for this awesome collection
of software!
:)
redag2
Could you post an archive containing the required files to run your
bash script?
Thanky