https://ninedegreesbelow.com/ Nine Degrees Below Photograpy, Elle Stone.
Articles and tutorials on ICC profile color management and free/libre image editing. Includes a large collection of profiles.
Given the (X,Y,Z) of the reference whites of the source and destination, and cone response matrix MA and its inverse MA^-1, we calculate the linear transformation matrix M.
Lindbloom gives values of MA and MA^-1 for three methods: XYZ scaling, Bradford and Von Kries. Other methods include Sharp, CMCCAT2000, CAT02, BS, BS-PC and Fairchild.
For example, to convert from D65 to E, using the Bradford method, Lindbloom gives M:
Consider the numbers on the diagonal. Approx 1.05 will slightly increase the value in the red channel; 0.97 will slightly decrease green, and 0.918 will decrease blue. The overall transformation will make the image slightly redder.
According to Standard illuminant - Wikipedia, illuminant E is a theoretical illuminant roughly similar to D55. We can see from File:Planckian-locus.png - Wikipedia that D55 is slightly redder than D65. So this confirms that the matrix M shifts colours in the right direction.
The matrix xyz_rec2020[3][3] can be multiplied by M to give a conversion from XYZ to REC2020 with standard illuminant E.
Thanks for pointing out what happens to the colour. It reinforces the learning process. Indeed, E and D55 are similar. I hope to be able to hop between arbitrary illuminants.
Lindbloom has calculated M for our convenience. For programatic calculation, we don’t want to store all those values for M. We do need to store the white points of whatever illuminants we care about, eg from Standard illuminant - Wikipedia , and we need the cone response matrices for whatever methods we want to use.
Whenever I see a 3x3 colour transformation matrix, I ask myself: Are the diagonals approx 1.0, and the other values approx 0.0? If so, then it will cause a subtle colour change. Then, which diagonals are above 1.0 and which are below 1.0? This gives the colour shift.
And we can readily see the visual effect of the transformation (Windows BAT syntax):
rem From D50 to E.
set SMAT=^
1.0025535,0.0036238,0.0359837,^
0.0096914,0.9819125,0.0105947,^
0.0089181,-0.0160789,1.2208770
magick ^
toes.png ^
-color-matrix %SMAT% ^
x.jpg
@afre Following the maths on Bruce’s site I arrive at this (fairly straightforward) method to compute the example matrix you picked out. Note that for some odd reason, the variable name in RT is not what I expected. As I understand Bruce’s site, this matrix is used to convert an RGB value in Rec.2020 to a XYZ value and not the other way around. Maybe I’m wrong…
Anyway, here’s the maths. Forgive me for using slightly different notation… force of habit.
Pick your origin color space, here Rec.2020, and note its primaries and white point in xy chromaticity coordinates:
These values are taken from Wikipedia. The white point is D65 and therefore needs adaptation to D50. Adaptation is a simple matrix multiplication of (X,Y,Z) values with the respective transformation matrix \mathbf{M_A} (see Bruce’s table). For going from D65 to D50 we have,
So this is how I have interpreted the Bruce Lindbloom page, RGB/XYZ Matrices
The difference is that he starts with the XYZ value for white point while I start from the xy coordinates for white point too.
I believe one of us has mixed up the order of operations. In your final step you have rec2020toxyzd50=np.matmul(M,d65tod50) , so you seem to do \mathbf{M} \cdot \mathbf{M_A} while I effectively do the reverse, \mathbf{M_A} \cdot \mathbf{M}. Since matrix multiplication doesn’t commute, we get different results.
@Thanatomatic, I just had finished testing the result. It works, almost. Some problem in the mismatching face, it isn’t continuous like the other one which is not acceptable, and two, it doesn’t match. I will try with the other approach to see if it gets anywhere. Continuous output is more important on the mismatching face. In the case of no solution to this problem, I think this still can be a new filter for gmic.
I got a new challenging math question and programming question. I would like to know how to find out the number of digits from numbers concatenated with a base where the counts of number is defined in base 10.
Is this still a challenge if you found a sequence on OEIS? Edit: I didn’t look at the sequence, but tried deriving it myself. I came up with something equivalent, though the formula on OEIS seems somewhat shorter.
After some manual inspection of such base-digit-sequences, I came up with an expression for the length L of the string of concatenated digits in base b from 1 to the largest number with n digits:
T(b,n) = \frac{1-b^n-nb^n+nb^{n+1}}{b-1}
So, for example, there are T(5,2) = 44 characters in the string “12341011121314202122232430313233344041424344” and T(3,3) = 68 characters in the string “12101112202122100101102110111112120121122200201202210211212220221222”.
To find the length S of the string for an arbitrary number N in base b, we first need to know the number of digits d for that number, which is given by:
d = \lfloor\log_b N\rfloor + 1
The length of the string is shortened by (N_\text{max}-N)d digits, where N_\text{max} is the largest number with d digits, N_\text{max} = b^d-1.
We finally have,
S(N,b,d) = T(b,d) - (b^d-1-N)d
Or, to match your definition of concat_consec_digits_count, we have after some simplification and rearrangement:
@Thanatomanic I was able to find a optimized solution for element-wise subtraction with that definition of concat_conset_digits_count. It doesn’t work if N is lower than b. This is my final formula:
Is it allowed to use a semi-colon (;) like that in the middle of a ? : expression? I’m pretty sure it was forbidden back in the days when I learned C, and we would probably have used a comma (,) instead. But maybe the C standards have evolved since then?