Did anyone notice a huge difference between 2.4 and 2.5, especially with FATTAL?
Example:
2.4:
2.5.1:
The input are 3 processed NEF → TIF files. But even with the camera JPG’s it’s going bad in the same way. Also bad with different kind images as I remembered what I tried months ago. Ignored it and continued using 2.4 but can’t do that for years long probably, so rather find out what’s going on.
Please provide example files to reproduce if possible.
Also: Is that using 2.5.1 or using 2.5.1 Snapshot?
2.5.1 from Download « Luminance HDR
Also what I have with 2.4 is different output for 100% same input and 100% same settings. Was never able to figure out how that is possible.
Than it’s at least not caused by my optimiatzions \o/
True. I’ve had the problem already since the alpha/beta version of 2.5.
Any news on this?
Someone willing to try a comparison?
Does this also happen with latest dev build? You can find a windows build here
https://keybase.pub/gaaned92/HDRNightlyBuilds/
No files provided.
Will try soon.
Sample set:
2.4 importing:
2.5 nightly importing:
So there is a difference in absolute exposure bias. 2.4 is correct, although relatively it’s the same. There seemed to be a bit of a difference in lightness of the result. Though, this might also be the Different render outcome for same input bug. I will post in that topic after this post.
2.4 after import :
2.5 nightly after manually set correct exposure bias and import:
2.4 render:
2.5 render:
Now, there are some good things about 2.5, like sharpness but saturation is less and the whole point of the topic: looking in the white areas you see strong artifacts, and the display in the middle has just been destroyed.
To be able to reproduce we still need files …
Sample set included that I used too.
Ok, missed that, thank you 
Reproduced in v.2.5.1-245-g7dc448a6.
I don’t know why the result is better in 2.4 but I think the reason for the artifacts is that the darkest image is not darker in all places than the second darkest image. To demonstrate I subtracted the 2nd darkest image from the darkest image. That should give a completely black image but it does not:
The differences are in the regions where the artifacts appear in lhdr
The areas which look clipped-white are also not really #FFFFFF. Maybe JPEG compression.
@heckflosse
Interesting find. I don’t remember if I did individual pre-processing with this sample set. Normally I do pre-processing with exactly the same parameters on all 3 files, and still it would happen.
@Morgan_Hardwood
Might have happened with the sample set, but also happened with 48-bit TIFF as LHDR-input.
I will update on this subject when I come across it again.
