libraw 0.20.0 returns incorrect D65 multipliers and rgb_cam for ERBG file

Hi,
I noticed that for the Sony F828 that has an ERBG sensor, the Daylight white balance multipliers returned by 0.20.0 is 2.094020 0.917032 1.222377 0.000000. However, on 0.19.5, the values are 2.094020 0.917032 1.222377 1.203671.

Similarly rgb_cam on 0.20.0 is
1.6726 -0.5983 -0.0743 0
0.0080 1.4036 -0.4116 0
0.0046 -0.4089 1.4043 0

but on 0.19.5 it is
1.6374 -0.2528 -0.0035 -0.3811
0.0672 0.8224 -0.5306 0.6410
-0.0009 -0.3551 1.4153 -0.0593

Is this expected?

Regards,
Dinesh

Forums: 

Your message subject: libraw

Your message subject: libraw 0.20.0 returns incorrect D65 multipliers and rgb_cam for ERBG file

Could you please clarify why you call 0.20.x data 'incorrect'?

What values do you think are correct and why?

-- Alex Tutubalin @LibRaw LLC

0.20.0 behaviour

Alex,
This file has four distinct sensors. However, when the multiplier for E is marked as 0, this would indicate that the E component is being discarded. Same with the rgb_cam having 0's for the E component.

I noticed that the cam_xyz is the same as the F828 entry in the adobe_coeff table is the same. This indicates there is a change in how the rgb_cam and hence the Daylight multipliers are derived in the code.

That being said, the 0.19.5 version has a very strong yellow cast on the image but the image definitely looks better in 0.20.0. Please find attached screenshots in the same drive location as above. I assume the 0.20.0 is the expected behaviour.

Regards,
Dinesh

I also think the new version

I also think the new version is better.

That is why I do not understand why it was called incorrect.

-- Alex Tutubalin @LibRaw LLC

BTW, I strongly suggest to

BTW, I strongly suggest to update to 0.20.2. raw-identify in 0.20.0 may display rgb_cam incorrect.

-- Alex Tutubalin @LibRaw LLC

Thanks!

Alex,
Apologies for jumping the gun and reporting the issue in 0.20.0 as a bug. I just saw that my tests had failed and assumed a regression. But I agree that 0.20.0 behaviour is better.

I will upgrade to 0.20.2 for the updated raw-identify behaviour.

Regards,
Dinesh

rgb_cam for Sony F828 matches 0.19.5 value

Alex,
I am upgrading to 0.20.2 and I noticed for this file, the rgb_cam value matches that of 0.19.5 instead of 0.20.0.

The raw-identify output on 0.20.2 has the following:
Camera2RGB matrix (mode: 1):
1.6374 -0.2528 -0.0035 -0.3811
0.0672 0.8224 -0.5306 0.6410
-0.0009 -0.3551 1.4153 -0.0593

which matches 0.19.5 (see comments above). Is this intentional?

Regards,
Dinesh

I cannot understand your

I cannot understand your question. You complained 0.20.0/raw-identify displays incorrect data for some color matrices. We fixed that in 0.20.1/0.20.2. What exactly is the problem?

-- Alex Tutubalin @LibRaw LLC

Thanks!

Alex,
I understand there is no "right" answer when rendering an RGB image from CFA data. The images in 0.20.0 and 0.20.2 look quite similar (no opinion on which is better, they both look good).

I wanted to confirm that the changed value in 0.20.2 was expected and not accidental because it matched the values from an older behaviour.

Regards,
Dinesh

The problem was in raw

The problem was in raw-identify printing code, not in data.

-- Alex Tutubalin @LibRaw LLC

The issue is not raw-identify

Alex,
I debugged my code and actually looked at the rgb_cam values in memory and they are different between 0.20.0 and 0.20.2. You can check the values I have posted in my first post.

The google drive link above has the RAW file. You can confirm this at your end.

Dinesh

OK, may be, too lazy to check

OK, may be, too lazy to check.

Is something wrong with F828 colors and LibRaw 0.20.2?

-- Alex Tutubalin @LibRaw LLC

Not at all

The colors look fine. I have posted the image in the google drive link in my earlier post (f828_srgb_0.202.png). The image is different from 0.20.0 but does not appear bad or malformed.

Please confirm if the change to rgb_cam is expected.

Dinesh