W3C home > Mailing lists > Public > www-svg@w3.org > July 2011

icc profiles and compositing

From: Nick Hofstede <Nick.Hofstede@inventivegroup.com>
Date: Mon, 4 Jul 2011 07:52:50 +0000
To: "www-svg@w3.org" <www-svg@w3.org>
Message-ID: <BC885F9E3DB48248A4C9FC7F2C57215C10877DF0@Hoefnix.dc.intranet>
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
Received on Monday, 4 July 2011 12:21:08 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:48 GMT