- This topic has 3 replies, 2 voices, and was last updated 8 years, 8 months ago by
.
-
Posts
-
I have always calibrated my display to D65, and verified that the white point is indeed quite close to D65 from Calman of verification session of dispcalGUI. However, when I tried to profile it using a matrix+curves option, the profiled white point is always far from the intended value. For example, this time it’s 6734K. In the correlated temperature session of verification, almost all white points are around D65 (+50K), so it is unlikely that 6734K is an average. Is there any reason that the CM engine choose a white point that is neither the calibration intended white point nor the actual white point measured after the calibration??
Also I notice there are two many XYZ trimulus of display RGB under different tags in the profile. ‘Colorants (PCS-relative)’, ‘RGB column matrix (both illuminant relative and PCS-relative)’ and ‘chromacity (illuminant-relative)’. I know the PCS-relative always refer to D50 equivalents transformed via a Bradford chad, but the weired thing is values from these three categories are not consistent even with chad. The values from column matrix are connected by a chad from 6734K to D50, which I have verified. The ‘chromacity’ surprisingly records almost the exact measured xy values of the display, but since they don’t have Y values for each primitive, it does not decide the white point.
The next thing i found is the nominal values (XYZ) used in verification of such a profile, are actually the first ones from ‘colorants (PCS-relative)’ if relative is selected or ones chad-transformed to 6734K if absolute is selected. But I vaguely remembered once these values seem to be from ‘R/G/B column matrix’ !!! This confused me quite much since they provide such ambiguity in define the color space and what’s worse, neither of these two is the correct one! The correct coordinates from ‘chromacity’ can only be verified by measuring and do not participate at all in color space transormation !
So here is the thing, strange white point coming from nowhere, strange matrices coming from no where yet contradicting each other…. Does this have anything to do with calibration settings? I always do some of it by adjusting the display itself and leave the rest to video card LUT.
P.S, I got the intended D65 in the profile and mostly consistent matrices by choosing XYZ-LUT type profiling. But I still prefer the matrix type.
- This topic was modified on 2015-08-15 05:35:37 by vrships.
[…] when I tried to profile it using a matrix+curves option, the profiled white point is always far from the intended value. For example, this time it’s 6734K. In the correlated temperature session of verification, almost all white points are around D65 (+50K), so it is unlikely that 6734K is an average. Is there any reason that the CM engine choose a white point that is neither the calibration intended white point nor the actual white point measured after the calibration?
The matrix (rXYZ/gXYZ/bXYZ) is not just the primaries. For matrix profiles, the primaries are only (if at all) encoded in the chromaticity tag and colorant tag, which are informational tags (metadata). The matrix itself a best fit model to reduce the overall color errors in conjunction with the tone response curves. If the display is not behaving very additively this can result in sacrificing grayscale neutrality for overall color accuracy. Note that this ONLY applies to matrix profiles, so the solution in that case is to create a (XYZ) LUT profile as you did.
But I still prefer the matrix type.
Why?
Thanks for the reply, Florian.
The matrix (rXYZ/gXYZ/bXYZ) is not just the primaries. For matrix profiles, the primaries are only (if at all) encoded in the chromaticity tag and colorant tag, which are informational tags (metadata). The matrix itself a best fit model to reduce the overall color errors in conjunction with the tone response curves. If the display is not behaving very additively this can result in sacrificing grayscale neutrality for overall color accuracy. Note that this ONLY applies to matrix profiles, so the solution in that case is to create a (XYZ) LUT profile as you did.
So what is the information provided by rgbXYZ besides the primaries, and what are the data that is actually used by a CMS to determine the transformation across color spaces? And still I don’t understand the discrepancies of XYZ values between these metadata (with bradford considered). As I understand it, the simplest CMS only requires the XYZ or Yxy values of three primaries (255,0,0， etc.) , and an overall single gamma value to perform any colorimetric transformation, assuming that graphic single-channel LUT has taken care of all the greyscale imbalance and nonlinearities with a minimized sacrifice in contrast. Is this correct?
Why?
Matrix-based seems to give the best compatibility. And I found sometimes XYZLUT “overcorrected” some colors and produce “kinks” at certain RGB values. Once in Calman I did a test where most of the colors <1 DE, while a few shows DE greater than 2.5, but these colors are well within the gamut of my calibrated display and can be reproduced more accurately if I use a matrix-based profile.
- This reply was modified on 2015-08-23 06:51:52 by vrships.
So what is the information provided by rgbXYZ besides the primaries, and what are the data that is actually used by a CMS to determine the transformation across color spaces?
Thes rXYZ/gXYZ/bXYZ tags are defining the profile colorspace, but as I said, those do not necessarily match the actual primary locations (because that would in some cases make for a poor profile). The model that Argyll CMS employs tries to find a matrix + curves that gives the best overall fit to the measurement data.
And still I don’t understand the discrepancies of XYZ values between these metadata (with bradford considered).
The ‘colorant (PCS)’ values are derived from the actual profile, so the model that it was derived from is taken into account. You can get the exact same values by doing an
xicclu -ir -pXon the profile. The ‘Chromaticity (illuminant-relative)’ values on the other hand are taken directly from the measurement data, so don’t take into account the profile.As I understand it, the simplest CMS only requires the XYZ or Yxy values of three primaries (255,0,0， etc.) , and an overall single gamma value to perform any colorimetric transformation, assuming that graphic single-channel LUT has taken care of all the greyscale imbalance and nonlinearities with a minimized sacrifice in contrast. Is this correct?
For a perfectly additive, well-behaved display with a ‘perfect’ zero black, that would work, but not so much for most real-world displays.
Once in Calman I did a test where most of the colors <1 DE, while a few shows DE greater than 2.5, but these colors are well within the gamut of my calibrated display and can be reproduced more accurately if I use a matrix-based profile.
I’m not sure, but does Calman even have the capability to verify an ICC profile? I was under the impression that any ICC profile is basically ignored, and the only thing that affects verification results is the videoLUT. I may be wrong though (not a Calman user).
Overall, the default XYZ LUT profiles created by DCG are a bit more accurate than a simple curves + matrix profile, as an example the results with 750 point verification set on a pretty well-behaved display (that should work well with matrix profiles):
- Matrix + curves 73 patches: Avg dE 0.4, max 2.45
- XYZ LUT with ~400 patches: Avg dE 0.38, max 2.24
- XYZ LUT with ~580 patches: Avg dE 0.34, max 1.66
For less well-behaved displays, the differences in favor of the LUT profiles will be bigger. Note that increasing the amount of patches for matrix profiles does not have as much beneficial effect to the profile accuracy, while for LUT profiles more patches = (usually) more accurate.
- This reply was modified on 2015-08-24 19:08:20 by fhoech.
