Re: [css-color] wider/deeper colors

This conversation has now so long I'm not sure what anyone is talking about any more. My brain is failing.

Can someone summarize the changes that are being suggested? Does it impact what we've already decided on.

Dean

> On Mar 21, 2016, at 1:44 AM, Florian Rivoal <florian@rivoal.net> wrote:
> 
> 
>> On Mar 20, 2016, at 04:15, Rik Cabanier <cabanier@gmail.com <mailto:cabanier@gmail.com>> wrote:
>> 
>> [sorry for the late answer[
>> 
>> On Thu, Feb 18, 2016 at 11:04 PM, Florian Rivoal <florian@rivoal.net <mailto:florian@rivoal.net>> wrote:
>> 
>>> On Feb 19, 2016, at 14:02, Rik Cabanier <cabanier@gmail.com <mailto:cabanier@gmail.com>> wrote:
>>> 
>>> I don't see that as hardcoding, rather the opposite. Unlike the device-cmyk() approach where you don't specify what the color space is and therefore depend on the output device being what you hope it will be to get your colors right, when you actually specify color spaces, you can optimize your assets (both images and explicit colors) to be the best match for what you think is the most likely output medium, while still having them work when rendering to something else.
>>> 
>>> We could just drop all color spaces other than CIELab, but that'd be hugely impractical. When you know something is most likely to come out into an sRGB environment, specifying things in sRGB makes sense, and color management deals with other environments. Just the same, if something is  likely to or meant for being printed on US Web Coated SWOP, working in that space makes sense, and doing so explicitly lets UAs deal with different situations.
>>> 
>>> This is a very weird way of thinking about color management.
>> 
>> Why is that weird? Of course the fact that we've been rendering things almost exclusively into an sRGB space is the reason why images and manually specified colors have been sRGB. Doing otherwise would have been impractica, even if we had color management.
>> 
>> It's weird because traditionally the whole point of adding color management is to NOT design for a particular color space.
> 
> Color management makes things work everywhere regardless of what they were designed for. It doesn't mean you cannot have a typical target in mind when you design your content, and tailor your assets to work ideally with that.
> 
> It's not that you have to, but if you expect 99.9% of viewers to be on sRGB devices, why would you bother designing your tinted drop shadows in ProPhoto RGB?
> 
> If you're working with photographic assets, then sure, there's a good change the color space you'll use for these is going to be more influenced by what camera you used than what kind of screen viewers to use, because color management deals with that for you.
> 
> But if you're drawing the things your self (whether in photoshop or in hand crafted SVG or in CSS...), I have a hard time thinking of people choosing to specify things in CMYK when they're creating content for screen, on in sRGB when authoring for monochrome e-ink. Sure, it would work, but there's just so much less mental overhead by doing things in the natural space of your expected output.
> 
>> I admit that print is a bit special. We couldn't get rid of designing in CMYK mostly because designers want to control the black channel themselves. The algorithms usually mess that conversion up with very bad end results.
>> This proposal is just for screen display, correct?
> 
> I don't think so. The web is predominantly screen rather than print, but not exclusively, and this proposal, as I understand it, is meant to deal with both.
> 
>> I think we probably have a SHOULD somewhere advising UAs to use the underlying OS's facilities to avoid treating all screens as if they were sRGB, as doing so would lead to terrible results on wide gamut displays, but that's about it.
>> 
>> Yes, that would be bad. I was under the impression Safari currently doesn't do this since MacOS has nice color facilities. I'm unsure of other browsers.
> 
> I think Safari is the only well behaved browser at the moment.
> 
>> 
>>> Is there such a thing as a document profile?
>> 
>> Except in emails sent to a printer along with a PDF containing untagged CMYK, which say "in this document, CMYK means SWOP", no I don't think there is. But I'm not sure where you're going with that question.
>> 
>> If you define that the document renders in sRGB then that would mean that the "document profile" is sRGB (and then mapped to whatever monitor is attached)
>> A user could potentially override this profile. In that case the document would be rendered with the new profile and then remapped (with possible gamut reduction) to the screen.
> 
> What is the advantage of flattening, presumably from CIELab or CIEXYZ, to sRGB then converting the the output device's profile, as opposed to converting directly from CIELab or CIEXYZ to the output device's profile?
> 
>  - Florian