I have been using RT (ver 4.2) for a while on a Linux/Ubuntu 14.04 System and I did not bother too much about special settings for Nikon NEF files [camera model D700]. In essence, I left the default settings.
Trying to process some night shots, I recognized some strange behaviour i.e. green pixels in a yellow area (see extracted section attached).
Do I use the wrong profile for processing NEF-files? (from: /usr/share/rawtherapee/dcpprofiles)
Should I always use a different demosaicing method?
I tried LMMSE instead AMAZE. The green pixels went away, however other areas went worse. My nightshot is ISO100.
It’s a 12-bit raw, so the white level in camconst.json needs to be changed, but despite that it still produces the artifacts, I don’t know why. @ilias_giarimis @heckflosse have you any ideas?
@claudio-v what are we looking at, what light was it illuminated with?
it was LED illumination
Did you also try LMMSE instead of AMAZE demosaicing?
Reading the help files, I noticed this method is particularly for high-ISO
and I should probably not be using LMMSE for my ISO100 image.
However, with LMMSE the artifacts seem to disappear.
I did try other methods, but the point is it looks bad with AMaZE at ISO100. If I remember correctly, RT does auto-white balance early in the pipeline for some reason or other, that’s why I asked what the illuminant was, as perhaps it throws auto-wb off and somehow ends up with those artifacts… Ingo and Ilias will know more.
Questions relayed from Ingo:
- The base ISO of the D700 is ISO200, and ISO100 is “LOW1”. Do you have a good reason for using ISO100/LOW1?
- Does the problem persist if you use ISO200?
It’s an extreme illunination !!!
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.
Hi Carmelo,
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.
As far as I can see, with proper WB multipliers I’m getting nice results with LMMSE on linear values. But I’ve not experimented much so far.
Can you share these proper WB multipliers ?.
@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 …
I’m still of the idea that the WB a user would choose is as good as, if not better, the output of any auto-WB algorithm.
Unless the user sets intentionally the WB far off for artistic purposes…