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.

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 or 6000K per some newer colorspaces). Never D50.
D50 is used in the printing industry, a migration from the photo-print industry. It is not in use in other industries (interestingly, the paper and the ink industries use D65). It is incorrect to use D50 with colorspaces and display technologies that use D65, unless the destination is D50. For the web the destination is 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 one 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 of illuminants, and 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.

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_uv 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 out there as well.

I delve deeper into this in this Gist: Where's The Luv?

In short, adding D65 Luv is trivial, and advantageous.

The hue of LCh_uv 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_uv 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:

ICC: "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 the freely available Open Color IO. 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.

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. Because 6000K is also a standard for some emerging content standards, it should be supported as well.

Solution TWO

Add Luv, LCh_uv, Lsh as available spaces/notations

The math and implementation is trivial as an addition to LAB support, the results are demonstrably superior for the use case of a self-illuminated display, particularly for color selection and adjustment, 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 (W3) 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. Certainly 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. The ICC use case is desktop-to-print. The web workflow is mainly desktop-to-desktop/mobile.

If ICC profiles are supported, then open LUT standards such as OCIO need to be supported as well. 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

+1 just for sheer effort. This is well beyond my level, but in terms of whether this sort of CSS could be converted to PDF:

Lab space in PDF allows specification of white point, so D50/D65 are both possible.
Excepting ICC profile based colors, any other CIE space is necessarily converted to Lab when converted to PDF. This seems to work well enough for LCH, the process would work as well for Luv. Obviously performance isn't as much of an issue for us as we're not doing it at 30fps.

Lab is not unbounded

Purely for my education, can you help me understand why this is? Although normally clamped for practical purposes, as far as I'm aware neither L, a or b have a theoretical bound, and the transform between Lab and XYZ is lossless, discounting implementation rounding. lab() in css-color-4 has a lower bound of 0 on L but that's it. Is that significant? I am most definitely not a color expert, just an engineer. What have I missed?

Hi Mike @faceless2 Thanks for commenting.

+1 just for sheer effort.

Well, thank you...

This is well beyond my level, but in terms of whether this sort of CSS could be converted to PDF:

Lab space in PDF allows specification of white point, so D50/D65 are both possible.

Excepting ICC profile based colors, any other CIE space is necessarily converted to Lab when converted to PDF. This seems to work well enough for LCH, the process would work as well for Luv. Obviously performance isn't as much of an issue for us as we're not doing it at 30fps.

Um, I don't understand what you are either asking or saying, or the point or relevance?

Depending on the type of PDF, it can use many different colorspaces and color models, including inside the same document for different elements.

As for performance: performance is an issue for page loading on mobile, for streaming anywhere, for animation etc etc.

Again, I don't understand what you are trying to say?

Lab is not unbounded

Purely for my education, can you help me understand why this is? Although normally clamped for practical purposes, as far as I'm aware neither L, a or b have a theoretical bound, and the transform between Lab and XYZ is lossless, discounting implementation rounding. lab() in css-color-4 has a lower bound of 0 on L but that's it. Is that significant? I am most definitely not a color expert, just an engineer. What have I missed?

0 is a bound. In production environments and various working spaces, colors can be negative, and need to be in some compositing operations. If clipped, there can be ...uh... unexpected color mayhem.

Officially, L* is bounded 0-100. There have been experiments in extending this for HDR with mixed results.

Lab TIFF, Photoslop, ICC profiles are integer, and I can assure you integer implementations of Lab are most definitely bounded, and most definitely not lossless. Lab is also a grossly inefficient code space, only ~35% of code values map to real colors, and there is STILL gamut clipping.

If the implementation uses floats, then sure, theoretically not "that" bounded other than 0. But it is also not linear, it's perceptual, and so if it exceeds perception, where are we? The practical bound is when exceeding the human gamut, and then you're in no-man's land.

Here's a deeper dive for you: http://brucelindbloom.com/index.html?LabGamutDisplayHelp.html#IntegerLab

And especially: http://brucelindbloom.com/index.html?RGB16Million.html

Please let me know if you have additional questions....

Thank you!

Andy

Thanks Andy. Rendering CSS colors to PDF is an area I know; all I was saying there is that what you've proposed looks implementable in PDF - as in, if someone gave me some CSS with Luv color or Lab referenced against D65, I could store that color in PDF with no loss (where L is clamped to 0..100, but all components are generally represented as floats)

All I was trying to establish is whether there was some theoretical bounds on Lab that I was unaware of that didn't also apply to XYZ. It's true enough that it's represented as a 16-bit value in ICC profiles, although of course that's how ICC does everything, including XYZ. I realise this was part of your "side note", so all fine and now I consider myself better educated :-)

Hi @faceless2

"All I was trying to establish is whether there was some theoretical bounds on Lab that I was unaware of that didn't also apply to XYZ. "

AH, this is an easier question to answer.

YES, there are different theoretical bounds. XYZ (and linearized RGB and other linear tristimulus models) are models of LIGHT as light exists in the real world, and can be unbounded. (Light is an unbounded physical phenomenon.)

LAB is NOT a model of light. it is a model of PERCEPTION, and therefore bounded at least to perceptual limits.

I think that is the best way to describe the difference.

All I was trying to establish is whether there was some theoretical bounds on Lab that I was unaware of that didn't also apply to XYZ.

XYZ has a theoretical non-negative bound (but in practice, enforcing that affects round-tripping so should not be done).

Lab has a clear bound at L=0 (but again, round-tripping is enhanced if that is not enforced) and is defined to be relative to the current adapted white at L=100. That implies that specular whites should be at L > 100, so CSS Color 4 carefully allows values > 100; but it is not clear that the cube-root L power law is appropriate above media white.

a and b are theoretically unbounded. Some implementations impose arbitrary limits. One notable implementation enforces 128 to -127 which arbitrarily clips real, useful colors. Pointers surface gamut exceeds that, for example; and real-world content can easily have colors outside the surface gamut.

Hey Chris @svgeesus

but it is not clear that the cube-root L power law is appropriate above media white.

I have been exploring a lot of this lately as I really would like to understand why "middle contrast" is not at all the same as the accepted "middle grey" ... cube root is increasingly less accurate above 100, and is also less accurate in the mesopic range — under 4.0Y in particular actual sensitivity seems closer to log.

If you want to play around with some of the experiments, there's a "research mode" at the SAPC dev site, and you might find the "middle contrast" experiment interesting.

https://www.myndex.com/SAPC/

I really would like to understand why "middle contrast" is not at all the same as the accepted "middle grey" ... cube root is increasingly less accurate above 100, and is also less accurate in the mesopic range

This is just the breakdown of Weber's law, no?

Its (one of the reasons) why many EOTFs have a linear portion near zero, and also why HLG uses a gamma law to media white and a log law above.

I am presently, increasingly of the opinion that "L* is not super useful for self illuminated displays."

You don't say why.

For sRGB, I have been working on some alternatives: Ls and one possible definition is: Ls = Y0.62 * 121 - 21

Where do these numbers come from? Has this had any peer review?

Hey Chris @svgeesus

This is just the breakdown of Weber's law, no?

EGADS.... gotta few hours? LOL.... Weber breaks I think well before that.... Stevens is more what L* follows... but also breaks... in fact, here's the ginormous stumbling block for readability contrast (that APCA does address) is that Weber, Michelson, et al are threshold based measures.

Readability is far supra-threshold, and due to contrast constancy and other effects, there is a pretty massive shift that causes a breakdown of all of those, Weber, Stevens, Michelson, etc etc.

As a side note, did you know that "ginormous" is now a dictionary word?

Its (one of the reasons) why many EOTFs have a linear portion near zero, and also why HLG uses a gamma law to media white and a log law above.

Yes, C. Poynton has talked a lot about how the curve is not just powerlaw or not just log, but a hybrid.

I am presently, increasingly of the opinion that "L* is not super useful for self illuminated displays."

You don't say why.

No I don't.... at least not publicly yet... I really need to get some of these papers in better shape for review... Why do humans need sleep anyway?

We have a saying in the film industry "A film is never finished — it is simply abandoned" .... I suspect this same sentiment applies to research as well, LOL....

Andy

This is a response to a portion of the thread in in #5883 that Chris noted was drifting far off topic, but is on topic here.

Hi Chris @svgeesus Thank you for the comments, they stimulated additional thought (and memories) that helped me to clarify some things below.

I do rely a bit on R.W.G. Hunt's The Reproduction of Colour where he says:

Hunts' work is well regarded and was seminal in it's day, but the first edition dates to 1957. The fifth edition, which I have, is from 1995 and is a somewhat light re-warming of the 1987 fourth edition. So in terms of evaluating the impact of the 1976 color models, it necessarily misses a lot of later work.

I'm referencing the 6th, 2004 edition, which includes CIECAM02, CAM97, CIEDE2000. I happen to like Hunt's writing style as it fits well with how I assimilate information.

Nevertheless, I did not cite Hunt "in support of LUV" so much as to indicate an independent statement regarding the usefulness on self-illuminated displays that was, uh, less handwavy.

But I am also thinking about some work I did nearly two years ago related to color vision deficiency that is directly related to the concept of "what is the best space" for color mixing or prediction relative to a tristimulus monitor.

CVD Simulators

I created two CVD simulators. The first was based on the Brettel model, which goes into LMS space to determine the deficiency. The second is based on my theory that on a tristimulus display, it is only necessary adjust the luminance of the color primary(s) affected by the given deficiency (and combine), to predict the perceived outcome.

Here they are for protanopia, side by side. Which is which?

Screen Shot 2021-03-03 at 4 21 05 PM Screen Shot 2021-03-03 at 4 20 35 PM

Eye stream cones

In reflected surface colors where factors such as metamerism are de rigueur, an appearance model pretty much needs to be in LMS space. Tristimulus monitors don't present such wide-spectral images. A tristimulus monitor only ever emits three narrow band (even sometimes monochromatic) colors.

In surface colors in a viewing booth, the color will always be of lower luminance than the light source (unless luminous) meaning the colors viewed will be within present eye light adaptation (at the viewing booth) which also goes for chromatic adaptation, and therefore color constancy. This requires the model be in LMS space with the appropriate light and chromatic reference for the adaptation.

The "standard" environment for a computer monitor is ambient at a 20% luminance relative to the monitor peak white, meaning peak white will be higher than the overall light adaptation. Most monitors today use the D65 whitepoint, And while the general guideline is that the ambient illumination be ~5500K, in fact this have very little effect on the display perception as self illuminated displays do not follow the same laws of color constancy relative to the environment as do the physical objects in that environment.

So, we don't need a complete model to account for phenomena such as metamerism. We need to model three narrow band or monochromatic lights, and their mixtures. And we need to model the perceptual lightness/darkness.

...which...

Is really not "traditional" Lstar, but different due to the position of light adaptation relative to stimulus. Not to mention "system gamma gains" and other factors.

A couple years ago I created a dynamic list of the 140 named colors, and was putting the text for the name and color metrics inside each patch. For darker colors I wanted the text white, for lighter colors I wanted the text black, and I wanted to set the programmatically. My first instinct was to switch when the named color patch's luminance was above or below 18.4Y — under 18.4, white text, black otherwise.

As it happens, this was much too dark to switch to black text. The switch point ended up being about ~36Y.

The live example is here at the bottom of the page, click "HTML Names sort by Luminance": https://www.myndex.com/SAPC/DEV98LABLUV

I mentioned the (limited) value of chromaticity diagrams as one use case. For stage lighting design, in particular, they were fairly useful This was in the days before personal computers or even programmable calculators, it was a benefit to plot light sources on a large chromaticity diagram drawn on graph paper, connect them with a straight line, and be able to directly read off the resulting mixture chromaticities to two or perhaps three decimal places.

Funny about the size of human memory, and the context dependence of memory retrieval. I did theatrical lighting design in the 80s and also Circa 1980 the computer club I was in just built a Sol-20, 8080 based with the D/A converters... the Little Theater had just bought an analog lighting controller, that had VCA inputs, an early coding project was a rudimentary scene preset controller, the lights were positioned/focused manually... 10 years later, the last theatrical project I ever worked on was at the TPA at the former Aladdin in Vegas, "VariLights" had just been introduced, servo motor controlled including changing gel colors etc, and controlled by an embedded microcontroller console...

I only mention because you jogged my memory and it reminds me of my life long fascination with light color and vision. LOL.

...The MacAdam ellipses are still very elliptical and vary greatly in size.

Yes, and for LAB as well:

The best example of uniformity with the MacAdam ellipses Is (I think) one of the DIN systems, will have to dig it up.

The flaws of the model are not suddenly cured because the light from a colored patch is directly generated rather than being the modified, ....

Only three narrow band or mono illuminants are being used, not a continuous spectrum, so if grassman's laws are valid, then a simple model should be capable — one thing I am "working on" is can better accuracy be achieved in the simple Luv by correcting the lightness axis, which in isolation does not align with certain data collected as I alluded to in a pervious post, but I am no where near committing to anything there.

" HIGH DYNAMIC RANGE IMAGING (2010)"

(I don't have that one yet, it is eye-wateringly expensive and I fund all my book purchases; W3C doesn't cover them.)

OpAmp technical books used to be a few blocks from where I live. I had to give myself a rule to leave my wallet at home before going in there.

CalMAN™ uses CIELuv

No, CalMan used to use Lab, with deltaE2000 for all color differences, and now has moved to using ICtCp, with deltaITP.

Well, I am citing my manual, but it is an older version (V2), and I haven't used it since I replaced my CRT projector with a DLP projector... which was... UGH a decade ago... It did lead to some interesting threads and arguments, largely that the newer DE functions are intended for Lab and don't work with Luv.

I am not trying to dismiss LAB in any way, but I did add LUV to the models I'm working with, and I've found several aspects that make it favorable over LAB on self illuminated displays.

Thanks for the clarification. Some of your comments, and in particular the personal mails you sent to me earlier, gave a very different impression where you seemed to suggest that any use of Lab was entirely erroneous and purely due to commercial pressure from one or two companies. I'm glad to hear you state more clearly your position - thanks!

NOT AT ALL, and sorry if I wasn't clear.... What I am claiming is "erroneous" is the forced use of D50 when the standard is D65 (for all industries except print, and that is being discussed for a change, though doubtful).

Here is the very short clarification of my position:

Web content display space is D65, and an RGB model (default sRGB, but other possible).
- Best practices for working spaces is usually to work in the same space as delivery, though often at a much higher bit depth and there is the useful case of linearizing the working space, at least for some operations, and applying the TRC on output.
- I have some very bad experiences following some of A Dough Bee's very bad workflow advices, and learned the hard way many years ago that a company that knows print and pre-press should not automatically be trusted for film/television post.
- There is no justification to go into D50 when source and destination are D65, with the minor exception maybe of using a working space like ProPhoto, which is not a display space and requires gamut mapping for display, and as I said two years ago is a mistake to be implemented for web based content when its function is pre-press.
- And I am fairly certain the error will become more apparent with HDR material. DANGER WILL ROBINSON DANGER
For choosing colors that will be rendered into an RGB model space, at the moment I much prefer Luv or one of the Luv variants over Lab or HSL. I have demonstrated why on other links.
- Pairwise mixing, gradients, and color adjustments do not suffer the same problems as Lab,
- the hue values are better spaced and more consistent
- Can use saturation in addition to chroma
- no blue purple shift (at least not that I've found yet)
- everything is a straight line vector to the other color or white point, and for a tri stimulus space that only has three narrow band colors, that seems to obviate the need for LMS space. On this last point though, I am still working on some studies and modified models.
- none of this means that Lab should not be available, only that it is trivial to add Luv or a variant, and there are advantages for the use case. Lab is useful as a PCS to transit from the RGB model to the CMYK model, no question. But how is that core to web content?
The final "big" issue is ICC profile support, and again I am NOT saying that ICC profiles should not be supported, only that they should not be supported to the exclusion of other open-source methods like OCIO.
- ICC CMS is a processor hog. Useless for streaming, harmful to mobile, and limited utility to the general use case.
- Device manufacturers love things that force people to upgrade — IMO we should avoid promoting that.
- plain 1D or 3D LUTs without a computationally expensive CMS are the best practice when source/destination are the same color model and the same white point. Especially having provision for a 1D simple fallback LUT for lower power mobile devices. The world is not rich after all.

THAT'S IT

My objections are to baking into a workflow that is closed and will have negative consequences in the future.

Lastly, while this is interesting and useful discussion, it is entirely unrelated to the topic of this particular issue "Don't force non-legacy colors to interpolate in a gamma-encoded space".

Moved here to the correct issue for continuance.

I do hope, though, that your more wide-ranging views will be brought to bear during the Color Workshop. I would also encourage you to submit your research to a Color Science journal.

Yes, am working mainly on the accessibility and for the workshop, but intend to participate in the other discussions where appropriate.

And as to publishing: yes — however I am shocked and dismayed by the utter scam that is most of these journals. I'm supposed to pay $2000+ to publish? WUT? For work I am doing pro bono? So definitely I will not be publishing to any open access — that's insane.

In Hollywood, I often could not publish due to NDA. And what I did publish were industry articles in publications that paid me to write them. How wrong has our society gone that we force researchers to pay to play?? UGH!

Small edit to clarify: reviewing the projects/notes where we were having difficulties with integrating LAB and ICC profiles circa 2008 ultimately related to "not well behaved" profiles, and clipping in deep blues during round trips through D50 because of the unbounded transforms being done in 32bit float, in combination with 10bit per channel DPX, the clipping caused wrap-arounds with some spectacular artifacts...

Thank you!

Andy

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 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 CIELUV

Lab CIELab

Lab is bettered by CAM16-UCS

and by Oklab 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.

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.
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.
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.
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.

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_uv = C^*_uv/L^* 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

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

Here we see the infamous purple shift in LAB. Notice that LUV does not have such a shift.

Next Slide

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!

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

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_uv.)

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¹ , 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² , and the value used by physical measurement devices such as spectrometers, when they report measured colors in Lab³ ....

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_ab 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_uv 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.

Edited for clarity: "Because the red/green and yellow/blue opponent channels are computed as differences of lightness transformations of (putative) cone responses, CIELAB is a chromatic value color space." is the clarification of the other off handed remark. There's a conversation to be had here regarding the utility of transforming into a cone space or LAB's chromatic value space, versus modeling tristimulus displays which are using relatively narrow-bandwidth primaries, and therefore lack benefit in going to LMS or post-receptor, etc.

CIELUV also does not have the obvious purple shift of Lab (at least compared to LAB in the tests I've been doing), provided D65...

All for today,

Thank you,

Andy

Hey Chris @svgeesus

Regarding D50

Something I wanted to add in here. I'm concerned I am not explaining my position well, and it's not being received as intended. I have some additional experiences to share.

Some years ago I was working on the film, "The Fourth Kind" and I was using AfterEffects as there was a substantial load of motion graphics, and AE was well suited to that. Adobe had introduced ICC profiles to AE, and also came out with a workflow manual that resulted in issues that certainly shaped my opinions. As I had used ICC profiles for all of my print related work for over a decade, it "sounded like" a good idea, being a typically optimistic early adopter.

Adobe defined a workflow for feature films which was to use the ProPhoto ICC profile in linear 32 bit floating point as the working space, and use the "Universal Film" ICC profile they provided to output to 10bit integer DPX log (standard Cineon), using display soft proofing. The cursory early tests seemed okay, round trips worked so didn't "seem" to be a concern. But as work progressed into the full range of shots, and deliverables to the DI house, PacTitle, this workflow turned out to be a very bad idea.

Round Trips in Square Spaces... Or something.

I don't think I've adequately conveyed my concerns here and why I am taking this issue on. And it's not about round trips, not really even the performance issue I've been mentioning. I realize that I have not emphasized some important considerations.

Following the above approach on T4K resulted in a slew of issues. Investigating into what was wrong:

Problems Experienced:

Color channel wrap. This was a crazy and unexpected side effect. There were no negative colors in the working space, but through the PCS to output transform, color channels would go negative which would then wrap around and become the brightest pixels.
- Most notable was red channel wrap, as I recall it was the blue channel going negative, wrapping around and ending up in the red channel of the next pixel on the DPX file.
- The black point to the DPX was set at code value 90, nevertheless a combination of factors including the profiles and WP still caused negative excursions, particularly in noisy areas of the image.
Substantial desaturation. I believe this was more an artifact of using ProPhoto than D50 per se. By the time the DPX files got to DI, the look was very desaturated from how it appeared in my working space.
Unexpected shifts in density and gradients.
Some banding artifacts which I didn't have time to investigate as they appeared just before I changed the workflow, this being the only time I've ever had to change a workflow mid-film.
Unexpected blue/purple shifts, which is unexplained as none of the profiles used the LAB PCS space, all were XYZ, though reflecting back on this, it occurs to be that since the 1931 2° observer under-represents blue, this could have been a factor with this shift.

Take Aways

That was a long time ago, when workflows were still using DPX and there were still emerging workflow changes. Today, these things are more settled, and the industry has largely adopted EXR (finally!) But in essence, best practice is keeping the same illuminant for working space and destination space, and when possible work in the same space as destination. Doing work in a different space or reference illuminant than destination will have different results.

It's not about round trips. Yes, a floating-point trip through a different space for a given color with no gamut mapping and nothing clamped, should result in a near lossless result, with the output-color being less than 1 ∆E (except dark blue).

BUT

It's not always about round-tripping an unchanged color... Working in or choosing colors or gradients or whatnot will result in a demonstrable difference.

EXAMPLES

The easiest way to illustrate this is with some examples using a simple gradient. The gradients are being created in LAB and LCh_ab using a simple averaging between the start and end for each axis.

Method

The start and end colors are selected in D65, and the D65 version does everything in D65. The D50 version first transforms the D65 sRGB colors to XYZ using the piecewise sRGB TRC, then in XYZ Bradford CAT to D50 using the matrix listed in CSS 4 color, and using the D50 convert to LAB and LCh_ab, then do the gradients using the same method for the two versions, then back out from LAB to XYZ, then Bradford CAT to D65, then back to sRGB using the piecewise.

Then use the basic LAB color difference formula (square root of the sum of the squared differences). Everything is floating point except of course the hex values for the two start colors, and the final hex values for the displayed gradient. The ∆E is done with the floating point values in LAB space. The ∆E for the LCh was also performed on the L^*a^*b^* values.

LAYOUT:

TOP: Cartesian L^*a^*b^* D50 left, D65 right
BOTTOM: Polar L^*C^*h D50 left, D65 right

RESULTS:

You'll notice the start and end colors make it through the round trip okay. But the work done in D50 has different results from the identical work done in D65. Also, the LCh version suffers more than the LAB version.

COLORS: 00F to FF0

A greyscale ramp had no issues:
COLORS: 010101 to F0F0F0

And a monochromatic ramp was not a problem for LAB, but was still for LCh.
COLORS: 010101 to FFAA22

As a side note, not related to D50, sometimes the blue/purple shift is not a problem in the LCh but is apparent in LAB.
COLORS: D0E0F0 to 0101FF

And other times, the LCh is having problems with a purple shift even more so, and is noticably different in the4 D50 vs D65 version.
COLORS: 0000DD to FCFCFC

Additional examples:
COLORS: F00 to 0FF

TL;DR

What i am hoping to convey here is that round trips are not a definitive assessment of these transforms, it is the work being done in a given space. With these simple examples I am hoping to demonstrate that there are many aspects of a given space's illuminant that impact the ultimate results. More complicated work such as gamut mapping or color grading may have more complicated consequences — imagine going from Rec.2020 D65 to Rec.709 D65, but doing the gamut mapping in D50 LAB. Such a workflow would not make sense.

Thank you,

Andy

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.

CIE Lab does not go to cone space, this statement is incorrect. OK Lab does go to a cone space. The much quoted "wrong von Kries" in CIE Lab only applies if someone goes into Lab with one white point and goes out again with a different white point, which no-one does nowadays; instead they use a CAT (typically Bradford, which CSS color 4 mandates). CIE LUV has the "very wrog XYZ scaling" adaptation problem, even worse than an incorrect von Kries. But again, easily avoided by using a proper CAT.

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... 😳

CIE LUV does exhibit the purple shift.

Dragging things back to the CSS Color 4 specification, the purple sift was dealt with by using OKLCH as the space for gamut mapping and OKLab as the default space for interpolation. This also avoids a D65 to D50 adaptation step, as OK uses D65.

Just tying a loose end in this closed thread:

_CIE Lab does not go to cone space, this statement is incorrect....._

I edited the earlier post for clarity, nevertheless, many papers refer to CIE LAB as _"...lightness transformation of putative cone responses...", that being what I meant, it is an Adams chromatic value space, but that was tangential.

It can be difficult around here to have an open academic conversation, one oddly or hastily typed sentence out of context from 100,000 others is the one the trolls will bash around with, which is the only reason I am compelled to proactively post clarifications such as these.

IIR, I was trying to convey something I was working on, which is the idea of a simplified but accurate perceptually uniform space based on three narrow primaries, which after the relationship to the cone fundamentals is determined, provide everything needed to predict a color (without multiple matrixes to transform).

CIE LUV does exhibit the purple shift.

The images above, and I have further tests, showing much better results than LAB, particularly for the use case of selecting colors for gradients. But again, I've more or less dropped it, at the moment I have more important projects in tow.

Dragging things back to the CSS Color 4 specification, the purple sift was dealt with by using OKLCH as the space for gamut mapping and OKLab as the default space for interpolation. This also avoids a D65 to D50 adaptation step, as OK uses D65.

Yes I was very happy to see the inclusion of OKLab.

w3c / csswg-drafts

[css-color] Discussion of Conflicts & Resolutions: D50/D65, LAB/LUV, ICC/OCIO #6061

Statement of Purpose

What's at stake

CONFLICT ONE: D50 vs D65

The Standard is D65, including for LAB. It is not D50.

Specific points of response

Side note: Round Trips and Gamut Mapping

CONFLICT TWO: LAB vs LUV

LAB is better suited to reflective surfaces. LUV has advantages for displays.

Now let's compare the two:

Regarding "popularity"

CONFLICT THREE: ICC vs OCIO or LUTs

ICC CM is not always ideal, and it is not the only choice, either.

BUT

SO?

Path Forward

Solution ONE

Solution TWO

Solution THREE

TL;DR

This is a response to a portion of the thread in in #5883 that Chris noted was drifting far off topic, but is on topic here.

CVD Simulators

Eye stream cones

Here is the very short clarification of my position:

THAT'S IT

D65

If you are working in D65, and your destination is D65, then stay in D65.

Working or Display?

The Great LAB/LUV Debate

FROM COLORIMETRY (2007)

Today in 2021, LAB and LUV are weak compared to CIECAM02 and CIECAM16.

Whatabout LUV

Misc Advantages

D50

Eye See Sea

What initially caught my eye

Regarding D50

Round Trips in Square Spaces... Or something.

Problems Experienced:

Take Aways

BUT

EXAMPLES

Method

RESULTS:

TL;DR