Re: [css-color] wider/deeper colors

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

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?


> Just the same, if you anticipate the main use of your content being in
> some other color space, it make sense to provide assets (and manually
> specified colors) that match that color space, be it fooRGB or barCMYK.
>
> I'm not saying this is the only reason to use color management, you may
> very well want it because you have existing assets in various color spaces
> and you just want them to play nicely with each other.
>
> Can you point to a spec that say where the output profile come from?
>
>
> I don't think we have that. To me it makes sense to leave this entirely up
> to the UAs, with the understanding that taking advantage of the gamut of
> the medium you're rendering into will lead a better experience.
>
> 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.

OSX follows the standard model where the "document" is rendered in a
standard color space and is then mapped to whatever colorspace the monitor
is, [1]

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



1:
https://developer.apple.com/library/ios/technotes/tn2313/_index.html#//apple_ref/doc/uid/DTS40014694-CH1-ACTIVEANDTARGETEDCOLORMGMT