Menu
▾
▴
#27 Odd color artifacts on highlights in HDR
Creating HDRs from multiple images some of which have blown highlights results in bad color artifacts. The behavior is quite different between 1.8.12 and 1.9.2, actually worse in newer version. The attached pair of source images illustrates the problem really well (at least, it does on Windows, did not try other platforms). The images are created using dcraw (executable from 1.9) from CR2 files with default parameters per 1.9 ("-T"). Using parameters equivalent from 1.8 (appears to be "-w -o 4 -q 3 -T") results in better HDR in 1.8 but no real improvement in 1.9 -- magenta shapes are still there, just slightly different.
Analyzing pixels in Photoshop shows rather odd highlight anomaly in TIFF images: the brightest highlights in the second image are actually really bright magenta (255,238,255). So, there may be more than one issues here:
a) something broke in dcraw between 1.8 and 1.9;
b) something changed in HDR composition between those two versions -- not necessarily to the worse, hard to tell with the first issue around.
Discussion
Problem images
Logged In: YES
user_id=1219574
Originator: NO
Hi Vasyl, indeed it's hard to tell, can you please test with the following parameters (suggested by another user): "-T -4 -q 3" ?
thank you.
Logged In: YES
user_id=352450
Originator: YES
That improved things somewhat but still far from perfect. I've done some extra research and found some relevant information (this one's good: http://www.luminous-landscape.com/forum/lofiversion/index.php/t23430.html). By playing with -S parameter (not documented in qtpfsgui help but supported with dcraw included with 1.9.2) I've managed to get it right (for Canon XTi it was -S 3745). As I understand, that value is different for different cameras and at different ISOs. So, the proper fix would be "camera profiles" for RAW conversion (more like a feature request though). Help file needs updating but that's minor -- it might as well just refer to dcraw manual. I am still concerned that so minor color inversion in source images (those attached TIFFs) causes so major artifact in the result. Is it possible to automatically clip values of higher/lower EV images not to go below/above values in the next image? That would probably eliminate some noise in shadows -- I've noticed definitely amplified noise in some HDRs.
Logged In: YES
user_id=1219574
Originator: NO
I used your LDRs and managed to get those magenta color casts that you reported.
Your suggestions about clipping (or even discarding the value) makes sense. I'll have to look into the history of the hdrcreate.{cpp,h} files. I mentioned them in case you want to find a fix/hack yourself.
Since this requires a longer sitting, I'll leave the bug open as a reminder.
Logged In: YES
user_id=1255981
Originator: NO
I also experienced this phenomena today. A large area colored with magenta appears when I create my HDR image.
When I use the "-T -4 -q 3" flags the area disappears but I haven't notified any difference when using the -S flag (maybe I used the wrong value).
I guess using the "-T -4 -q 3" flags is a sufficient solution for me but this should probably be mentioned in the documentation.
I'm using Qtpfsgui 1.9.2 and Windows XP and my the Camera used for the RAW images is a Canon 400D.
Logged In: YES
user_id=352450
Originator: YES
As I said, using "-T -4 -q 3" does improve the quality for me but it is still not perfect -- instead of large magenta areas I am getting narrow magenta bands in highlights. "-S 3745" brings it to perfection.
The problem is, I am getting similar bugs on JPGs straight from camera where I don't have much choice. TestImages2.zip contains two JPGs, crops from Canon SD800 shots, that illustrate the issue (you may want to enable alignment plugin when loading those). Version 1.8.12 handles those perfectly but 1.9.2 quality is really bad. So, there is definitely a regression there.
File Added: TestImages2.zip
More problem images
Logged In: NO
One more thing: I've pulled older versions to find when that regression got introduced and it looks like it went in between 1.9.1 and 1.9.2. I don't have setup to build qtpfsgui right now so I cannot test individual changes but there were not that many changes in that period. Did not see anything immediately suspicious except for debevec.cpp but I am not familiar with algorithm to tell if there is anything wrong about the change.
Logged In: YES
user_id=1219574
Originator: NO
Thank you very much for testing older versions and most likely for finding the real issue. debevec.cpp is definitely the right file to look into.
So basically with version 1.9.1 all is ok?
Logged In: YES
user_id=352450
Originator: YES
Almost. TestImages2 works exactly as expected. There are still some issues with TestImages (the first set) but those are probably caused by that color inversion I've mentioned before and, as such, would be fixed by clipping color values.
Logged In: YES
user_id=1219574
Originator: NO
I restored v1.9.1 original behavior (with a trivial fix for the alpha channel) in svn.
I used your first LDR image set to run a quick test and I can confirm that there are still some color issues with that.
Reading the code I can say that Qtpfsgui (when computing an hdr pixel) discards (i.e. skips) an exposure if the pixel has an higher (lower) value but its EV is lower (higher) than the current image.
Logged In: YES
user_id=352450
Originator: YES
I've been thinking about those color artifacts and now I am not sure anymore if skipping is the right thing. The problem is that in the case of two images it is not exactly clear which one to skip and this still may be only one part of the problem. The other part -- with older (now restored) algorithm I am getting artifacts that are too close to neutral gray to be a coincidence (tried in 1.9.1). I did not dig deep in code but this is suggestive: on EV -3.95 pixel (255,255,255), on EV -0.95 pixel (255,238,255), the resulting pixel looks close to (127,127,127). It's almost like one value was dropped but some divider was not adjusted and the pixel values were divided by 2.
I've just started using Luminance HDR and it's quite fascinating! I've created a few very cool images with the tool.. however, this issue is affecting me in a serious way. I'm using a Nikon D5000 and NEF files as input. I'm getting very bad artifacts where the white spots (pushing the upper range of values, possibly hitting the limit) are blown out, even at the lowert exposure image.
No matter what settings I use, it's there. When I set the option to use "Plateau", it's better, but still bad. Ultimately, I have to use Photoshop CS4 to merge the images. This results in no artifacts and a usable HDR file. The only problem is that the auto-align feature doesn't work nearly as well as the one in Luminance.
I am more than happy to send some example NEF files. They are 10 MB each, so an attachment might be a bit much. Please look into this! This is one of the 2 biggest issues with the software. (The other is not dealing with my high-res images well.. I shoot at 12 megapixel, approx 4800x2400, and 90% of the time the program crashes when I perform tone mapping.
Cheers!
-Sean
To elaborate on my issue, I see magneta or rainbow "blow outs" on the highlights.. a recent image I processed had purple spots where sunlight was hitting leaves!! :)
Hi everybody,
I'm a new developer of Luminance HDR. I was already looking into this problem in this days because I think it's a major issue to sort out asap.
A few days ago an user of the flickr group suggested a possible solution for this problem changing the default parameters of DCRAW in Luminance adding "H=2". Can you try this solution?
Thanks, Davide
BTW, which OS are you using?
I'm using Windows 7, 32 bit. How do I add that parameter? I'd love to try it!
You can easily do it using the preference panel and changing the parameters for the dcraw converter.
I just found it! I'll try it out and let you know. That auto-align is first-class, but those blow-outs are just plain ugly! :)
That worked beautifully! Looks like a new default to me. So is this just a side effect of the Nikon EMF conversion?? Looks like the "-H 2" did the trick. :) Very happy camper!
Now... if only the apparent resource issue can be solved.. (my 4000 x 2000 images mostly die when applying tone mapping)
Try to save the file in TIFF, then close Luminance, open it again and load the file (without doing the creation of the HDR). Now you should be able to do the tonemapping. It's just a workaround. :)
Davide
Using the new Luminance 2.0.2-pre1, it's possible to set multiple parameters for the RAW conversion. I consider this bug close, bug if you spot other weird behaviours using 2.0.2-pre1, feel free to open a new bug report (specifying OS, Luminance version and steps to raise the problem).
So.. I am now running the 2.0.2 beta 2 build and had similar issues. On a whim, I made some config changes and found the fix! I originally was getting artifacts from my D5000 EMF conversion, but turning OFF "Auto Brightness" under White balance, the problem goes away! :)
This should be re-opened. I have three TIFF's at 800x600 that exhibit the problem with 2.0.2pre1. This is even after turning off the RAW option I mentioned below (no surprise, as these are TIFF's, not RAW) A workaround is to: create the aligned HDR in hugin, open and re-save in Picturenaut, then open in Luminance. Quite a hassle.
I do have the same problem with CR2 files