Re: [css-gcpm][css-color] device-cmyk() interaction with RGB-space colors.

Hi Chris,

sorry if I sounded snippy in my last email. I didn't mean to offend you.

I'm not arguing against having CMS on the web. You and I have had
conversations about this before and I *thought* we were in general
agreement on how RGB should be handled.

CMYK is a different problem though.
I've attached a screenshot of the color settings dialog for people that
don't have access to InDesign:
 cms.png<https://docs.google.com/file/d/0B26l3CHMT6bfVHVGUVFfdjUyOVE/edit?usp=drive_web>
Note how CMYK is handled. Profiles are ignored and numbers preserved.

Here's a quick google search on this feature: http://bit.ly/18qTiaM which
digs up many articles and mail threads.

One of the results is this article:
http://indesignsecrets.com/my-cmyk-images-change-when-i-print-or-export-pdf.php
which
talks about the pitfalls of calibrated CMYK. Note this sentence from the
article:

Let’s say you are in a fully color-managed workflow, and you really like
CMYK cross-rendering for some bizarre reason

So, the author can not see a reason (hence 'bizarre') for a workflow
cmyk->cmyk.

Let's go over a couple of scenarios:
1. you place a CMYK image with an embedded profile.
Should this profile be used (by default) at any time?
During printing -> no, we went over this. People don't want us to touch
their cmyk values
During proofing -> no, proofing goes from the target profile to the
proofer's profile (while doing matching) so use the original cmyk values
but tag them with the target profile.
During display -> this sounds tempting, until you think about it. You will
get a nice color link from the embedded cmyk to srgb but it won't match
what you get when printing...
Another reason not to use it, is that it's very likely that the profile is
wrong.

2. CMYK to RGB conversion for screen display.
I admit that the simple formula from CMYK to RGB is suboptimal. Maybe we
can somehow define a document profile to make this more sane. This
basically would turn device-cmyk into calibrated CMYK during display.
If there is no such profile defined, let's settle on the simple formula.
Otherwise, pages will look different in different parts of the world since
cmyk profiles across countries.

3. Export/printing to a format that supports multiple color space (ie PDF)
Don't do any color conversion and just pass everything through as-is.

4. Exporting/printing to CMYK
device-cmyk values are preserved. RGB is converted to CMYK using ICC.
Maybe we can define that rgb where r=g=b is mapped directly to K? Maybe we
can also define CMYK alternates for named colors?
During export, there must be a profile which either comes from the document
or the UA.

5. How to handle content that has an RGB only operation (such as a
colormatrix filter) during export to CMYK
That entire section should be treated as if it had a sRGB profile attached
to it (aka as if it were displayed). At the end of the operation, all the
RGB values are mapped to CMYK.
This does mean that cmyk values in that section are destroyed.

What do you think? Does this make my intent more clear and ease your
concerns?



On Wed, Sep 25, 2013 at 8:06 AM, Chris Lilley <chris@w3.org> wrote:

> Hello Rik,
>
> Wednesday, September 25, 2013, 4:42:59 PM, you wrote:
>
>
>
>
>
>
> > On Wed, Sep 25, 2013 at 4:11 AM, Chris Lilley <chris@w3.org> wrote:
> >
> > Hello Tab,
> >
>
> >  Tuesday, September 24, 2013, 10:51:47 PM, you wrote:
> >
>  >> Sorry, I should have linked this:
>  >> <http://dev.w3.org/csswg/css-color/#cmyk-colors>
> >
> >  That description needs a lot of finessing, because as-written it
> >  introduces the general concept of CMYK and then says that device-CMYK
> >  is how you do that.
> >
> >  This is absolutely not what we want to do (its no longer the 1980s).
> >  Instead, we should talk about CMYK, explain how its generated and
> >  handled in a modern colour-managed environment.
>
>
>
>
> > No. Device color is exactly what most people want.
> > Adobe promoted this CMS workflow in the nineties and early 2000's,
> > but we've learned a lot since then. Keeping it simple is key and
> > introducing calibrated color is anything but simple.
> > In addition, it caused tons of subtle problems (such as losing the
> > black channel or color fringing during transparency) that proved
> unsolvable.
>
> Well, that explains why you have been arguing against or
> misrepresenting/misunderstanding colour management for the last couple
> of years in the SVG WG, all the while claiming that you understood it
> and (apparently) were in favour of it.
>
> Thanks at least for stating your position clearly: you don't want any
> colour management on the Web.
>
> I note that Adobe products still have a whole preferences section for
> setting up the RGB and CMYK profiles to be used, so I conclude that
> your position and Adobe's official position don't coincide?
>
> >  Another section would explain how compositing happens when the various
> >  colours to be composited are specified in different colourspaces.
>
> > Yes, that's needed somewhere.
> > Likely, just mapping to the RGB colorspace as early as possible
> > (using the simple conversion for CMYK) is enough.
>
> OMG we really are back in the 1980s? C = 1.0 - R and all that?  Total
> mystery-meat colours?
>
> > I'm unsure what should happen for non-rgb targets. Maybe it's
> > better to say that they shouldn't change the colors and let the
> > print system handle color managment. For instance, if the target is
> > a PDF file, that PDF should contain CMYK and RGB (as sRGB) as defined in
> CSS,
>
>  So you are saying that PDF should continue to benefit from
> colourmanaged colours (there is a substantial part of the PDF spec
> dealing with this) while the Web should not? I can see how that would
> be a benefit for selling PDF but not how it would benefit the Web in
> any way.
>
> >  Lastly, as a special case where you really do want to specify
> >  unmanaged CMYK (such as for quality control test strips) device CMYK
> >  should be introduced as the way you do that particular thing.
>
>
> > No, deviceCMYK should be the way to express prepress colors.
>
> No, it shouldn't.
>
> --
> Best regards,
>  Chris                            mailto:chris@w3.org
>
>