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

On Thu, Sep 26, 2013 at 12:51 AM, Rik Cabanier <cabanier@gmail.com> wrote:

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

Hi Chris,

I never heard back from you.
What you do think of my points?

To be clear, I'm not arguing against color management. I just want to make
sure that we can define a model that doesn't disturb the current world,
that is easy to extend and that can be turned on piecewise.


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