Regarding doing matrix multiplication, itâs associative so you can multiply (A* B) * C or A * (B * C) and the result is the same either way. But not any three random matrices can be multiplied. If you plan on doing much matrix math, itâs worth doing a bit of reading, maybe starting with Wikipedia, but there are wonderful websites that will walk you through all the basics, if you do a little searching on the internet.
Iâve never used gâmic for doing matrix math, but here are two other options iIf all you want to do is multiply a few matrices together and calculate a few inverses:
Also you can do matrix math using openoffice or libreoffice. Neither is fun to use, setting up the specific matrix math is fiddly. This article has a downloadable spreadsheet that is set up to calculate the sRGB D50-adapted ICC profile from the sRGB color space specs, and so has examples of using a spreadsheet for matrix math, including doing Bradford chromatic adaptation:
Regarding Bruce Lindbloomâs equations, as far as I can tell they are first rate, never had any reason to doubt their accuracy.
Regarding Lindbloomâs pre-calculated adaptation matrices and his XYZ values for D50-adapted sRGB ICC profile and similar adapted profiles, he uses different D65 and D50 white point values than the sRGB color space specs D65 values and the ICC profile specification D50 values.
So of course Lindbloomâs calculated values arenât the same as youâd expect if you used the values actually in the various relevant specifications. More information is here:
Sadly some profile vendors seem to feel free to just make up whatever D65 and D50 values they want, leading to a plethora of profile variants for what are suppose to be âthe sameâ profiles. If you really want the correct values âby the specsâ values for RGB to XYZ for sRGB profiles, use the matrix that you can make from my sRGB profilesâ XYZ RGB channel values, or else look at ArgyllCMS sRGB.icm channel values.
But keep in mind the XYZ channel values for my profiles and for ArgyllCMS profiles have been modified to make well-behaved profiles - the difference between pure calculations and whatâs needed to make a well-behaved ICC profile are small:
Iâm not an expert at doing matrix math, but it really helps if you work through some simple examples to get an idea of whatâs going on, and check your results using the bluebit website.
I just wish I had some handy link to the tutorials I followed a long time ago, Anyone else have some good links to âget startedâ matrix math tutorials?
The downloadable spreadsheet I referred to has pretty good annotations. Iâve used it as a template for doing other sorts of matrix math related to color space calculations, using other color spaces, even as a basis for setting up RGB to XYZ to LAB and such. But honestly I have no interest at all in plugging in numbers for someone else or checking their math . Even thinking about doing matrix math gives me a headache!
The matrix multiplication site you gave works perfectly I get the result that I was expecting.
Which is to multiple the last matrix by the first.
XYZ â sRGB times Cameraâ> XYZ.
The result I was expecting was BTW:
1.872 -0.792 -0.076
-0.197 1.639 -0.444
0.028 -0.548 1.518
I have a follow up question if my destination is sRGB, what should its white point be? I had expected it to be D65 but the Rawtherepee code has it is as D50 and also an example I am following is the same. i.e. what is the white point for the viewing environment?
D50 for ICC profile calculations. For viewing environment, unclear what you mean - the lighting in the room? the color temperature of the monitor white point?
In a regular file without an ICC profile, say as example a jpg encoded as sRGB, what is the white point assumed to be? I had guessed D65, but looking at the RT code it suggests D50. The spec seems to suggest D50 as the viewing environment but I got confusedâŠ
ICC generally uses D50 for various reasons (that some people might debate). As long as your app and / or OS has some colour management and can handle ICC profiles properly, it is not a concern.
As for the gmic command, perhaps you are using a version a little too antiquated. Update to a newer version and try again.
On the ICC web page for ICCMax, they cite the D50 illuminant as âfixedâ for V4, âto ensure interoperability and prevent ambiguity in colour transformsâ. Now, I have both D50 and D65 (owing mainly to dcraw conventions) ICC profiles in my profile âzooâ, and the LittleCMS library seems to handle the chromatic transition nominally.
1.7.9 is antique in gmic terms . There have been lots of improvements since, the one youâre missing there is ârunâ which avoids many shell escaping headaches.
As stated already multiply the two in the same order you would use them individually (I had no idea you pasted in reverse of usage, sorry). In gmic you can reverse them with a simple ârvâ at the right point - quicker than reorganising the numbers:
gmic run "(0.7446,0.2074,0.0134;0.2772,0.9656,-0.2429;0.0269,-0.243,1.0402) (3.1338561,-1.6168667,-0.4906146;-0.9787684,1.9161415,0.0334540;0.0719453,-0.2289914,1.4052427) rv mmul +invert"
If you are talking about rounding errors from floating point math, thatâs very important to keep in mind and can produce catastrophically different results given appropriately chosen input values. But I think issues with floating point calculations isnât exactly germane to the current discussion - yes? no? I mean unless one were unfortunate enough to start with the wrong input values!
Yes but what about a file that does not have a colour profile and is using the default sRGB values, what is the correct viewing environment expected to be D50 or D65?
For example when RT reads a plain TIff and assumes the values are sRGB what value for illuminant is assumed?
in order to get the correct result it has the last matrix that would be applied last as the first one in matrix multiplication, (if I am to get the same result as the example).