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:
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 …