hugin-devs team mailing list archive

[tmodes <1630172@xxxxxxxxxxxxxxxxxx>]

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

** Project changed: hugin => enblend

-- 
You received this bug notification because you are a member of Hugin
Developers, which is subscribed to Enblend.
https://bugs.launchpad.net/bugs/1630172

Title:
  Unadequate stitching of a HDR panorama

Status in Enblend:
  New

Bug description:
  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?

To manage notifications about this bug go to:
https://bugs.launchpad.net/enblend/+bug/1630172/+subscriptions