- From: Andrew Somers via GitHub <sysbot+gh@w3.org>
- Date: Tue, 02 Mar 2021 02:37:12 +0000
- To: public-css-archive@w3.org
Myndex has just created a new issue for https://github.com/w3c/csswg-drafts:
== [css-color] Discussion of Conflicts & Resolutions: D50/D65, LAB/LUV, ICC/OCIO ==
**It is with some trepidation that I am posting this issue. I'm going to be expressing viewpoints that are counter to some of those listed in CSS color, and indeed counter to those of some individuals who I have the greatest respect and admiration for.** This presentation is based on decades of experience in the Hollywood film and television industry, which is clearly related to interactive web content.
## Statement of Purpose
I am posting this in the hopes of avoiding some dark alleys that could have negative consequences in the future development of web content (including HDR). We experienced similar difficulties in the film and television industry during the transition from analogue and chemical media to digital. We can avoid those kinds of pitfalls here, and it's easy to do so. It's simply a matter of avoiding a forced or "Baked in" approach.
**_Conflict of interest statement:_** I am an invited expert with the W3 and AGWG. I am not affiliated with any outside party or stakeholders. Myndex is my IP holding entity, nevertheless nothing in this post is related in any way to the R&D I am doing for Silver/WCAG 3.0, the APCA.
I mention this as I have concerns regarding the corporate agenda of certain stakeholders. I feel strongly that some of these positions are not in the best interests of the W3 as an objective standards organization, nor the best interests of the world at large. No standard here should help any particular stakeholder's marketshare, meaning standards must be flexible and open, not constrained.
### What's at stake
**I am very supportive and excited by the new technologies being developed,** and we should definitely be incorporating them provided we also recognize the potentials for harm. There are 7.8 billion people in the world, most do not have access to the newest and most expensive technologies. Also, some newer technologies make major advances in image fidelity for people with normal vision — but at the expense of being less accessible for some people with certain impairments.
This means a key consideration must be fallbacks, and in particular accessible fallbacks. It also means that "mandated" standards take the route of minimum processor load — if a proposed feature has a potential high cpu load, there needs to be a low-overhead fallback as well. Not to mention that some technologies/features are only available in higher end devices — co-opting these into standards may be useful, but the standard then must provide for alternates and fallbacks.
-----
## CONFLICT ONE: D50 vs D65
### The Standard is D65, including for LAB. _It is not D50._
Per the CIE, D65 and Illuminant A are the only _standard_ illuminants, inclusive of all CIE colorspaces. D50 is not the standard illuminant for any industry except the printing industry. Even the paper and ink industries use D65, and CIE pub 15 clearly states that D65 should be used for everything (including Lab). D50 is used for the v2 & v4 ICC PCS as ICC color management is designed in favor of the physical print industry.
Arbitrarily forcing LAB into D50 is bad practice when the source, working, and destination spaces are all D65. Certainly, D50 can be an _available_ WP/Illuminant — but it should never be forced, and neither should needless transformations which increase processor load without purpose, not to mention creating other issues related to gamut mapping, clipping, and other unexpected behaviors.
For an interesting thread on this specific subject, [please see this article.](https://pressmanacademy.wordpress.com/2019/07/19/d50-lighting-for-printers-and-d65-used-by-paper-companies/)
### Specific points of response
- 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). Never D50.
- D50 is used in the printing industry, a migration from the photo-print industry. It is not in use in other industries. While incorrect to use D50 with colorspaces or display technologies that use D65.
- Spectroradiometers are typically calibrated with Illuminant A, a blackbody radiator about 2850K. They report results as W/cm². They do not use D50 and they do not use LAB — LAB is not about colorimetry as much as about predicting appearance.
- D50 is not usually a calibration source, though there is a recently developed spectrophotometer that uses an array of 7 LEDs to create a D50 source specifically for print industry use, that's not common.
- As for ICC compatibility, D50 can certainly be "available" but should never be forced. The dubious benefit of ICC compatibility will be discussed later.
### Side note: Round Trips and Gamut Mapping
**Whether or not a round trip is successful is not that relevant. Processor load is very relevant.**
For instance XYZ is an unbounded infinite linear space that allows for imaginary primaries, so you can transit it (with invertible matrixes) with no round trip loss. But round trip errors are not the issue. **The issues are performance, gamut mapping, clipping, etc.**
Lab is not unbounded, uses the “wrong Kries” transform, and sure may be large enough for sRGB to transit without much harm sometimes… but not always. And it is computationally expensive to needlessly add chromatic adaptation transforms. Lab has some use as a working space for adjusting color, selecting color, gamut mapping: but let me ask you, _does it make sense to gamut map in D50 and then transform to D65?_
**_No, you’d never want to do that._**
You’ll find this even more the case using larger working spaces, especially linear, that can exceed Lab. HDR breaks bounded spaces. If your destination is D65, and your source is D65, everything should be D65.
The ICC use of D50 in PCS is nothing but a “reference point” and as I mentioned, not that relevant for the XYZ pcs, and software typically collapses such transforms so going from sRGB to display P3 does not cause that horrid of a performance hit. To be discussed further in the ICC section.
-----
## CONFLICT TWO: LAB vs LUV
### LAB is better suited to reflective surfaces. LUV has advantages for displays.
And even then there are newer appearance models that have further advantages. Of course performance is again important, so the use of the more complicated models will cause additional processor load.
Both LAB and LUV are very simple appearance models. LAB is useful for small differences in color of reflected surfaces. LUV is not as useful for that case, but LUV has advantages over LAB when it comes to color on self illuminated displays.
**How is web content delivered? On self illuminated displays.**
### Now let's compare the two:
In this image, we compare the LAB and LUV hue angles at maximum saturation for sRGB. This was created sending the colors into a CIELAB or CIELUV processor and reading the reported hue angle, and selecting the sRGB hex values at 5° increments for LAB and LUV. Hue was shifted to line up the top at red.
<img width="812" alt="image" src="https://user-images.githubusercontent.com/42009457/109571993-576cbf00-7aa1-11eb-8ad3-c09059c00e05.png">
As can be seen, the LUV hue angles are better distributed across the total color palette. Of course, color does not have an "angle", but using an angle for hue is a convenient way for humans to adjust color to their perception. For use with an LCh type of colorpicker, you want a hue distribution that is more consistent with perception of the colors on a display, and that's Luv, not Lab.
I am not saying that LAB should not be offered — but I am saying that disregarding LUV is an error, and LCh using LUV is a best practice for the use case of web content and CSS colors.
**Luv is superior to Lab for _choosing_ CSS colors**
- Luv has both saturation and chroma available, and is more stable in this attribute.
- Lab has only chroma, and is not stable in regards to hue.
- Luv's more even color distribution means the hue control in LCh<sub>uv</sub> has a more uniform and intuitive effect.
- While I am still conducting tests, Luv appears to be much better for gradients and additive non-linear color mixing.
- The fact that Luv is more stable in hue make it a better choice for "color adjustment" than Lab.
- This is not to say there are not other alternatives ever better that Luv, but Luv beats Lab in these areas.
- Luv is computationally simpler than Lab, as Luv has fewer exponents
On this last point, LUV is simpler than LAB. They both use the identical math for ` L* ` But Luv is literally just the 1976 UCS with some simple scaling:
Take this chromacity plot then make Y into L* and you've got Luv. Just in time for spring. _Awww_.
Luv does have some scaling relative to the UCS in that u and v are each multiplied by ` 13L* ` but for LCh, the **_exact same math is used for Luv as for Lab_**. In other words, if you have an implementation that uses Lab, the **only code needed to add Luv is:**
u = 13.0 * Lstar * ((4.0 * X) / ( X + 15.0 * Y + 3.0 * Z) - 0.19783982482140775648);
v = 13.0 * Lstar * ((9.0 * Y) / ( X + 15.0 * Y + 3.0 * Z) - 0.46833630293240970476);
// D65 constants
### Regarding "popularity"
There have been some statements that Luv is never used and Lab is more popular. Not only are these statements not particularly relevant, they are not really true.
YES: Lab is very popular for surface/reflected colors. And Lab is used as the PCS for CMYK conversions in ICC, and also in a certain product from A Dough Bee (and Adobe is a major influence at the ICC). None of this means Lab is "best" only that it is used in ways that are highly visible.
**But don't discount Luv.** It has wide adoption in industries and applications where the measured color is self-illuminating as opposed to reflective/subtractive. Luv is common in the television industry, and lighting, and the uv plot is MilSpec for use with spectroradiometer results. Also, LUV is often "hidden" behind commercial products, for instance Tektronix's color correction system TekHVC uses Luv as the basis, with a minor modification to the C value, and aligning hue 0• with "best red". There are [web-oriented LChuv projects]( https://www.hsluv.org) out there as well.
I delve deeper into this in this Gist: [Where's The Luv?](https://gist.github.com/Myndex/47c793f8a054041bd2b52caa7ad5271c)
In short, adding D65 Luv is trivial, and advantageous.
- The hue of LCh<sub>uv</sub> rotates on the vertical axis from the white point in the 1976 UCS.
- Easy to visualize
- Might help replace the 1931 chromacity diagram with the 1976 UCS (finally!)
- Useful existing pre-gamut mapped Luv->CSS interfaces exist NOW.
- A second polar notation, Lsh offers saturation rather than Chroma
- Using Luv for SDR has a better chance of forward compatibility to HDR than Lab.
- SGI already developed an HDR variant, LogLuv
- Something I'm working on: LCh<sub>uv</sub> _may_ be able to give a better prediction of helmholtz kohlrausch, but there is more work to do there.
-----
## CONFLICT THREE: ICC vs OCIO or LUTs
### ICC CM is not always ideal, and it is not the only choice, either.
**When Apple, Adobe, and the rest, formed the ICC and created ICC color management, they did a great thing. It is what made real desktop publishing possible. Nothing I say below should diminish the importance of these achievements, and the still very useful ICC workflows for the printing industry.**
### BUT
Web Content is not the printing industry. Film and Television is not the printing industry. And as it happens, what is a good workflow for desktop-to-physical-print is not necessarily going to be a good workflow for other use cases. **And the ICC readily admits this, saying:**
> _"Where trade-offs are necessary, the preference has been to serve the needs of applications in graphic arts and desktop publishing. For this reason the PCS definition is biased somewhat toward scenarios that result in output to reflection-print media such as offset lithography, off-press proofing systems, computer-driven printers of various kinds, and photographic paper."_
Adobe tried to shove ICC into film and television with disappointing even disastrous results, when they added ICC to AfterEffects circa 2008. Today no one serious uses ICC CM in AE, instead using LUT based workflows [such as Open Color IO](https://opencolorio.org). In 2018 Adobe added ICC as an option to Premiere, which is also not particularly useful, and left unused.
**Why? Many reasons one of which is ICC introduces increased processor load.**
### SO?
Who cares about processor load? If you are just working on a big desktop workstation with static images or pre-press pages intended for print, you might not think much of the substantially higher CPU/GPU overhead for using ICC CMM. But what about those on mobile devices? And what about those working with streaming media?
As an example, on one of my 12/24 core Xeon systems with 96GB RAM, nVidea cards and thousands of cuda cores, turning on ICC CM prevents real-time playback of 2K frame sequences, which play fine with ICC off, and using instead OCIO.
The reality is that in terms of distribution, streaming media normally does not use profiles at all — the media has a specific color grade baked in that is relative to the expected display/environment. The display is (assumed) calibrated to a particular standard. This is a completely different workflow than for desktop print.
Now, the way things are evolving, it is clear that some form of transform is going to be needed as there are now multiple color spaces, multiple devices types, and legacy and new media forms.
Performance is STILL going to be crucial, so ICC is simply out of that picture (pun more or less intended, sorry). A->B direct LUTs (no PCS, no added transforms, etc). OCIO is a library that can help here.
And this presents up with ideas for best practices for workspaces too. I discuss that in the companion Gist to the above link:
[**Will Work For Color: Color Manglement and Working Spaces.**](https://gist.github.com/Myndex/10caff6a68e844591e83eadeebfb4347)
-----
# Path Forward
As I hope everyone knows, I don't complain and then wander off. I believe in a proactive approach, and seek to offer solutions to any problem or concern I raise. Unlike the monumental task of finding a contrast appearance model, the solutions here are simple and easy.
## _Solution ONE_
**D65 is the standard, and should be the default for everything.**
Transforms in and out of D50 can be available for the limited use cases that might arise.
## _Solution TWO_
**Add Luv, LCh<sub>uv</sub>, Lsh as available spaces/notations**
The math and implementation is trivial as an add-on to Lab, the results are demonstrably superior for the use case of a self illuminated display, and an HDR variant already exists.
## _Solution THREE_
The ICC is a consortium of corporate interests that may not always have the widest/best interests of our world of 7.8 billion people. As an independent standards org, we need to promote balance, and ensure that no one is excluded through forced obsolescence.
ICC profile support should never be a _mandate_ for web content. Nevertheless it can be supported, but consideration must also be given to the harm that can be caused such as the increased processor load on mobile devices.
If ICC profiles are supported, then open LUT standards such as OCIO *must* also be supported. Not just to provide balance, but because a LUT workflow is a better workflow for most use cases involving web content, not to mention use cases involving streaming or VR content.
## TL;DR
**1) D65**
**2) Luv**
**3) ICC U L8 R**
Thank you all for reading. You may commence throwing tomatoes and lettuce at me now.
> _"Why do people always bring lettuce and tomatoes to a speech?"_ - The Penguin
Thank you,
Andy
_Andrew Somers_
_W3 AGWG Invited Expert_
_Myndex Color Science Research_
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6061 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 2 March 2021 02:37:15 UTC