I googled a bit and it appears that the ICC does have an idea what a PCS profile with a perceptual rendering intent might mean, and it looks like V4 profiles are supposed to help with standardizing what it should mean by defining "Perceptual Reference Media ". At least, that's what I seem to understand - you probably want to check with someone who understands this better than I do.
References:
http://www.color.org/ICC_white_paper_9_workflow.pdf
http://www.color.org/Design_and_use_of_v4_PI.pdf
http://www.color.org/profile.xalter (3.1.4)
http://www.onyxgfx.com/index.php?area=viewinfo&action=kbase&id=50170000000MX6NAAW
If black-preservation is mainly done in the 'from PCS' transformation, then the only remaining and important question appears to be: do you want to support parts of an SVG image having different rendering intents?
(Given the possibility of a Lab compositing space in the future, I'm starting to prefer answering 'no' to this question, which would result in a much simpler implementations. This would imply that a different answer on my original question is preferred though - opaque and transparent colors are to be treated the same and converted to sRGB (the default compositing space that will be made configurable by SVG Color) before being converted to the device color space)
(Also note that 'not being able to mix rendering intents' is only a problem for cmyk devices. You could mix rendering intents on rgb devices by specifying the device's color space as the compositing space and merging input on it using different rendering intents - the last transformation from root compositing space to device will be a no-op and thus preserve the previous intents. This is something you can't do when your ouput device has 4 components due to the missing compositing math, but that's a price I think we should be willing to pay in order to have a shot at sane implementers.)
Food for thought,
Nick Hofstede
-----Original Message-----
From: www-svg-request@w3.org [mailto:www-svg-request@w3.org] On Behalf Of Nick Hofstede
Sent: donderdag 28 juli 2011 13:02
To: Chris Lilley
Cc: www-svg@w3.org
Subject: 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
--
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