- From: Andrew Somers via GitHub <sysbot+gh@w3.org>
- Date: Wed, 08 Sep 2021 01:12:15 +0000
- To: public-css-archive@w3.org
Hi Chris @svgeesus,
Thank you for in depth reply. I do think there are some misunderstandings regarding my position, please let me clarify:
> _A few responses:_
> _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._
## D65
Yes, nearly all monitors and devices are D65. I haven't seen a 93K monitor since I gave them to Goodwill a decade ago LOL.
- Even when working in pre-press for a D50 output, the monitors are normally calibrated for D65.
- DCI P3 is 6300K and essentially a closed ecosystem for digital cinema. Apple's Display-P3 is D65.
- ACES is sort of an odd bird...
- There is a white point listed, but it's not a standard illuminant
- And while you can say it's close to 6000K,
- The academy is careful to state that the white point is _not dictated as the neutral axis_, leaving that up to the filmmaker.
- Also, the ACES spaces are intended as working spaces (or archival), not delivery spaces.
- ProPhoto at D50 is also not a display space, having imaginary primaries.
- It's huge (like ACES) so it requires 16 bit.
- I remember a few years ago here asking why it was added as one of the default spaces for CSS, as it carries with it a few potential troubles which I'll get into a little later.
> _...However, introducing an (adequate, not the best) Bradford CAT step has an utterly imperceptible effect. See the example in CSS and print.... where the entire round-trip errors are below 0.1 deltaE2000._
Except for dark blue on that link... which is the portion of the gamut that often gets clipped between D50 and D65. And sure, if you don't clamp values and do work in signed 16 bits or more, you may be able to round trip — but for what utility? That's like driving around the block to use up that pesky gasoline in the tank.
#### _If you are working in D65, and your destination is D65, then stay in D65._
And regarding ProPhoto, one of the interesting mapping issues is how red and blue can go negative when transforming to another space, and it's exacerbated transforming to D65. Regardless, I do use ProPhoto for pre-press as it allows working in RGB without clipping for a CMYK deliverable, and working in RGB is preferred for things like compositing.
### Working or Display?
So, part of my confusion here regards working vs display or delivery spaces. When I think of web content, I think in terms of delivery and display (perhaps the rare printing of something). I don't think in terms of a separated working space that then needs to be transformed on demand to a particular display.
Maybe I am missing something here then?
-----
## The Great LAB/LUV Debate
> > _LAB is better suited to reflective surfaces. LUV has advantages for displays._
> _I'm astonished to see this hoary-old argument from 1976 resurrected, ....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._
I notice you don't like hearing this commentary regarding CIELUV. I suppose my background in Television (and lighting) is part of my bias. And to be really super clear, I don't dislike LAB, nevertheless if we are talking about accuracy, then __CIECAM02__. I do recognize the LUV is not as prominent in recent years — but I'd venture it is not supplanted by LAB but by CAM02 and CAM16.
But moreover, __this is a key misunderstanding in terms of what I find LUV is useful for__, as a simple uniform color model of additive light and including self-illuminated displays.. You're talking about apples, I'm squeezing orange juice.
LUV is used in data visualization, used by the US military for specifying illuminants, underlying technology for Tektronix color grading gear, and sure, CAM02, CAM16 etc are compelling reasons... to leave LAB also. All that said, CIELUV has some specific useful applications, and it's not a "dead sea space."
> _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 LUV comes out second worst..._
It is well known that LUV is not useful for reflected or surface colors. I am not disputing that at all. Luo's study you cited was relative to his work with LLAB, and in it associated with that diagram, it is explained this is a test of complex images (Z score), and further they state: _"It can be seen that the results for CIELUV are much worse, and for CIELAB significantly worse, than for the other formulae and models;"_
I am also not talking about surface or reflected colors, nor complex images.
Again, the reason I brought up LUV is as a useful space or method for:
- Selecting a CSS color.
- Creating gradients.
- Adjusting a CSS color.
__And I did not suggest it to replace LAB.__ I suggested it as, if you support LAB, you are already half way to supporting LUV, with just a little extra code.
Also, there is a very useful LUV color tool for the web here: https://www.hsluv.org and it has the interesting feature of showing the limits of the sRGB gamut as you use the tool.
Also as a side note, I seem to remember someone asking about NCS recently. Here is NCS mapped to CIELUV for Computer displays:
https://www.sciencedirect.com/science/article/abs/pii/014193828790062X
___ADDITIONAL SUPPORTING:___
> ### _FROM COLORIMETRY (2007)_
> _...1976...CIELUV and CIELAB...It was hoped that only a single space and formula would be acceptable; but it proved impossible to meet both the requirements of those in the television industry (who wanted an associated approximately uniform chromaticity diagram, as provided by the uʹvʹ diagram in the CIELUV system), and those in the colorant industries..._
> _The absence of [a] chromaticity diagram in the CIELAB space [means no] saturation. In the CIELUV space, the measure S<sub>uv</sub> = C<sup>\*</sup><sub>uv</sub>/L<sup>\*</sup> provides a correlate of saturation..._
AND
> _Currently, the CIELUV system and its related quantities are the best visually-uniform color space for additive colors accepted for international use....the gamut of achievable colors on a CRT lie in the most uniform region of the u′, v′ diagram. Furthermore, because the CIELUV system is based on the CIE u′, v′ parameters, it provides the same advantages to video-based implementations._
> _Downloaded from Digital Engineering Library @ McGraw-Hill_
AND
> _...volume of the gamut in CIELUV space is successfully used as an optimization criteria for colorimetric filter design.
> The CIELUV color space is recommended by the CIE for applications that uses additive color mixtures, while the widely adopted CIELAB color space is a better choice for surface color measurement, e.g. printed products. Since this is an additive color system, the primary performance criterion for the filter selection is chosen to be the volume of the color gamut in the CIELUV color space... Barco, Daniel Nyström 2002-05-08_
### Today in 2021, LAB and LUV are weak compared to CIECAM02 and CIECAM16.
Nevertheless, both LAB and LUV have plenty of utility, in particular they are much simpler than the full CAMs.
## Whatabout LUV
The reason I am suggesting the addition of LUV is for its useful Lsh (Lightness Saturation Hue) space, arguably saturation is a more useful control for color selection and gradients than chroma. Also, I showed earlier some examples how LUV presents smoother and more uniform gradients. LUV is not prone to the blue purple shift. Here are some examples:
Let's start with a monochromatic set of gradients. In these images, the top four are polar coordinates, and the bottom four are cartesian coordinates.
**TOP: Regular HSL, LUV Lsh, LUV LCh, LAB LCh**
**BOTTOM: sRGB, CIExyY, CIELUV, CIELAB**
<img width="628" alt="Screen Shot 2021-09-07 at 7 13 32 AM" src="https://user-images.githubusercontent.com/42009457/132427199-7df80d8a-14b0-43fe-9022-07f61a02224a.png">
This one is basic, most spaces perform similarly for a simple gradient like this. Notable, the xyY is washout as it is linear, and the upper left HSL is a bit over saturated comparatively.
Also pay attention to the top, second from the left, the Lsh — LUV's Lightness/Sat/Hue... you'll see it is the most consistent and most even overall.
Next slide
<img width="628" alt="Screen Shot 2021-09-07 at 6 17 55 AM" src="https://user-images.githubusercontent.com/42009457/132427867-eb710d31-b3dc-4151-8604-28695edd4ba2.png">
Here we see the infamous purple shift in LAB. Notice that LUV does not have such a shift.
Next Slide
<img width="628" alt="Screen Shot 2021-09-07 at 6 58 52 AM" src="https://user-images.githubusercontent.com/42009457/132427984-465ff511-f0d6-4303-8c25-b5cbf87cffde.png">
The purple shift in LAB continues to be an issue.
ALSO notice that sRGB is noticeably darker and that the HSL is being more colorful than the rest, but also uneven.
Next Slide — Colorful!
<img width="628" alt="Screen Shot 2021-09-07 at 7 02 33 AM" src="https://user-images.githubusercontent.com/42009457/132428188-82f9abab-35a8-4b42-bca7-af4670f54eb7.png">
In this case, the "hue rotation" direction was reversed, so the color palette of the top row is suddenly more colorful.
ALSO: the HSL gradient isn't doing to well. The sRGB is still a bit dark, and LAB is still polluting other colors with purple.
The LAB LCh is a bit out of whack — but the LUV plots, especially Lsh are still demonstrating consistency
Next slide
<img width="628" alt="Screen Shot 2021-09-07 at 6 47 18 AM" src="https://user-images.githubusercontent.com/42009457/132429227-62d76033-46b5-4038-a3b6-fd2d976efde0.png">
t Slide
Last one... what's going on? a pure blue to achromatic gradient can demonstrate unexpected behaviors. Notice the LAB plots and their shifts, but the LUV plots are still doing well with expected behavior.
### Misc Advantages
> _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._
Interestingly the military specifies u'v' for colored lighting such as in a cockpit. But as far as out of gamut, look at that hsluv.org implementation.
Another advantage of LUV is that it does not have that **noticeable blue->purple hue shift that is a problem with CIELAB**.
And a big advantage, which is why it is used in dataviz so much, is it can handle saturation in addition to chroma. This is also very helpful for color choosing, gradients, etc.
Though also, I've been experimenting with the saturation polar of LUV, Lsh, and while there are cases where colors go out of gamut for a gradient, simply clipping the sRGB values does not seem to be particularly noticeable. On the other hand, CIELAB has that purple shift for anything with blue in it.
-----
## D50
> _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._
There is no compatibility issue here.
Photoshop is the only app I know that "forces" D50 for LAB editing mode, and the PS implementation is of marginal utility. Krita, RawTherapy are not limited to D50, Gimp's LAB implementation is a little odd but does not enforce D50.
Nor should they. ___CIELAB is not tied to any specific illuminant.___ It was only "stuck" with D50 in the ICC PCS, for v2 and v4 ICC profiles. But ICCmax (v5) is no longer forcing D50 either.
Per the CIE, D65 (and A) are the standard illuminants. But _any_ can be used with LAB.
> _The cost of one or two adaptation stages is very minor and non perceptible, if done correctly._
The cost can be substantial for dynamic content especially streaming as I've mentioned. Not that streaming content is color managed, as it normally is not, and for reasons like these. But there is increasing dynamic content.
It takes next to nothing to not force it and simply allow inclusion of standard D65.
function XYZ_to_Lab(XYZ,wp="D65") {
var white = (wp=="D50") ? [0.96422, 1.00000, 0.82521] // D50 reference white
: [0.95046, 1.00000, 1.08906]; // D65 reference white
> _The cost of using Lab with an unknown adaptation state, or using unadapted colors with the wrong adaptation state, is significant and easily seen._
But it's not unknown. If it's web content, it's sRGB and D65. And using D50 does nothing to help that.
If people are going to use LCh for choosing colors, those colors are going to display on a D65 monitor or device. (Though my point with LUV is that it's a better space for choosing colors or gradients using Lsh<sub>uv</sub>.)
### Eye See Sea
> > _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._
__Woah, I never said that.__ I know ICC profiles have wide uses. It is ___illuminant D50___ that is used by print/graphic arts, while other industries including paper, ink, textiles, autos, etc etc use D65. I did not say ICC is "entirely print oriented" though that is definitely the bias, and so stated in ICC white papers.
> _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......._
Okay, this is good to know, but not apparent. The CSS Color 4 document mentions ICC profiles 47 times, and makes no mention of any form of LUT nor the more specific OCIO or other technology.
> _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._
I am being misunderstood, I sent you a DM to hopefully clear this up. Though to add, it has nothing to do with CIELUV, and yes I am aware that LUV is not a good choice for CAT, again, my suggestion for LUV related to CSS color selection and gradients.
> _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._
Okay, then I'd like to suggest that some mention of alternate methods be included, as at present the document relies on ICC, and it presents the impression that it's all about ICC profiles.
### What initially caught my eye
As an example, here's the paragraph that raised my eyebrows, being ever so slightly hand wavy...under section 9 on LAB:
> ... ___The illuminant is D50 white<sup>1</sup>___ , a standardized daylight spectrum with a color temperature of 5000K....D50 is also the whitepoint used for the profile connection space in ICC color interconversion, ___the whitepoint used in image editors which offer Lab editing<sup>2</sup>___ , and the ___value used by physical measurement devices such as spectrometers, when they report measured colors in Lab<sup>3</sup>___ ....
1) CIELAB is not specific to any illuminant.
- CIELAB is illuminant independent, just as it is device independent.
- The LAB math has specific inputs for reference whitepoint to accomodate this flexibility.
- CIE Recommends D65, but any illuminant can be used.
- D50 is used in print and graphic arts, historicaly derived from Kodak/photo printing.
- There is discussion about shifting this in industry.
- ICC v5 profile, ICCmax, accomodate other illuminants for the PCS.
- Other industries use D65, notably paper and ink indistries (LOL) also textiles, automotive, paint...
2) Photoshop is the only editor that forces LAB (and probably can be changed in a setting file), the other image editors are flexible, as they should be, not locked to D50.
3) Spectrophotometers are available in any number of illuminant standards, and again there is no restriction for any given illuminant to be used with LAB.
> _Turning to a couple of ICC-related points:_
> > _ICC CMS is a processor hog._
> _You do realize there is more than one implementation, right?_
Sure, I've been working with ICC profiles and countless implementations since circa 1993 (ish).
> > _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.
The print industry does use ICC profiles in some workflows, but technologies like G7, CxF, PQA-S etc. are a bigger component for major jobbers. Native code and automated/integrated systems seem the norm or 4 to 8 color offset printing.
When I send in a book layout to a printer, the PDF I send has been prepared & soft proofed using either SWOP coated or GRAcol. But the presses are all about calibration — the ICC workflow means I can work at my home studio, but still be in alignment with the printer, calibrated to the common standard. (Yet still occasional surprises, LOL).
> _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:_
If LCh<sub>ab</sub> is being used to color choosing, then it does not make sense to force D50 into a workflow that is otherwise D65, meaning CSS and web content. There is no benefit, and there is no compatibility issue. Though again, I am going to make the case for a uniform __Lsh<sub>uv</sub>__ for a color selector, if not CIELUV, some CAM...
> * _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._
I agree with this at least in part. While it is computationally most efficient to convert directly from one RGB space to another, especially with the same whitepoint, using XYZ as an RGB conversion space lends flexibility at the expense of some performance, if that's what you mean?
LAB is not a great choice for RGB -> RGB due to the performance hit and greater difficulty mapping gamuts... but LAB is a often a good choice for RGB -> CMYK (and the mandated choice for CMYK with ICC).
> _One last comment_
>
> > _Try using Lab but...blue-purple shift..._
>
> _It isn't, because it is unrelated to adaptation. It is inherent in CIE Lab._
Yea not sure what I meant to say there so much, I think I meant "made worse by" since it is blue that can take a beating in some CAT or other transforms... such as how ProPhoto blue or red can end up as negative (or more negative) when transformed from D50 to D65.
> _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._
LAB goes to cone space using "wrong Kries", but this leads to the conversation regarding the utility of transforming into cone space as a practice to model tristimulus displays with very narrow bandwidth primaries.
CIELUV also does not do the purple shift. LUV is not in cone space, it's in "illuminant space" which is convenient for self-illuminated monitors... 😳
All for today,
Thank you,
Andy
--
GitHub Notification of comment by Myndex
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6061#issuecomment-914761114 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 8 September 2021 01:12:19 UTC