[css-color] Discussion of Conflicts & Resolutions: D50/D65, LAB/LUV, ICC/OCIO #6061
Comments
|
+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:
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. |
|
Hi Mike @faceless2 Thanks for commenting.
Well, thank you...
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?
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
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. |
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
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. |
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.
You don't say why.
Where do these numbers come from? Has this had any peer review? |
|
Hey Chris @svgeesus
EGADS.... gotta few hours? LOL.... Weber breaks I think well before that.... Stevens is more what 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?
Yes, C. Poynton has talked a lot about how the curve is not just powerlaw or not just log, but a hybrid.
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'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 SimulatorsI 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?
Eye stream conesIn 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
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.
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.
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.
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.
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.
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:
THAT'S ITMy objections are to baking into a workflow that is closed and will have negative consequences in the future.
Moved here to the correct issue for continuance.
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:
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.
I'm astonished to see this hoary-old argument from 1976 resurrected, given the amount of experience we have gained with these two systems since then. Lab is widely used, everywhere; there are better models, especially if viewing conditions and surround effects can be precisely controlled. Luv is occasionally mentioned as being standardized at the same time and is otherwise ignored in most textbooks. It is well known to give por predictions of color appearance. But it has been studied. Here for example is a figure from Luo, L and Kuo "The LLAB(l:c) Colour Model", Color Research and Applications, 21:6 1996. It is showing LUV significantly worse than all the other systems studied:
Here, figures showing the prediction of Munsell hue and chroma. LUV comes out second worst, and is the worst colorimetrically-based model (HSV came out worst, and was presumably included only for comic effect). LUV Lab Lab is bettered by CAM16-UCS and by Oklab For compatibility (with Krita, or Gimp, or Photoshop, or any other software or hardware that uses Lab) Lab in CSS Color 4 assumes a D50 adaptation. The cost of one or two adaptation stages is very minor and non perceptible, if done correctly. The cost of using Lab with an unknown adaptation state, or using unadapted colors with the wrong adaptation state, is significant and easily seen. The one advantage of CIE LUV over CIE Lab is the associated chromaticity diagram, because 2D diagrams are easier to show and to understand and because color mixtures being on straight lines rather than curves makes for simple explanations, and because the u'v' chromaticity diagram sucks less than the xy chromaticity diagram. Both, however, will erroneously show out of gamut colors as being apparently in-gamut. A 3D representation avoids this.
Turning to a couple of ICC-related points:
You do realize there is more than one implementation, right?
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:
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
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).
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:
D65Yes, nearly all monitors and devices are D65. I haven't seen a 93K monitor since I gave them to Goodwill a decade ago LOL.
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
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."
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:
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: ADDITIONAL SUPPORTING:
AND
AND
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 LUVThe 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
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
Next Slide
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 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
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
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 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.
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 Lshuv.) Eye See Sea
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.
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.
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.
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 eyeAs an example, here's the paragraph that raised my eyebrows, being ever so slightly hand wavy...under section 9 on LAB:
Sure, I've been working with ICC profiles and countless implementations since circa 1993 (ish).
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).
If LChab 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 Lshuv for a color selector, if not CIELUV, some CAM...
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).
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.
Edited for clarity: 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 D50Something 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:
Take AwaysThat 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). BUTIt's not always about round-tripping an unchanged color... Working in or choosing colors or gradients or whatnot will result in a demonstrable difference. EXAMPLESThe easiest way to illustrate this is with some examples using a simple gradient. The gradients are being created in LAB and LChab using a simple averaging between the start and end for each axis. MethodThe 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 LChab, 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:
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: A greyscale ramp had no issues: And a monochromatic ramp was not a problem for LAB, but was still for LCh. 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. 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. Additional examples: TL;DRWhat 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 |
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.
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:
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).
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.
Yes I was very happy to see the inclusion of OKLab. |
Uh oh!
There was an error while loading. Please reload this page.
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
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: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.
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:
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, LChuv, 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.
Thank you,
Andy
Andrew Somers
W3 AGWG Invited Expert
Myndex Color Science Research
The text was updated successfully, but these errors were encountered: