RE: icc profiles and compositing

ChrisL told me on IRC that this was discussed during a call and that there was an action item created for responding to this.
However, I don't see an action item for this <http://www.w3.org/Graphics/SVG/WG/track/issues>, and I'm afraid this is falling through the cracks.

Can someone clarify how the specification should be interpreted? What conversions happen when I specify a CMYK color that needs to be rendered to a CMYK device?
If you want I can follow up with more print-related issues and use cases later (there seemed to be some interest in that), but first I'm interested in this clarification.

With kind regards,

Nick Hofstede
From: www-svg-request@w3.org [mailto:www-svg-request@w3.org] On Behalf Of Nick Hofstede
Sent: vrijdag 8 juli 2011 12:31
To: www-svg@w3.org
Subject: RE: icc profiles and compositing

All,

The lack of response leads me to believe I haven't made myself very clear. I'll try a different approach this time.

Suppose I have a color defined in a cmyk color space with a perceptual rendering-intent specified.
Suppose my target device is a cmyk device with a different cmyk color profile.

If I draw a fully opaque rectangle filled with this color, how do I calculate the values of the resulting color-channels?

Do I transform the input color to the device color space using the perceptual rendering intent?
Or do I transform the input color to the sRGB color space (because I'm compositing the rectangle with the background) using the perceptual rendering intent and then go from sRGB to the device color space using an undefined intent?

With kind regards,

Nick Hofstede
R&D Manager
From: Nick Hofstede
Sent: maandag 4 juli 2011 9:53
To: 'www-svg@w3.org'
Subject: icc profiles and compositing

Hi all,

I'm currently trying to write up a document for a standardization group that describes how to integrate SVG as an external object in a certain printer-language.
Obviously CMYK comes up, as do ICC color profiles.

I'm happy to notice that it's possible to define colors in any color space, and that it's possible to specify a rendering intent.
Given the target color space of the device, that should suffice to get a well-specified result on paper.

Things got complicated however when I started reading about compositing.
Compositing in 1.1 has to happen in either sRGB or LinearRGB. The 1.2 working draft allows you to specify more color spaces (yay), but defaults to the 1.1 interpolation space which itself defaults to sRGB.
The 1.1 specification (which is also the default for 1.2) doesn't specify a rendering intent. What rendering intent should I use to convert the composited RGB-values to my CMYK device space?

How do I make sure my brightly-colored graphs (possibly filled with a gradient going from (red,sRGB,saturation) to (yellow,sRGB,saturation) using sRGB as interpolation-space) end up using the saturation rendering intent going to my CMYK device space? In other words, how is the rendering intent remembered? The working space is simply defined as sRGB with no indication of intent.

You might say this is only a problem for composited pixels, but isn't everything - every pixel - composited? I would think so, given that even if you have a fully opaque color, you might still have to deal with anti-aliasing and I don't think you want to treat very similar and neighboring pixels differently. Also, the 1.2 working draft talks about a working spaces that get merged, which seems a reasonable implementation hint to me, but also implies converting every pixel to the working space.

How do I make sure that if I match my input color space to my device color space and specify a CMYK black (0,0,0,100) it is left alone and not converted to rgb(0,0,0) and afterwards a richer black (20, 20, 20, 100) when sent to my device? In 1.2 I might consider using the same color space as my input space for working space, but even in 1.2 4 component working spaces are optional and rather undefined.

In summary:
Am I correct concluding that at least for SVG 1.1 all colors should be converted to RGB (s or linear) using the defined profile and intent, the image drawn and then converted to the device space with an unspecified intent? (Which would mean that we should specify the final rendering intent on our included object and use it to convert the resulting RGB raster to the device space)

Is there a way to define and use (at least) fully opaque CMYK colors without having to go through another color space?

I was rather optimistic seeing icc-profiles, concluding that the mapping to the device space was well-defined, but upon further reading I now believe you are - at least in 1.1 - forced to go through an RGB space by doing a possibly destructive transformation and losing the use of your original intent before going to your device space using an unspecified intent ...

Hoping I'm misunderstanding something,

Nick Hofstede
R&D Manager


________________________________

Inventive Designers' Email Disclaimer:
http://www.inventivedesigners.com/email-disclaimer