Hi, I have some shots whose rather unusual white balance (owing to the orange-ish light of high-pressure sodium vapor street lamps) bumps into the lower limit of the color temperature range (1500), and therefore cannot be processed correctly. (The WB is correct, the camera-JPEG looks pretty good!) Could this limit be eliminated in future versions?
Thanks in advance!
Hey
The Blue/Red equalizer is meant to deal with that. You would need to shoot a color target under that light to get colors anywhere close to accurate.
Hi, thanks for the very quick reply.
That slider definitely does improve the colors, but they are still too warm, relative to the camera-JPEG. To clarify the situation, I don’t intend to compensate for the sodium vapor lamps so that their light looks neutral - I simply want to be able to use the camera white balance, which gives a pretty good result in the cam-JPEG, but that lies beyond the lower limit of the temperature slider.
@szgabor Did you use packaged version of rt or self-compiled? In case of latter, can you try to change MINTEMP in rtengine/colortemp.cc and rtgui/whitebalance.cc from 1500 to 500 to check whether it solves your issue?
Or upload a raw file to filebin.net so we can check.
Sodium vapor lamps are a poor light for color due to a discontinuous spectrum. See:
High pressure is better than low, but still isn’t great. You may not be able to color balance accurately. It doesn’t really have what you could call a true color temperature because of the discontinuous spectrum. Color temps are based on a continuous spectrum from black body radiation heated to a certain Kelvin temperature. Color temperatures assigned to other discontinuous spectra sources (like fluorescent and white LED) are really only approximations. Using more phosphors that are carefully chosen can improve the CRI (color rendition index) of those sources, but sodium doesn’t work that way.
Yes, that would be simple and I believe it would solve the problem - at least for me. But I’m still so unfamiliar with Linux and its development tools that it would be several hours of headache to get it compiled, I think.
I’m pretty much aware of this. I think it’s not even possible to fully compensate for the orange light without amplifying a lot of blue noise, at least with non-professional cameras. But for now, I only want to have a cooler white balance. The camera (actually a phone with RAW capability) has determined a pretty nice-looking WB using its built-in colorimeter, and had no problem at all to process the image into a JPEG using those values - and I don’t see the point why should RT, a software aimed at people with good technical understanding, be more restrictive.
OK. I haven’t used Rawtherapee that much, and I realize that’s your preferred tool, but darktable has a color zones tool that allows you to apply multiple instances with specific color and bandwidth control that might be useful for what you’re trying to do.
RawTherapee has similar functionality in the Lab* curves:
http://rawpedia.rawtherapee.com/Lab_Adjustments#CH_Curve
But the correct way to go about this is to fix the problem at the source: white balance + input profile.
Just did a little search and found a couple of resources that list numerous HPS lamps at a color temperature of 1900K - 2200K and CRI of 20-22. So going below 1500K for color temp may not help that much. This suggests to me that CRI is a greater problem than color temp.
Again, I never expected that a lower WB temperature will turn HPS into studio lighting 
But it will definitely give less yellow colors, closer to what the human eye would see after being accustomed to it. Just as it already does in the JPEG pic made by the camera app! RT is just unable to use that WB because of the restricted temperature range. I think it’s just an arbitrary limit, but in any case, a serious RAW processor like RT should not fail where a simple, consumer-grade camera app doesn’t.
@szgabor we can test whether increasing the WB range will work if you upload a sample file (not zipped), either directly here or using https://filebin.net/
Here you are: Filebin | ee0nbj3y7icp36bs
Extending the range would definitely help with the colors, as a different RAW processor with a wider range can process it correctly. The only remaining question is whether RT’s current implementation can deal with those values.
Also, you’ll notice that RT gets the image dimensions wrong, the resulting image is slightly cropped when compared to the camera-JPEG. I’ve already tried to mess with camconst.json, without success (as far as I remember, data embedded in the DNG has absolute priority???).
Hi @szgabor
Why do you think that extending the WB range would help? Here’s what I get with the current RT:
20161124_173422.dng.pp3 (10.4 KB)
Seems pretty close to the out-of-camera jpeg to me…
I agree with @agriggio, the raw looks like the JPEG.
The Channel Mixer can be used to change white balance when you want it more extreme-cold or extreme-hot:
The “distortion” caused by the WB range isn’t that big for this particular shot (I chose this one to also demonstrate the cropping problem), but you can see that the temperature slider bangs into its lower limit. Some other software can correctly handle such low, and even yet somewhat lower values - we can call it headroom, and RT should also have some of it instead of some shortcomings.
(And of course I also know that such a small color offset can be compensated for using other tools in RT, but that would be only a workaround with drawbacks, not a solution)
“The Channel Mixer can be used to change white balance when you want it more extreme-cold or extreme-hot:”
I wouldn’t call this so extreme, and no way exceptional, as HPS lamps are very common in some countries. And again, other progs like the quite simple UFRAW have even some headroom for this WB - then why should RT, a MUCH more advanced software be more limited, necessitating workarounds?
hi @szgabor, from your comments in this thread I get the impression that you are an expert user with lots of technical background on (digital) image processing. unfortunately, I am not 
you mentioned a couple of times that you have some pictures which RT gets completely wrong, as opposed to the camera JPEG and/or other raw processors. for the sake of my understanding, would it be possible to share one such pic, where the difference is clearly visible? that would really help me, thanks! (also, would it be possible to know which other sw gets it right? I might try that for reference if possible…)
edit I now see you mention ufraw
White balance limits can be changed, as long as the change is not a penalty for 99% of users for the benefit of a fringe case. That is why @agriggio’s request is important.
This screenshot shows the image using temperature=1200 and tint=0.352:
I figured the input color matrix was causing this, and disabling it improved the situation:
Ping @jdc and @ilias_giarimis
P.S. Maybe “the input color matrix was causing this” is not the right expression, as those lights might have a color spectrum which results in this.
Of course the color matrix is designed for daylight.
P.P.S. Amusing that I found a high pressure sodium light spectrum on a marijuana-growing website of all places.
P.P.P.S. Also, this is probably the first time anyone has written the word “marijuana” in this forum.
