All demosaicers (and I think Amaze even more …) are sensitive on WB used during demosaic. In RT we have a pre_demosaic auto_WB for this but there are cases that this calculation fails miserably.
This LED illuminated scene is one of the more extreme one can think of. and RT fails pre_mul:[0.003023 0.038842 1.000000 0.038842], scale_mul:[0.051131 0.656900 16.912258 0.656900],
calculated multipliers as 0.003 and 0.038 are insane and I bet this is the culprit here. Also see that auto WB falls out of range (tint 5.0 )
We had this conversation some months ago with @heckflosse. We have to sanitize the pre_WB calculation and a first step is to remove marginal values from calculating the average level of raw RGB
near black (say 0-2 raw levels in this file) because there is no real signal there, it’s only noise with no color info…and
near white levels because there are non-linearities there which can also disturb calculations
at the corners of the frame to remove the area where vignette and color casts can disturb calculations.
Another option could be to define a sanity range and use this when calculations give out of range results … set 5.0 as limit and when RT pre_WB calculates an insane 300 (1/0.003) use the sane 5.0.
Why not to perform the demosaicing with the user-selected WB? This is supposed to be the choice that better harmonises the different channels, right?
I have some example in which a proper user-selected WB gives much better results than the pre-demosaicing auto-WB in the case of LMMSE, particularly in terms of impulse noise… I can share the RAW file if you are interested.
RT used the AsShot at first but we had problems (demosaic artefacts) with insane user selected WBs (see UniWB ) and changed to auto calculated (like Dcraw ). At an old discussion Emil Martinec wrote that a correct WB helps demosaicers to deside correctly about demosaic direction so we found that usually the auto calculated is better.
(A user selected WB is not really choosed about balanced channels but about the final rendering I think.)
But then remain the cases where the calculation fails …
A workaround could be to have the option to revert to AsShot (a checkbox at RAW tab) or even to permit the user to define raw multipliers (your raw converter gives this option I think )
If you do LMMSE in a log space, it shouldn’t affect things. It smooths out differences in the color channels, not ratios, and it doesn’t do actual edge detection.
That said, there’s a tradeoff because a log space can’t handle negatives, and if you just clip at 0 you throw out real data.
Here is my file for which LMMSE performs better with the AsShot WB compared to RT’s auto-WB: http://filebin.net/zndesgrh1e
Well, in fact the temperature/tint corrections finally boil down to RAW multipliers… so setting the multipliers directly is just another way of doing the manual WB correction, if I’m not wrong.
@ilias_giarimis: For this specific image, AsShot multipliers are OK. I’ve played with RT some time ago, disabling the auto-WB computation and replacing the auto-WB multipliers with the AsShot ones, and results where practically the same as in PhotoFlow, and definitely less noisy than the default RT processing.
I’m searching on my disk to see if I still have the examples.
OK … it is again wrong auto_wb because it wrongly tries to handle the yellow which fills the frame. The AsShot is a correct WB here. But I think this is an exception ?. I find more shots where the as shot WB is
So the problem is to find an algorithm which does not fail that easily, I had some links for more robust algorithms … I will try to find them again …
This is not very difficult, but still it is more practical to have a global WB before the demosaicing and then local corrections after demosaicing but before converting from the camera colorspace to the working colorspace… particularly because at this stage it is already possible to construct luminosity masks and/or hue masks.
Thanks, is it possible to provide very overexposed shots (say +5EV so that all channels at all the frame are clipped) at ISO100. To detect any non linearities at highlights …
This is complicated with the way RT is organized. Going back and forth from RAW to RGB perplexes things regarding white level and chanell scaling, I remember Anders had difficulties adapting …
Thanks a lot for all your input. I am definitely less worried now. I thought, I had been using wrong settings for previous NEF-images. Actually, the extreme illumination in this particular case, challenges the software probably causing artifacts.
I would very much like to help you with overexposed shots for further investigation. However, the shot was taken at a building illumination event and there is no option to reproduce the scenario.
) and changed to auto calculated (like Dcraw ). At an old discussion Emil Martinec wrote that a correct WB helps demosaicers to deside correctly about demosaic direction so we found that usually the auto calculated is better.
