Extra Large and Gigapixel help with Hugin
Emad ud din Butt
I have successfully created 4000x2000 panoramas. But when I try to make 8000x4000 or bigger full res panos, hugin just hangs after several hours. Total number of images is 291.
Regards,
Emaad
Yuval Levy
On August 21, 2010 03:11:06 am Emad ud din Butt wrote:
> I am having problems stitching extra large panoramas with Hugin. I am
> forwarding .pto, mk and stitching window files.
I looked at the files attached to your message. They raise more questions
than answers.
> I have successfully created 4000x2000 panoramas. But when I try to make
> 8000x4000 or bigger full res panos, hugin just hangs after several hours.
> Total number of images is 291.
So here I go with a first bunch of questions:
1. how many hard disks does your system have? how much space is free on each
one of them?
2. what version of Hugin are you using? and what version of Enblend-Enfuse? I
see hugin-2010.1.0.4920 and hugin.win32.5161 in the paths to the executables,
but path names can be arbitrary.
3. Did Hugin *hang*, i.e. become non-responsive and you had to kill it in the
task manager? or did it *wait* with an error message window for you to
copy&paste and then terminate the program normally?
From the stitching window output the immediate reason for the stitching
process to fail seems to be lack of disk space (emphasis mine):
| enfuse: an exception occured
| enfuse: enblend: error writing to image swap file.
| *Most likely cause: No space for temporary files*.
| Make sure that there is enough space in the temporary directory
That said, the project shows unusual patterns and there likely are more
errors. More information is required to understand:
4. How did you position the camera to shoot the images? Hand held? On a
tripod? On a calibrated panoramic head?
5. Did you do exposure-bracketing? Consistently on every shoot? Or only when
shooting high contrast areas such as windows?
6. In what mode was the camera? Manual? Automatic? Anything in between?
It would help if you could post the following nine pictures, selected in
different areas of the project that show anomalies to explain. Please post
out of camera originals so that we can analyze the whole EXIF input.
P8150053.JPG
P8150054.JPG
P8150055.JPG
P8150132.JPG
P8150133.JPG
P8150134.JPG
P8150135.JPG
P8150136.JPG
P8150341.JPG
The .pto and .mk files seem to be for the 4000x2000 output. From a quick
look, at least a few things are not right. Could be at any of the following
stages or combination thereof: shooting, cp detection, optimization,
stitching. The errors might not show when stitched at 4000x2000 but they will
show when stitched at full resolution.
I don't want to sound pessimistic but it is highly unlikely that I would call
a stitch with the project files you posted a "success" and at this point it is
too early to say if it can be fixed.
Yuv
Emad ud din Butt
_________________________________
Emaad
www.flickr.com/emaad
Yuval Levy
where have you uploaded the pictures and replied in detail? I do not see
anything neither on the mailing list nor in its files area.
For control point generation there are a number of options. Currently all of
them (with the exception of manual generation) are external to Hugin, and all
of them have drawbacks of some sort. Hugin can call some of them from its
user interface. Others need to be called from the command line. A few have
their own GUI, or are even fully fledged stitching solutions.
Autopano Giga, that you are using, is one option. If it works for you, keep
on using it (and buy a license).
The factors to consider in deciding which tool to use include technical
factors, legal factors, the specifics of the project and of the lens used.
From a purely technical point of view, I have found panomatic to be the best.
But it uses SURF and is patent-encumbered in some jurisdictions. When I did
try it, I used it from the command line to generate an initial pto file:
panomatic -o project.pto *.JPG
assuming all image files ends with .JPG and have been sorted so that one
folder contains only the files for one project.
Then open project.pto with Hugin and go about optimizing and pruning CPs.
The above panomatic command is a brute force attack on the project. It will
take long to run, and may result in false positive that are difficult to
detect, especially if there is symmetry in the scene. Another option is to
write a wrapper script around panomatic to only match time-contiguous pairs,
then merge that into a single project and continue with a whole strategy.
Yuv
Emad ud din Butt
Hi Yuv,
Sorry, Images were not sent due to gmail size problem. I am uploading it in parts here.
here is my reply to your questions.
1. There is only one harddrive. I chooe F drive due to 16GB available space. Temp directory of Hugin was also located on F drive. Harddrive partition free space was 16Gb. When Hugin stopped doing anything, there was still 8GB space available.
2. Hugin version is correct. Paths to executables are exact locations where these are located.
3. Hugin was non-responsive. In task manager there was no memory utilization by Hugin or enfuse etc. There was no response for 8 hours or more. Than I copy/pasted these stitching window message and manually closed it.
4. Images were shot on tripod. Using a DIY panoramic head. Camera was in manual mode Or Aperture priority. Camera was in portrait mode. It is 5 row panorama.
5. I dont do exposure bracketing on each image. That increases number of images. I have my own way of doing bright areas. Its a historical place with lots of arche views. I set camera at manual mode for capturing interior details and for windows or high contrast areas I shot another image for details outside. When I chose Fused and Blended output it blended images nicely. I have 4000 x 2000 equirect generated by Hugin. Enfuse is set with "--fine-mask".
I have also seen .mk file. I dont know why its showing 4000 x 2000 whereas I have saved project with 8000 x 4000. Waiting for your reply.
Regards,
Emaad
--
_________________________________
Emaad
www.flickr.com/emaad
Emad ud din Butt
--
_________________________________
Emaad
www.flickr.com/emaad
Emad ud din Butt
--
_________________________________
Emaad
www.flickr.com/emaad
Emad ud din Butt
_________________________________
Emaad
www.flickr.com/emaad
Yuval Levy
On August 26, 2010 12:41:24 am Emad ud din Butt wrote:
> 1. There is only one harddrive. I chooe F drive due to 16GB available
> space. Temp directory of Hugin was also located on F drive. Harddrive
> partition free space was 16Gb. When Hugin stopped doing anything, there
> was still 8GB space available.
only one harddrive? so F (mentioned above), and D (in the pto.mk file) are
partitions? and do I guess correctly that you also have a system partition C?
I am not familiar with the current situation on Windows, but I recall issues
with the storage of temporary files. The analysis still stands:
| enfuse: an exception occured
| enfuse: enblend: error writing to image swap file.
| Most likely cause: No space for temporary files.
| Make sure that there is enough space in the temporary directory
"No space for temporary files".
*Recommendation: simplify / standardize your hard disk layout and try again.*
> 3. Hugin was non-responsive. In task manager there was no memory
> utilization by Hugin or enfuse etc. There was no response for 8 hours or
> more. Than I copy/pasted these stitching window message and manually
> closed it.
If you can manually close the stitching windows after copy/pasting the text,
then Hugin is responsive. Hugin was waiting for user action after the "No
space for temporary files" error. Non-responsive is when you have to kill the
application from the task manager.
> 4. Images were shot on tripod. Using a DIY panoramic head. Camera was in
> manual mode Or Aperture priority. Camera was in portrait mode. It is 5 row
> panorama.
Analyzing the images and EXIF data.
Good news first: they all have a consistent FoV. This means something went
very wrong in the geometric optimization step(s).
Not so good news: the images are architectural and present symmetries. Simply
dumping them on any brute force CP generation will result in a nightmare.
The really bad news: EXPOSURE! Sure, Hugin has photometric adjustment and
more, but this is really pushing it.
*Reccomendation: if you can, re-shot* - but first take the time to read the
following feedback and plan your shooting well.
1. set the camera to *manual* mode.
2. your shots were at F/2.8. Even if this is a small sensor, you may want to
stop it down one or two F-stops.
3. the shutter speed in the few example shots was all over the place. 1/1000
is surely nice for an HDR of the exterior, but given the kind of camera and
other challenges, I'd scale back with the ambition. Shoot *all* frames (even
those that are only on the inside) with the camera's bracketing (I believe it
can do -2/0/+2 EV). Set it at 1/125 (for F/2.8 - if you step down, adjust
accordingly). You'll have 1/30 (which is enough for the interior) to 1/500
(which is enough for the exterior).
4. shoot all the shoots consistently with those very same settings. Don't
forget to put the focus on manual too.
5. When you're back home, first merge the brackets with enfuse. Use one of
the enfuse GUIs, or the droplets, or the command line. This will reduce by
2/3 the number of images (and their disk space).
> 5. I dont do exposure bracketing on each image. That increases number of
> images. I have my own way of doing bright areas.
consider doing it. a memory card is cheap nowadays, and shooting consistently
with the same settings prevents errors that can cost you much more than a few
extra shots. See above.
> Its a historical place with lots of arche views.
Beautiful. I would like to see the full pano.
> I set camera at manual mode for capturing
> interior details and for windows or high contrast areas I shot another
> image for details outside.
From the description I would expect just two shots per image. But there are
five of them (unless the place has absolute symmetry and you turned the pano
head 180° between the shots). This is not "one image for interior and another
image for details outside". It is five images, and it looks as if the
"bracketing" has been done manually, in the following sequence:
Shutter Speed : 1/1000
Shutter Speed : 1/13
Shutter Speed : 1/40
Shutter Speed : 1/30
Shutter Speed : 1/25
Those five images could have been resumed with auto-bracketing -1/0/+2
resulting in 1/500 1/125 and 1/30
Those five images resulted in a huge amount of CP computations. Enfusing them
first and feeding the enfused images to Hugin is the way to go here.
> Waiting for your reply.
I hope you did not find it too hard - the intention is to give you feedback
you can learn from. Summarizing:
1. simplify your hard disk's layout
2. shoot regular brackets all over the pano. manual exposure, manual white
balance (like you did), manual focus. all of them, including focal distance
(as you did) constant
3. merge the brackets with enfuse first
4. feed the bracketed images to Hugin using the new multi-row mode; or use a
script to generate an initial pto file with CPs only between adjacent images;
or use Hugin's interface to select image pairs and generate CP's between each
of them (tedious); or before optimizing select check the connections between
pictures that may have symmetries and prune the wrong ones.
I'm still not sure if the current project can be saved, but it can definitely
be used as a learning experience.
Yuv
Emad ud din Butt
2. shoot regular brackets all over the pano. manual exposure, manual white
balance (like you did), manual focus. all of them, including focal distance
(as you did) constant
or use Hugin's interface to select image pairs and generate CP's between each
of them (tedious); or before optimizing select check the connections between
pictures that may have symmetries and prune the wrong ones.
_________________________________
Emaad
www.flickr.com/emaad
Rogier Wolff
> 5. When you're back home, first merge the brackets with enfuse. Use one of
> the enfuse GUIs, or the droplets, or the command line. This will reduce by
> 2/3 the number of images (and their disk space).
>
>
> > 5. I dont do exposure bracketing on each image. That increases number of
> > images. I have my own way of doing bright areas.
If you want, you could start (as I did) without using the
bracketing. It would be best to start out shooting something that
doesn't have too big a dynamic range.
I always chose the second-brightest shot in the pano for my exposure
setting.
Roger.
--
** R.E....@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
** Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement.
Does it sit on the couch all day? Is it unemployed? Please be specific!
Define 'it' and what it isn't doing. --------- Adapted from lxrbot FAQ
Yuval Levy
On August 27, 2010 02:33:52 am Emad ud din Butt wrote:
> Bundles of thanks for your detailed reply. Its very informative for me. I
> learnt a lot from your reply.
glad it helped.
> How can I stitch adjacent pics? I am not into scripting.
the new multi-row mode should help, but I am not sure how far the windows
binaries are nowadays.
> Please! See final panorama at Royal Garden Arches at Lahore
> fort.<http://pan0.net/upano.php?id=1134#pano_self> Nadir is not
> patched yet. This is beauty of Mughal Architecture.
Thanks. Beautiful indeed.
> Thanks again for help. have you ever tried to stitch extra large or
> gigapixel images with hugin ? Hugin can do it?
Yes, easily. Already in 2007 at LGM we toyed with the idea with Pablo. But
we lacked time and gear. I went back to the same place a few weeks later, but
the weather was overcast, so it was a purely technical exercise. I did a
couple of other gpx-panos, although I am not a fan of the gigapixel race.
I wish there was a method to weight the pixels by their quality and the
additional information they bring to the scene. Generally I found most gpx-
panos published after the Harlem 13 gpx one to be boring. I would rescale
them factor 5 or 10 and would not miss the 80%-90% lost pixels. Plus most of
their pixels are just boring areas that I would have not even framed.
Attached is a thumbnail of one of my rather large panos. It's not gigapixel,
far from it. But it is 3x bracketed exposure (does this count as 3x pixels,
like foveon sensors vs. traditional sensors?) and I don't have enough free
wall space for it (4.5m x 1.5m). Shooting was limited by a tourist-like
situation. I could have used a longer focal distance. To waste more time of
my waiting travel partners? With few exceptions I fail to see the practical
and aesthetic value of gpx-panoramas beyond the computing race. Large panos
are nice. Large prints are nice. But how big do you want to print,
considering that with increasing distance to the print resultion can be
lowered with no practical visible loss? It's like those home cinema
enthusiasts who buy 42" FullHD TV and sit 6-7 meters away from them, where
they can not discern the 1080i resolution. For the same price they can get a
56" 720p resolution and get a much better experience. But the salesman sold
them the pixels.
Yuv
Emad ud din Butt
binaries are nowadays.
_________________________________
Emaad
www.flickr.com/emaad
Yuval Levy
> Which OS you use?
Kubuntu and FreeBSD.
> Fevon sensor is good but its low in megapixels :)
right, just that each pixel on a foveon sensor has three times the depth of
traditional CCD/CMOS sensor, so a foveon sensor at 4 mpx yield the same
information quantity as a traditional CCD/CMOS sensor at 12 mpx and does not
suffer from the demosaicing.
Foveon, another victim of the pixel-count race...
Yuv