Raw-embedded color matrices not used

[Beep6581]

Originally reported on Google Code with ID 2119

A few formats have color matrices embedded in the raw file itself. Dcraw parses out
those and puts it in "cmatrix". In original dcraw the +M parameter must be used to
employ this instead of a hard-coded default, and the hard-coded default is usually
coming from Adobe Camera Raw. RawTherapee always uses the hard-coded default, ie cmatrix
never gets used.

I don't know if that is good or bad, but it is something we should look into. I would
guess that a better strategy would be to use the embedded matrix always rather than
never, which would mean that we strive to reproduce the manufacturer's view of the
camera color rather than Adobe's.

Reported by torger@ludd.ltu.se on 2013-12-11 12:28:08

[Beep6581]

Phase One's iiq is one of those formats, and original dcraw had no hard-coded defaults
for those at all, leading to bad color in rawtherapee for those formats. This has now
been fixed with tables in camconst.json (tables come from Adobe Camera Raw), but probably
a better strategy would be to get the matrix from the format itself.

Reported by torger@ludd.ltu.se on 2013-12-11 12:29:40

[Beep6581]

It's strange that dcraw has chosen to privilege ACR's values over the manufacturer's
ones. I agree with you, manufacturer's one should be privileged.

Reported by natureh.510 on 2013-12-11 14:47:14

[Beep6581]

But what if dcraw/acr ones are better? Do we need a new choice entry or should we use
camconst instead?

Reported by natureh.510 on 2013-12-11 14:53:35

[Beep6581]

Need to do some tests before knowing. For example it could be the case that the embedded
color matrix will require a manufacturer-provided ICC too to lead up to sane color.

Reported by torger@ludd.ltu.se on 2013-12-11 15:58:10

[Beep6581]

Anders, thanks for opening this issue it's my request also (from long ago).

I would prefer a new choice entry or, to be exact, just enable the "use embedded if
possible" option which now is disabled for raw files.

The embedded matrices (Olympus and Phase one) are in different format than Dcraw currently
use but I have success copying the multipliers in channel mixer (use "no profile" and
sRGB working space for supported by dcraw (D65 matrix exists) models or camera when
not.

A couple of times I measured these matrices (in channel mixer) and was worse than Adobes
D65, but maybe I have to retry with different working color space ..
I think that possibly the matrices depend on the used (in-camera) color space and the
WB multipliers also ..

I still cannot find a way to translate the manufacturer matrices (and those from DxO
whitche are in the same format) to dcp format so hopefully this can be solved now.

May be a look in libraw code could help as they recently updated the method to use
Olympus's color data .. "correct Olympus color data conversion"
http://www.libraw.org/news/libraw-0-16-beta1

Reported by iliasgiarimis on 2013-12-12 02:12:54

[Beep6581]

Question: Does this issue also apply to DNG Raw files or only to other formats?

Reported by stefan.ittner on 2013-12-12 10:16:33

[Beep6581]

Hmm .. DNGs complicate my preference for "use embedded if possible" because sometimes
there are two embedded matrices,
- in exif data there are the default Adobe dcp matrices from which RT already uses
the D65 one (when loading DNGs RT use this embedded instead of it's internal)
- For Olympus DNGs exists in maker data the manufacturer matrix which is not used.
For Phase one Adobe deletes the maker data after conversion to DNG.

One more manufacturer who provides embedded color matrix is SONY in *.ARW files. Same
as with PhaseOne's after conversion to DNG the manufacturer matrix disappears (together
with many more maker tags). 

Reported by iliasgiarimis on 2013-12-12 14:01:11

[Beep6581]

Investigating in Olympus maker metadata one can see that the embedded matrix is not
always the same. I cannot come to a conclusion yet if the changes depend on some in-camera
settings or it's due to different firmware version ..

Reported by iliasgiarimis on 2013-12-14 18:04:07

[Beep6581]

I'd suggest that for DNGs you get the DNG matrix, it's the responsibility of the DNG
converter to put a good matrix there.

I've looked at Leaf and Phase One files which both have embedded matrices, for Leaf
you can use it directly, seems to be about or exactly the same as Adobe's default matrix
though. For Phase One there's some processing needed, colors are totally wrong if used
directly. This is probably a dcraw IIQ parsing bug though, as the cmatrix is intended
to be compatible with rgb_cam.

Anyhow, it seems like if we enable this we need to do it per format and make sure it
works for it.

I made some code that "if rgb_cam is not set, ie an identity matrix, and cmatrix is
set, then use cmatrix", but it would make Phase One files look worse than using the
identity matrix so I did not check in that code. Now we have Phase One matrices in
camconst.json anyway so they will look good.

Reported by torger@ludd.ltu.se on 2013-12-16 07:20:58

[Beep6581]

Anders hi,

Can you describe the calculations needed to translate those Olympus embedded matrices
(and those from DxOMark under "color response" tab) in dcp format ?. I'd like to do
some measures ..

For both these formats I have relatively good result copying the matrices in RT's Channel
Mixer after normalizing DxO's base 1.0 or Oly's base 256 to RT's base 100, and use
sRGB as working color space. 

Example from DxO, Nikon Df under D50 illuminant http://www.dxomark.com/Cameras/Nikon/Df
(tab color response) 
WB multipliers
R raw   2.14
G raw   1
B raw   1.56

Color matrix as defined in ISO standard 17321   
        R sRGB  G sRGB  B sRGB
R raw    1.65   -0.55   -0.10  (all lines sum to 1.00)
G raw   -0.09    1.34   -0.25
B raw    0.05   -0.40    1.35

Example from Olympus EM-5 maker data http://www.imaging-resource.com/PRODS/olympus-e-m1/EM1hVFAI00100.ORF.HTM
RawDevColorspace = sRGB
WBmultipliers (AsShot)= RBGG 496 386 256 256
WBmultipliers (5300K)= RBGG 502 396 256 256
WBmultipliers (6000K)= RBGG 542 362 256 256 (5300K & 6000K look to be the better matches
(among predefined WBs) to the "AsShot")
WBmultipliers (6600K)= RBGG 574 386 256 256 (I put this just in case D65 WB needed
to "match" sRGB specs)

Matrix
R 370  -92 -22 (all lines sum to 256)
G -44  352 -52 
B   8 -128 376

Reported by iliasgiarimis on 2013-12-16 11:34:30

[Beep6581]

Deleted my last comment here, it was rubbish, wrote before thinking... I'll get back
to you :-)

Reported by torger@ludd.ltu.se on 2013-12-16 12:45:48

[Beep6581]

heh, third attempt, I think I reversed the multiplication, BxA instead of AxB. Unlike
ordinary multiplication matrix multiplication is not commutative. Forgot about that.

As you see I'm no matrix master... so use this at your own risk. When it comes to color
math I always test and view and adjust my code to get it right, I often do mistakes
when I just code it straight up like this.

The C program is hopefully easy to understand even if you don't code C, it's only matrix
multiplication and inversion you do. You can probably translate it to excel if you
know how to do matrix math there.

You'll find lots of conversion matrices in rtengine/iccmatrices.h, and if you want
do do some matrix math you can use http://www.bluebit.gr/matrix-calculator/ it's a
quite good web matrix calculator

Reported by torger@ludd.ltu.se on 2013-12-16 13:25:08

---

• Attachment: test3.c

[Beep6581]

forgot;

compile: gcc -Wall -o test3 test3.c -lm

current output:

matrix: { { 1.949274 -0.525979 0.014507}, {-0.438410 1.250824 0.092924}, {-0.306079
0.223455 0.801412} }
"dcraw_matrix": [ 19493, -4384, -3061, -5260, 12508, 2235, 145, 929, 8014 ]

Reported by torger@ludd.ltu.se on 2013-12-16 13:26:35

[Beep6581]

Thanks Anders,

I asked you to "describe" not to program in these cryptic :) c language :)
because I feel easy with excel matrix math but not with c 

As you give the result I think I'll manage to translate .. and crosscheck the result

Reported by iliasgiarimis on 2013-12-16 17:37:58

[Beep6581]

#17: did you get this to work?

Reported by torger@ludd.ltu.se on 2013-12-18 17:57:39

[Beep6581]

No not yet. I'll try tonight

Reported by iliasgiarimis on 2013-12-18 21:24:09

[Beep6581]

Issue 2185 has been merged into this issue.

Reported by entertheyoni on 2014-01-20 05:10:40

[Beep6581]

Finally .. for the needs of supporting new models with camconst.json I managed to translate
DxO's matrices to dcraw format

As David insisted http://code.google.com/p/rawtherapee/issues/detail?id=979#c40
( David complicated things by inverting - dividing by WB multipliers -reinverting ..)

On DxO_D50 matrix ..
we need to first multiply the 1st column by the red WB coeff. and the third column
by the Blue :)
We take the DxO_D50_WB

Then matrix-multiply the sRGB_D50_to_XYZ X DxO_D50_WB (don't reverse the order I did
it and things went wrong ) 

sRGB_D50_to_XYZ (lindbloom)
0,4360747 0,3850649 0,1430804
0,2225045 0,7168786 0,0606169
0,0139322 0,0971045 0,7141733

then Matrix-inverse the result and multiply by 10000 for dcraw format :).
I tested this with Sony ILCE-6000 and Nikon D5300 cc24 raws. 
The measures show that the result is a matrix which gives DE2000 around 2.5 ,  same
as with Adobe's D65 colormatrix which dcraw uses by default ..

Reported by iliasgiarimis on 2014-04-18 01:20:38