Re: [w3ctag/design-reviews] EyeDropper API (#587)

Hi Lea @LeaVerou 

You mentioned above in part:
> _"...I'm not sure what is the best way to deal with this, since none of the currently widely supported color formats can express all on-screen colors. Ideally, the API should return one of the CSS supported device independent color formats, such as lab() or lch() but support is currently limited...."_

The following idea is only partially baked, kinda like a raw strawberry pop-tart. Nevertheless, it is how we deal with super wide gamut image data in film/TV: use the same Rec709 primaries but be unbounded linear. This is the default for .EXR with primaries that are assumed to be Rec709/sRGB (though others can be specified). 

I know you know this Lea but for others reading along at home: The entire visible gamut can be encoded this way, and converted to any arbitrary display with the appropriate LUT. And useful LUTs and related libraries are freely available at [**OpenColor IO**](https://opencolorio.readthedocs.io/en/latest/index.html)

So the not fully baked idea is, why not use the now very standard half float like EXR, use the same sRGB primaries for value 1.0, (or an ACES space, or possibly the 32 bit LogLuv space), and then use the free open libraries of OCIO to handle converting from or to any given display space, to a neutral, HDR space?

Then the concern about future proofing and "unknown" display spaces is abstracted, needing only a change of LUT, which can happen on the client machine without without any privacy issues (similar to a media query).

And now I'm thinking about pop tarts, I wonder if I have any....


A


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/587#issuecomment-787709866

Received on Monday, 1 March 2021 07:10:46 UTC