- From: Chris Lilley via GitHub <sysbot+gh@w3.org>
- Date: Fri, 03 Sep 2021 15:12:41 +0000
- To: public-css-archive@w3.org
A few responses: > Measurements of anything displayed on a monitor use D65. When working directly in XYZ or Lab for film color correction, we are also working in D65 (if not 6300K or 6000K per some newer colorspaces). Never D50. It is true that most RGB spaces use a D65 illuminant. The common exceptions are ProPhoto (D50), DCI P3, and ACEScc. It is also true that un-needed chromatic adaptation (adapting, then adapting back) should be avoided for computational efficiency and round-trip precision reasons. However, introducing an (adequate, not the best) Bradford CAT step has an utterly imperceptible effect. See the example in [CSS and print: using calibrated CMYK and other printed color spaces](https://drafts.csswg.org/css-color-4/#cal-cmyk) where the entire round-trip errors are below 0.1 deltaE2000. > LAB is better suited to reflective surfaces. LUV has advantages for displays. I'm astonished to see this hoary-old argument from 1976 resurrected, given the amount of experience we have gained with these two systems since then. Lab is widely used, everywhere; there are better models, especially if viewing conditions and surround effects can be precisely controlled. Luv is occasionally mentioned as being standardized at the same time and is otherwise ignored in most textbooks. It is well known to give por predictions of color appearance. But it has been studied. Here for example is a figure from Luo, L and Kuo "The LLAB(l:c) Colour Model", Color Research and Applications, 21:6 1996. It is showing LUV significantly worse than all the other systems studied:  Here, figures showing the prediction of Munsell hue and chroma. LUV comes out second worst, and is the worst colorimetrically-based model (HSV came out worst, and was presumably included only for comic effect). LUV  Lab  Lab is bettered by CAM16-UCS  and by Oklab  For compatibility (with Krita, or Gimp, or Photoshop, or any other software or hardware that uses Lab) Lab in CSS Color 4 assumes a D50 adaptation. The cost of one or two adaptation stages is very minor and non perceptible, if done correctly. The cost of using Lab with an unknown adaptation state, or using unadapted colors with the wrong adaptation state, is significant and easily seen. The one advantage of CIE LUV over CIE Lab is the associated chromaticity diagram, because 2D diagrams are easier to show and to understand and because color mixtures being on straight lines rather than curves makes for simple explanations, and because the _u'v'_ chromaticity diagram sucks less than the _xy_ chromaticity diagram. Both, however, will erroneously show out of gamut colors as being apparently in-gamut. A 3D representation avoids this. > ICC CM is not always ideal, and it is not the only choice, either. 1. The attempt to position ICC as entirely print-oriented is false. For example, I am active in the Display and the HDR working groups of ICC; I am not active in the Medical Imaging WG, nor in the Graphic Arts WG. Of those four, one is related to printing and the other three are not. 2. CSS Color 4 does not mandate ICC as the implementation method. Indeed, the (non-ICC) sample code is right there in the spec, while the associated ICC profiles are tucked away in a subdirectory and not even linked from the spec. The sole use of ICC profiles (outside of CMYK and CMYKOGV examples) is as one possible way to get better interop when faced with 'device-cmyk`. Of the two full implementations of CSS Color 4 that I am aware of, one uses direct conversion code and one uses a mix of ICC profiles, and direct conversion to Lab. 3. Your aversion to ICC seems to rest on a mixture of technical concerns (adaptation to D50, which admittedly works poorly in CIELUV as Luo shows, but is otherwise unproblematic) and political (assumptions on non-neutrality) which I won't address here. 4. The WPT tests for CSS color 4 present a set of colors (in various color models) and equivalent sRGB colors and simply require them to be correctly parsed and presented as visually indistinguishable. Feel free to use OCIO, ICC, or native code to do that - the tests don't care and don't know what was used. Turning to a couple of ICC-related points: > ICC CMS is a processor hog. You do realize there is more than one implementation, right? > Device manufacturers love things that force people to upgrade One of the advantages of the ICC model (particularly for embedded industrial systems) is that the implementation is installed once, verified once and not upgraded; because re-verification is super costly. This is why the print industry doesn't typically use native code. They can't afford to _ever_ upgrade, let alone _constantly_ upgrade. Anyway, the reason I responded to this thread now is that, while Lab in Color 4 is and will remain D50 adapted, for compatibility, a native code implementation will need several types of XYZ: - white-relative, D65 adapted - white-relative, D50 adapted - (if it does HDR) absolute, D65 adapted - (if it does ACEScc) absolute, ACES-wp adapted - (if it does DCI P3) white-relative, DCI-wp-adapted The question is which of those to expose to users. For completeness, they can all be exposed. For a minimal surface API across the Web platform, it is probably better to expose only one; and for that, I agree that **white-relative, D65 adapted XYZ** is looking like a better bet for an API. This would mean that CSS Color 4 would also need to switch to exposing that one. One last comment > Try using Lab but STAY in D65, then see if the blue-purple shift is reduced or eliminated It isn't, because it is unrelated to adaptation. It is inherent in CIE Lab. Here is a plot of circles of constant CIE deltaE2000 in CIE Lab. The elongation is obvious, and the fact that the axis of the ellipses in the blue region is not oriented towards the neutral axis is the cause of the purple shift. (the over-estimation of chroma differences at large chroma in Lab is also visible in this plot).  (From Lissner & Urban (2010) "How Perceptually Uniform Can a Hue Linear Color Space Be?", 18th Color Imaging Conference, Final Program and Proceedings, pp.97-102) Color models such as IPT, ICtCp, Jzazbz, or Oklab which map to a cone-related space before applying the non-linear transfer function do not exhibit the purple shift. -- GitHub Notification of comment by svgeesus Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6061#issuecomment-912612004 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 3 September 2021 15:12:44 UTC