Changed the limit for color temperature, now white balance is wrong when using a camera profile

Software RawTherapee
5

Not sure I fully understand then. Should it not work with an external camera profile then if it is an issue with handling the embedded profile? The external profile corrects the colors, except for artificial lighting when the color temperature hits the lower limit.

6

My guess is that it has something to do with how your phone produces the DNGs. The internal software may not really conform to the standards or do something funny.

7

That is well possible. The sensor uses an RYYB filter, so I would not be surprised.

Any input on why my own builds mess up the colors when using a camera profile, no matter what DNG? Even if I don’t change anything and just build stable 5.8, the colors on DNGs come out wrong. The installed version downloaded works just fine with the same files.

I am pretty confident extending the color temp range would be a workaround for me, but for that my builds need to work…

8

That basically explains everything. RawTherapee and darktable both assume a RGGB filter array. The “greens” are actually yellows, so the color is way off.
At the moment there is nothing that can be done about this, except to submit a sample to https://raw.pixls.us and file bug reports for camera support here and here. No guarantee that anything will happen with it any time soon though…

9

The embedded profile is properly used to decode the colors, but not to compute the color temperature. The color temperature is only an interpretation of the WB coeffs × color profiles. It’s really just a code path to add, the case has simply not been planned.

10

RYYB or RGGB is the same. First of all, none of them is what they say (there is no green, blue, red, yellow or whatever, it’s only arbitrary spectral slices), but then the mechanics are the same : multiply channels by wathever coefficients you have. If you have the right coeff for the right channel, you absolutely don’t care about what this channel is.

1 Like
11

I did not test, but one reason for this issue might be, that RawTherapee always uses the D65 matrix inside a DNG file (if available). Maybe for this kind of files it would be better to use the Standard light A matrix (which is available in this file btw.) ?

12

Is there a way I can test it myself?

13

Search dcraw.cc for

         if( get2() != 17 ) // 17 is Standard light A

and replace it with

         if( get2() == 17 ) // 17 is Standard light A
2 Likes
14

I’ll give it a shot. Problem is that my own builds are all borked right now, so I need to figure that one out first.

15

So this changes something. Colors are different and Temerature/Tint are read out as 1706/0.173 rather than 1500/0.87. Very promising!

Now the only problem i am left with is that my own builds don’t work properly.

Stable build, downloaded online: https://i.gyazo.com/63b5477eec8c933b7cbcec9ee5b31cf1.jpg
My own build of the latest data, no modifications: https://i.gyazo.com/c6552f7906d609b2f5c6ba88b4733bb8.jpg
Build with the modification as suggested above: https://i.gyazo.com/191274d92f3fd3aa732852749d6ffefc.jpg

You can see that there is a weird purple tint on my own builds. Any ideas how to fix that? This is my first time building anything, so it might just be a silly rookie mistake. I build for Windows 64 bit, simply following the guide on RawPedia.

16

Did you build using gcc 10.1? That’s a known issue. Just downgrade to 9.3

Edit: for reference:

17

It works also with gcc-10 of you disable the optimization option from the quoted bug.
Compiling with fno-tree-loop-vectorize is fine

18

I know that, as it was me, who bisected the compiler flags to that point. Though I don’t think we want to disable this vectorization…

2 Likes
19

Sure, it’s just a quick fix for the OP in case he cannot roll back the gcc. I have the problem because i compile on Windows with msys2. Once gcc was updated, I could no longer rollback.

20

I’m on msys2 as well. Rollback is no problem on msys2

21

Interesting, it did not want to do it for me. Can you please share what procedure have you followed to rollback?

22

Sure, do you still have gcc 9.3 in /var/cache/pacman/pkg/ ?

ls /var/cache/pacman/pkg/
23

yes, it is still there:

ls /var/cache/pacman/pkg/ | grep -i gcc-9.3
mingw-w64-cross-gcc-9.3.0-1-x86_64.pkg.tar.xz
mingw-w64-x86_64-gcc-9.3.0-1-any.pkg.tar.xz
mingw-w64-x86_64-gcc-9.3.0-2-any.pkg.tar.xz
24

pacman -U /var/cache/pacman/pkg/ mingw-w64-cross-gcc-9.3.0-1-x86_64.pkg.tar.xz

Same for the other files, should revert it then

1 Like