Hi steve
Regarding the RGB coordinate values of the absolute error EOTF, I don't know if it's my calculations or if there is indeed an error in the colourspace zro, as shown in attachment 1, the measured XYZ coordinates are converted according to the target colourspace (rec709 and the white point of 126.2247 132.804 144.6316) to obtain linear RGB values ( 1.00686296355603, 0.998835775138023 , 0.99131864499517), are significantly different from the chart's coordinates, and don't look like rounding differences. (I noticed that the G-value of the chart is just equal to 1. Was G-value normalization performed? But there's no need to change the original data, right?), but even when I scaled the G-value normalization (1.008036545, 1, 0.992474108), it's still not the same as the chart value, especially the R-value, but it's still not the same as the chart value.
Also after a linear RGB calculation (0.966575364, 0.955392653, 0.947386334) for the 250/255 grayscale points, and a normalized scaling for maximum brightness (0.967701987
, 0.956506242, 0.94849059), which is even further from the Annex 2 chart coordinate values.
Is this a problem with the ZRO calculation? Or is there something wrong with my algorithm?
If there is a problem, there will be problems with other charts that reference linear RGB.
This linear RGB conversion algorithm is validated in calman and there are no errors, so I don't think it's a problem with the conversion calculation!
Of course, if colourspace has other optimized algorithms, I'd appreciate any help in solving the problem.
Thank you!