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/
1 Like
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:
20161124_173422.dng.pp3 (218 Bytes)
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:
The image had the green hue you see in the screenshot. I could not get the light color to look white no matter what white balance combination I tried, it’s as if it went from hot (red) to cold (blue/green) never passing white.
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.
1 Like
Ok, as soon as I return home I’ll look for a better example.
What I don’t undetsand is why should a wider WB range (already present in certain other SW) be a penalty for anyone on the planet? The slider would be harder to use? That’s already only good for coarse adjustment I assume, lowering the lower limit to 1000 (that should be enough I assume) won’t make it noticeably worse, or will it?
(I know the wide range+fine adjustment problem very well, I faced a similar one with my RGB+W controller - but found a solution that took some work to implement, but it’s really cool and pleasant to use now. I’m ready to help as much as I can, but have almost no knowledge on Linux stuff, this is also the rason why I didn’t attempt to change it for myself.)
It wouldn’t, but in this case it seems not only a problem of WB range (as you can see in the screenshot provided by @Morgan_Hardwood where he used a modified RT version which allows temperature < 1500)
Yeah, now I get it (I’m using a small-screen device now, it’s easier to overlook things).
Again, I never intended to neutralize it! People saying that HPS is a very poor light source are completely right, no WB will ever get it truly neutral - especially without severely distorting other light sources.
I don’t want to do the impossible - only render it like a human would see at that spot, with somewhat accustomed eyes. A little cooler WB would mostly do the job, then further adjustments can be made if needed. Once the temperature slider doesn’t bang into its limit when using the cam-WB for the RAW I posted, instead has a little headroom, RT will be fully HPS certified
So, I played with this a little bit. This is one way of getting a bit more headroom. Probably not the only way, and quite likely not the best way, but it does allow to get a cooler temperature for the picture using only the WB settings and no other “trick”.
Here’s a screenshot:
And here’s a (quick and dirty) patch showing what I did. Essentially, I added some “slack” on the cool end of the temperature range which gives you some “headroom” when setting a custom wb, and extended the range of the blue/red equalizer (which was also hitting the limits for this particular picture).
Comments welcome, especially from people who actually know what I am doing 
diff --git a/rtengine/colortemp.cc b/rtengine/colortemp.cc
--- a/rtengine/colortemp.cc
+++ b/rtengine/colortemp.cc
@@ -29,6 +29,13 @@
#define CLIPQQ(a) ((a)>0?((a)<250?(a):250):0)
#define MAXR(a,b) ((a) > (b) ? (a) : (b))
+#undef MINEQUAL
+#undef MAXEQUAL
+#undef MINTEMP
+#define MINEQUAL 0.5
+#define MAXEQUAL 2.0
+#define MINTEMP 1000
+
namespace rtengine
{
@@ -122,7 +129,7 @@
void ColorTemp::mul2temp (const double rmul, const double gmul, const double bmul, const double equal, double& temp, double& green) const
{
- double maxtemp = double(MAXTEMP), mintemp = double(MINTEMP);
+ double maxtemp = double(MAXTEMP), mintemp = double(MINTEMP)+500;
double tmpr, tmpg, tmpb;
temp = (maxtemp + mintemp) / 2;
diff --git a/rtgui/whitebalance.cc b/rtgui/whitebalance.cc
--- a/rtgui/whitebalance.cc
+++ b/rtgui/whitebalance.cc
@@ -31,6 +31,13 @@
#define MINEQUAL 0.8
#define MAXEQUAL 1.5
+#undef MINEQUAL
+#undef MAXEQUAL
+#undef MINTEMP
+#define MINEQUAL 0.5
+#define MAXEQUAL 2.0
+#define MINTEMP 1000
+
using namespace rtengine;
using namespace rtengine::procparams;
Ouch, as I wanted to show a better example, I had to realize that the problem affects only the RAWs from this camera phone, and for RAWs from my “real” cameras RT’s WB range is more than enough! The white balance range doesn’t need to be changed, the problem roots elsewhere!
Actually, the photo I posted is the first HPS illuminated scene I found to be good enough to be shown to people, and the others had never been processed before. This is why I hadn’t noticed that RT has no problem with them, and values around 1900 already pseudo-neutralize the orange color. It’s a camera support issue, not a general problem with RT!
Therefore I’m sorry for being so careless on investigating the problem (I was in a hurry), and for being so self-confident with my mistake!
Might be just the color matrix that doesn’t play well with this particular light source, as @Morgan_Hardwood said? For example, I tried with a DCP profile for the Galaxy S7 that comes with the Adobe DNG converter (supposing it is close enough to a “proper” one for your phone), and auto WB gives me this:
1 Like
Hi everybody,
Yes as Morgan wrote it’s the color matrix used which is problematic. Because it happens that for this smartphone’s DNGs
- the colormatrix1** (D65 … ) is unusually different (too much) from Colormatrix2 (standard light A) … RT currently uses the D65 matrix only and adapts to other light temperatures (Bradford adaptation ?) … but because the behaviour of the camera is too much different under low temperature light the adaptation fails … so consiquently the WB calculations (temp/tint calculated from raw WB multipliers and colormatrix D65) also fail.
I think for such cases it would help to be able to use dual illuminant
** the illuminants are in reverse order in LG’s DNGs … Adobe uses colormatrix2 for D65
I modified (with exiftool) the exif in the sample DNG (both colormatrices set to illuminant A) https://filebin.net/ee0nbj3y7icp36bs/20161124_173422-A.dng … RT’s temp/tint are sane 
BTW … interesting things happen when we use CIECAM2 with “RT + CAT2 output” enabled and temp/tint set to default RT’s values …
2 Likes