Multi-row panoramas sans tripod with Hugin

[PacNWMike]

I did a quick and dirty comparison a while ago. PSE sucked. Hopefully PS updates are a big improvement. ICE was nice for simple panoramas and was easy. hugin was the best by far... after you learn the software.

 

[0000]

hugin was the best by far... after you learn the software.

Kids don't know how good they have it these days, with all this automagification... bah! Back around the turn of the century we had to select our control points manually, through three feet of snow!

Seriously though, looking through some of the docs for old-school PanoTools will make anybody feel better about the learning curve for Hugin... and, if you accidentally retain any of it, turns out to be useful for understanding how to tweak any of those parameters that interfaces like Hugin or PTgui expose in their scary dark corners...

 

[wjiang]

If you find that Hugin has a bit of trouble with blending, you can always export the individual reprojected frames as separate TIFFs for PS CCs stitching algorithms to take a stab at. Failing that, you can always do some manual blending of the problematic area with PS layers.

 

[fader]

@Balinov glad to hear you were inspired to try it out - feel free to share the results!

If you find that Hugin has a bit of trouble with blending, you can always export the individual reprojected frames as separate TIFFs for PS CCs stitching algorithms to take a stab at. Failing that, you can always do some manual blending of the problematic area with PS layers.

I didn't know you could do that - great tip. (Can I assume this is what the "save intermediate layers" checkbox is?) I have one pano that's about a 500 MB on disk and editing the tif is quite memory intensive - I'll give it a shot.

 

[fader]

Kids don't know how good they have it these days, with all this automagification... bah! Back around the turn of the century we had to select our control points manually, through three feet of snow!

Seriously though, looking through some of the docs for old-school PanoTools will make anybody feel better about the learning curve for Hugin... and, if you accidentally retain any of it, turns out to be useful for understanding how to tweak any of those parameters that interfaces like Hugin or PTgui expose in their scary dark corners...

I have a bit of exposure to gaming code and engines circa 2000~2003. Imaging and graphics is really hard.

 

[Balinov]

barry13, interesting point, probably this is why I can't quite find that test stich sharp enough. maybe embedded jpeg in the ORF has a dumb resolution?
Microsoft ICE pano stich test - 100+ mp

Need to give it a second go, this time using jpegs from the orf processed in LRCC.

 

[fader]

barry13, interesting point, probably this is why I can't quite find that test stich sharp enough. maybe embedded jpeg in the ORF has a dumb resolution?
Microsoft ICE pano stich test - 100+ mp

Need to give it a second go, this time using jpegs from the orf processed in LRCC.

I found that using 16 bit TIF's produce a much more detailed final image compared to JPEGs. What I do is export resized jpegs at 1200 px or 1600px width, then do a a few trial runs to find the right combination of images that produce a nice composite. For example, an image with a high overlap and a big variance in its focus plane compared to its neighbors can be discarded. Once I'm happy with a set of images that work, I go back and re-export the same images at native resolution in 16 bit TIF, then do a final stitch.

 

[Balinov]

fader, your input on ur workflow makes a very good point, sounds within the same amount of time (or just a tad more) I can experiment for the sake of the best possible output...running LRCC on a mere I5-2520M w/ 2x4GB so every little helps when it comes not to spend an hour on one photo... on ICE and with all those orf's it was a good 25-30 min till I got to the first reasonable output (one part was my stupidity, but that's a whole different story). All CPU cores were maxed out during stiching and export..

 

[fader]

fader, your input on ur workflow makes a very good point, sounds within the same amount of time (or just a tad more) I can experiment for the sake of the best possible output...running LRCC on a mere I5-2520M w/ 2x4GB so every little helps when it comes not to spend an hour on one photo... on ICE and with all those orf's it was a good 25-30 min till I got to the first reasonable output (one part was my stupidity, but that's a whole different story). All CPU cores were maxed out during stiching and export..

Likewise, my little cheap-o Dell (only 2 cores) would probably fall over trying to stitch the RAW images. You're not giving up much between 16 bit TIF and 32.

 

[wjiang]

I didn't know you could do that - great tip. (Can I assume this is what the "save intermediate layers" checkbox is?) I have one pano that's about a 500 MB on disk and editing the tif is quite memory intensive - I'll give it a shot.

Um... I was referring to the Stitcher tab for Advanced/Expert mode - you get an extra option under Panorama Outputs called Remapped Images. Checking Exposure corrected, low dynamic range under that heading will output the remapped, exposure corrected frames that go into the final panorama stitch. You could even turn off the one in Panorama Outputs to just get the individual frames and save some time.

FYI, I also do RAW -> ACR -> 16-bit TIFF -> Hugin -> TIFF -> [optional ACR/PS final tune and crop] -> JPEG.

The issue is that stitching huge images requires both a lot of RAM and a lot of CPU work. Because you probably don't have enough RAM, it will have to dump stuff to swap on the HDD, which is immensely slow. I noticed a huge improvement when I upgraded to 16 GB of RAM for moderate stitches because PS can keep the whole lot in memory (once it has ingested it - that's still slow because I don't have an SSD). Now it's just the CPU that becomes the bottleneck for the actual stitch.

 

[Balinov]

Think in my case the cpu limits more than the ram as all runs off a decent ssd

 

[fader]

same for me. At least on Linux, Hugin seems to be extremely memory efficient. The routines that generate the final panorama are decoupled from the Hugin GUI app. Once the project file has been generated with all the control points, you can shut the GUI part of the app off and just run the batch tool after it launches. I haven't tested it, but I'm pretty sure the entire image isn't loaded into ram to make the stitch. I'll have to do some profiling to find out. I typically have 4 desktops configured, the Thunderbird email client, lots of SSH shells (I'm a developer), Chrome browser, Gimp, and Darktable open when I run Hugin. If things start to look tight I'll close a few apps but it hasn't been a big issue. Also, thanks to Linux kernel and SSD swap I can safely push into 4GB or so of swap without too much issue.

If you figure 20 images at 200mb each in native resolution and 32 bit TIF = 4GB on an 8GB system. I've never waited more than about 10 minutes for a final stitch. 40 images at 16bit is about the same space and nearly the same final quality. Of course the system is sluggish with both cores pegged, but that's a minor issue.

 

[Herman]

Hi, are we talking / discussing software from Kolor France (Paris)?

Looking forward hearing from you, thanks in advance.

Best, Herman