Unadequate stitching of a HDR panorama

[Alex Fliker]

HDR files:

https://fliker09.tk/sharedstuff/launchpad/1.hdr
https://fliker09.tk/sharedstuff/launchpad/2.hdr
https://fliker09.tk/sharedstuff/launchpad/3.hdr
https://fliker09.tk/sharedstuff/launchpad/4.hdr

Project file:

https://fliker09.tk/sharedstuff/launchpad/panorama_8_panomodify.pto

Execute:

nona -m EXR_m -o panorama panorama_8_panomodify.pto

I get 4 EXR files. For visualization I tone-mapped them using mai11 operator:

https://fliker09.tk/sharedstuff/launchpad/panorama0000.jpg
https://fliker09.tk/sharedstuff/launchpad/panorama0001.jpg
https://fliker09.tk/sharedstuff/launchpad/panorama0002.jpg
https://fliker09.tk/sharedstuff/launchpad/panorama0003.jpg

Looks all good. After that I try to stitch them using enblend 4.2 (nft and graph-cut algorithms) and verdandi 2016.2.0 (watershed algorithm):

enblend --wrap=horizontal --blend-colorspace=IDENTITY -o panorama_original.exr --primary-seam-generator=nearest-feature-transform panorama000*.exr
enblend --wrap=horizontal --blend-colorspace=IDENTITY -o panorama_original.exr panorama000*.exr
verdandi --wrap --seam=blend --output=panorama_original.exr panorama000*.exr

I again tone-mapped the results for visualization:

https://fliker09.tk/sharedstuff/launchpad/hdr/

I hope no commentaries are needed...

Next, I decided to tone-map the nona's output:

pfsin panorama000$i.exr | pfstmo_mai11 | pfsout panorama000$i.tiff
convert panorama000$i.tiff -channel a -negate +channel panorama000$i.tif

After that I stitched again:

enblend --wrap=horizontal --compression=none --blend-colorspace=IDENTITY --fine-mask -o panorama_original.tif --primary-seam-generator=nearest-feature-transform panorama000*.tif
enblend --wrap=horizontal --compression=none --blend-colorspace=IDENTITY -o panorama_original.tif panorama000*.tif
verdandi --wrap --seam=blend --output=panorama_original.tif panorama000*.tif

And here are the results:

https://fliker09.tk/sharedstuff/launchpad/tmo/

Difference is huge... Much better results! Now the question - why so bad with EXR files? Am I doing something wrong?

[tmodes (tmodes)]

First of all: in this case it is sufficient to work with downsized versions. Your files are very big (also the final jpeg have different size 7 vs 49 MB by identical image dimensions). Why such big images?
Second: For hdr images the response type should by linear and not EMor (When loading these image, hugin sets it automatically to linear)
Third: Your HDR images have different exposure levels (they are different bright, have a look at the hdr file itself). And the exposure values in the project file does not match them. (Maybe recreating the hdr images with the same base brightness helps. Then the correction in Hugin is not needed.)
Point 2 and 3 explain a big part of the issues with verdandi - so closing moving to enblend tracker.
But it does not explain the problems with enblend, which should better blend away the brightness differences

[Alex Fliker (fliker09)]

1) Didn't think about that as an issue;
2) Yeah, I see now. The problem is - how do I set response type using only console tools? Yeah, I can do it by sed, but that sounds wrong;
3) HDR files may indeed have different exposure levels, but I expected autooptimiser to handle that. But even after fixing response type I don't see big improvement :/ vig_optimize is of no help (doesn't calculate the EV even if I set the corresponding variables with ptovariable). I also tried Hugin GUI - also no help. Any suggestions are welcome!

[tmodes (tmodes)]

1) This is not polite.
2) pto_gen sets the correct response type automatically.

[Alex Fliker (fliker09)]

1) Pay attention that I said it in past tension - I just didn't pay attention to the file sizes at the moment of the upload. If bandwidth on your side is problematic - just say it and I will re-upload smaller files, no need to call me impolite;
2) I am using pto_gen, and yes, you are right, it does indeed set the flag. But autopano-sift-c does not preserve it... So, I have to stick with sed?

[Alex Fliker (fliker09)]

What about the main issue? Is there anything else to be done/investigated?

[Stefan Peter (s-peter-deactivatedaccount)]

Dear Alex Fliker

autopano-sift-c has been deprecated for quite some time now due to concerns about the use of a patented algorithm, IIRC. It has not seen any maintenance since 2009. No wonder it has fallen behind regarding support of current features.

Why don't you use cpfind instead?

With kind regards

Stefan Peter

[Alex Fliker (fliker09)]

Dear Stefan,

The only problem with autopano-sift-c I see is the way it handles input pto... Regarding the control points search it beats cpfind, especially in indoor panoramas. But control points are not the main concern for me now - I need to get enblend/verdandi working in HDR pipeline. Don't suggest me enfuse, already tried :) I need to get HDR working :\

[Alex Fliker (fliker09)]

Well, it seems that applying gamma 2.2 to the HDR images solves the issue (which is strange on its own). But IMO it can not be accepted as solution