Re: [css-houdini-drafts] [css-typed-om] CSSColorValue section needs WG review (#1039)

> > First, the extensibility needed for a Color object is broader than the kind of extensibility afforded by CSS itself (e.g. in JS adding new color spaces can be done by providing conversion code -- CSS's @color-profile cannot provide that).
> 
> Could you open an issue for this? I was under the impression that an ICC profile was sufficient for color space conversions; if we will indeed want more than that, we should explore the details. CSS probably wants access to this, then, so they could use such a space in `color()`, which would be an argument for a new Houdini API.

Hi @tabatkins and Hi @LeaVerou 

just to chime in here a bit, possibly tangentially: We know ICC profiles don't "do" color space conversions, they just provide some information about a space so a color management engine can do so... but is that best?

### Eye See Sea Spaces....
That said, ICC profiles for converting between two display spaces with the same white point is not a best practice; it is just a commonly available method. ICC profiles are certain important, the ICC system is what allowed desktop publishing to flourish.

**BUT:** ICC profile-based color management is processor intensive. Not bad perhaps for some still images or printable content. But nearly useless for dynamic and especially streaming content. We do _not_ use them here in Hollywood and for good reason (After Effects notwithstanding). Instead we use LUTs, which are more direct and computationally less expensive.

LUT workflows are freely available, such as [OpenColorIO](https://opencolorio.org), a project of Sony Imageworks.

I bring this up as working with ICC profiles is slow enough, even on very fast workstations (and I have lots of fast workstations) that engaging them with streaming content is literally a show stopper. The playback stops.

The ICC workflow is reasonably good for RGB -> CMYK transforms as a part of pre-press, but ICC workflows are not a magical bullet to cure all and convert all... and there are other alternatives/methods that are worth considering.

And in filmmaking we do use ICC profiles in lieu of LUTs for _some_ Adobe products. But the main applications we use like Fusion and Nuke etc are all LUT based. OpenColorIO is a drop in for AfterEffects, and I stopped using Adobe's color manglement as soon as OCIO was available.

If we consider mobile devices, where power and processor are are at a premium, does such a system makes sense? Sure, I can see it being a part of a web standard — but it if is then so should OCIO, and some other default means, as in, sRGB should always be the default fallback. There are implications for accessibility where sRGB is somewhat ideal, and most devices can use sRGB with no color management at all. 

- Technically color management is "not needed" for sRGB web content, as it is a calibrated standard. 
- Watching television is not color managed. Television broadcasts are a calibrated standard but not a color managed delivery pipeline.
- The human capacity for "color constancy" allows us to see content or objects that are not absolutely color accurate, so long as the colors are *relative-correct* against each other.

### Display Spaces...
All that said, the important thing is getting content is whatever space the author worked in to display properly on the end user's display space. It is interesting seeing the new UHD/HDR technologies like Rec2020 and Rec2100. The important space is the display space. And if the user calibrates, then their monitor is one unique space that content author won't know. Only the user does.

For instance, when I surf the web with my NEC wide gamut monitor, technically I'm not looking at sRGB or any other, I am looking at "Andy's personal monitor colorspace" created with the calibration and loaded into the monitor's internal 14 but LUTs. It's not sRGB, it's specific to the calibration and calibration profile.

But my Safari browser assumes everything I see online is sRGB, and Safari and the MacOS color management takes what it assumes is sRGB and transforms it to display on my monitor.

But must mobile devices, and even many desktops, do not have full color management.


### Aye, See the Gamut Map, See?
Lea mentioned a couple things, one that conversion can be done by other means, and two, gamut mapping.

There is no magical button, ICC profile, OCIO or whatever, that can squish a wide gamut image into a smaller space automagically and without compromises. In Hollywood when we convert/transfer a film or TV show to a different distribution medium, that process is overseen by a colorist who makes adjustments though out for best results. Yes, you can use the gamut mapping in a color management engine or LUT workflow — if results are important, color will need guidance and adjustment along the way.

And this is not even mentioning that color management in browsers is not exactly "fully supported" except perhaps for Safari on MacOS. I imagine that issue changing as CSS 4 becomes the rec and more browsers fully integrate CSS colors and assets beyond images.

In practice, this is less hard that one might think; if we are working in a D65 RGB space, and the destination (user's display) is also a D65 RGB space, it's not horribly difficult to make that transform, and no ICC profile is really needed. ICC profiles are not superior to other methods of gamut mapping. And in practice, if you are not clipping, then a larger space and the resultant need to map does not provide much benefit.

### Bigger is not better
BUT I see that ProPhoto, a space so large that the primaries are not real, they are imaginary primaries that cannot exist in the physical world, and the white point is D50, because ProPhoto is not a display space it's a working space to allow working on images/art in RGB for elements that are destined for CMYK printing. 

I am a little puzzled as to why it's in the CSS spec; it's main use is in pre-press work, not as a delivery/display profile. 

ProPhoto is a huge profile that requires working in 16 bit, but it is literally impossible to create a monitor that fits that profile due to the size and the imaginary primaries. And an image in a prophoto profile is an example of the kind of image that needs to be "manually massaged" to bring it into a displayable or printable space.

## TL;DR

- There are alternatives to ICC profiles, and if all that is happening is going from ` RGB space A -> RGB space B ` display spaces, then ICC and the PCS (profile connection space) are unneeded bloat _for web content._
- The author's working space should "ideally" match the destination space & whitepoint
    - (except possibly being in a higher bit depth). 
    - They should use the same LUT the destination will be using. 
- The basic spaces, like sRGB, should be accommodated without the use of any ICC profile.
- sRGB is ubiquitous, and a web author should need nothing more than a tag in the head like:
       **` <meta: colorspace="sRGB"  type="display"  fallback="DisplayP3"  >  `**
     - _sRGB, Rec709, Adobe1998, and DisplayP3_ are close enough to each other including similar gamma/trc and similar gamut size that assets in these spaces can be converted easily and _probably_ without a lot of manual gamut mapping. 
- The PCS is not really needed for RGB to RGB, especially with the same whitepoint. 
- Hopefully these comments were not too tangential.

Thank you

Andy


-- 
GitHub Notification of comment by Myndex
Please view or discuss this issue at https://github.com/w3c/css-houdini-drafts/issues/1039#issuecomment-911536157 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 2 September 2021 10:58:06 UTC