Re: [css-color] wider/deeper colors

On Mon, Mar 21, 2016 at 9:24 AM, Dean Jackson <dino@apple.com> wrote:

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

I'm confused too :-)
What is the problem that it is being solved?
Is it:
- consistent color across devices with option to target high gamut screens
- media queries to detect different screens so you can special case content
- be able to specify out-of-range colors

> 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> wrote:
>
> [sorry for the late answer[
>
> On Thu, Feb 18, 2016 at 11:04 PM, Florian Rivoal <florian@rivoal.net>
> wrote:
>
>>
>> On Feb 19, 2016, at 14:02, Rik Cabanier <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
>
>
>