RE: icc profiles and compositing

Thank you for your detailed response.

Just to be clear: In SVG 1.1 there is a difference between how opaque and transparent/filtered colors are handled.
Are you sure this is how you want the specification to be interpreted?
This means there might be a noticeable difference between a 100% opaque color and a 99% opaque color.
This means the might be a noticeable difference between a shape and a shape with a feConvolveMatrix filter with 1x1 matrix [1] applied.
This means anti-aliased edges will follow a different path than the solid pixels next to it.
This means implementations need to have multiple working rasters with different color models+spaces+intents that they have to maintain (after partially overlaying an rgb rectangle with a solid opaque cmyk rectangle an implementation now needs 2 rasters (1 with all the rgb-pixels not overwritten by the cmyk rectangle, 1 with all the cmyk pixels from the overlayed rectangle) and probably mask indicating what raster should be used when finally transforming to the device color space)

The alternative interpretation (solid colors are also composited, they just tend to overrule everything else) doesn't suffer from these problems.
It does lose all rendering intents (as opposed to only some or most) however.

On the other hand, looking to the future: the only way I can see different rendering intents making it to the final conversion to device space is by maintaining different rasters and bitmasks.
It will be hell to implement and you will need to define how rendering intents 'mix' however. For example: what rendering intent wins when compositing a 50% opaque relative pixel and a 50% opaque saturation pixel using hard-light?

The sane option implementation-wise is to choose a color composition space and composite all pixels, fully opaque or not.
This still raises questions like "what does a CIELab D50 space n combination with a perceptual intent mean?" (maybe the ICC has defined an answer to that question)
Furthermore, it makes it impossible to mix different (final) rendering intents in a single SVG image. (you will have to pick an intent for the root plane, so no saturated graphs with absolute text and a nice perceptual image as a background)
It also makes it impossible to have black-preservation (unless you're allowing cmyk composition spaces with black-preservation as a rendering intent/option, but now you have to define all compositing operations for 4-channel additive spaces as well, so I don't think this is likely to happen)
But, it might be possible that that's a trade-off you're willing to make. This is not a rhetorical question.

Depending on what direction you are going with this in the future, the current interpretation should be picked.
It looks like you're opting for the "multiple rasters and bitmasks" route.

I don't really have a preference either way, I'm just suggesting some avenues of thought for when you're discussing this face-to-face.
Not wanting to imply you haven't considered all this already, but I'm going to hold off writing up my note on how colors should be handled when an svg object is used in a color managed cmyk context until you had the face to face meeting and some more time to talk this through with the other members. Seems like an important fork in the road and I don't want to rush you.

Please keep me informed,

Nick Hofstede
R&D Manager

PS: The http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Color document contains a strange example for the preserve black use case. The problem isn't 'losing' some of the black, the problem is process black cmyk(0,0,0,100) ending up as 'rich black' cmyk(63,52,51,100). The transformation from Lab black to cmyk rich black is something that is desireable if the black pixel was part of a photograph and the neighbouring pixel is a dark blue for example (rich black is 'darker' when printed than process black and the shift from a dark color which is a composite of toner to just black toner is noticeable), whereas it is not desireable if the black pixel was part of the letter a.
For reference:
http://www.printernational.org/rich-black-plain-black.php

http://littlecms2.blogspot.com/2009/08/black-is-black-ii.html


Phone: +32 3 821 01 70
nick.hofstede@inventivegroup.com
www.inventivedesigners.com


-----Original Message-----
From: www-svg-request@w3.org [mailto:www-svg-request@w3.org] On Behalf Of Chris Lilley
Sent: woensdag 27 juli 2011 19:13
To: Nick Hofstede
Cc: www-svg@w3.org
Subject: Re: icc profiles and compositing

On Wednesday, July 27, 2011, 2:02:07 PM, Nick wrote:

NH> ChrisL told me on IRC

logged here
http://lists.w3.org/Archives/Public/public-svg-wg/2011JulSep/0015.html


NH> that this was discussed during a call and that there was an action
NH> item created for responding to this.

NH> However, I don’t see an action item for this
NH> <http://www.w3.org/Graphics/SVG/WG/track/issues>,

(That is the issues list, not the actions list.)

ACTION-3062: Respond to "ICC profiles and compositing" mail on www-svg
http://www.w3.org/Graphics/SVG/WG/track/actions/3062


Its also on the agenda for the face to face meeting this week http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2011/Agenda


NH> Can someone clarify how the specification should be interpreted?
NH> What conversions happen when I specify a CMYK color that needs to be rendered to a CMYK device?

In SVG 1.1, all interpolation and compositing happens in the SRGB colour space (the values for the color-interpolation property only allow sRGB or linearRGB)

http://www.w3.org/TR/SVG11/painting.html#ColorInterpolationProperty


and all filter operations are similarly limited by the color-interpolation-filters property

http://www.w3.org/TR/SVG11/painting.html#ColorInterpolationFiltersProperty


So if a CMYK colour is used
- with opacity
- in a gradient
- in a graphic that uses filter effects
then the colour is converted into sRGB. The original values, the rendering intent, are therefore lost and there will be compression of out of gamut colours.

Opaque solid colours which are unfiltered, will pass straight through and will be available to the output device. In an ICC workflow, if the output device uses the same profile as was used to define the colours in the SVG file then the CMYK values will be used without adjustment. otherwise, the CMYK input values will be converted to the profile connection space (likely CIE Lab) and then converted to the output CMYK space.

In SVG color, some of these restrictions are lifted. color-interpolation is extended to allow several new values,

http://dev.w3.org/SVG/modules/color/master/SVGColor.html#interpolation


of which the most relevant to this question is CIELab with a D50 whitepoint; this is the same as the ICC profile connection space. Thus, in cases where colours are interpolated or composited, conversion from CMYK still happens, but in this case there is no gamut compression.

It is still an issue that the original rendering intent is lost.

It is still an issue that we don't have a way to specify preserve-black, and that we don't have control over black point compensation.

Some issues are listed in the discussion document for this weeks meeting:
http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Color





--
 Chris Lilley   Technical Director, Interaction Domain
 W3C Graphics Activity Lead, Fonts Activity Lead  Co-Chair, W3C Hypertext CG  Member, CSS, WebFonts, SVG Working Groups



--
This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.


________________________________

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

Received on Thursday, 28 July 2011 11:02:45 UTC