Re: icc profiles and compositing

Hi Nick, Rik,

I added an issue to tracker so that we can keep track of this issue:

http://www.w3.org/Graphics/SVG/WG/track/issues/2424

Kind regards,
Vincent

From: Rik Cabanier <cabanier@gmail.com<mailto:cabanier@gmail.com>>
Date: Mon, 1 Aug 2011 09:56:51 -0700
To: Nick Hofstede <Nick.Hofstede@inventivegroup.com<mailto:Nick.Hofstede@inventivegroup.com>>
Cc: Chris Lilley <chris@w3.org<mailto:chris@w3.org>>, "www-svg@w3.org<mailto:www-svg@w3.org>" <www-svg@w3.org<mailto:www-svg@w3.org>>
Subject: Re: icc profiles and compositing

I agree that if you have support for spot colors, they should survive compositing.
However, it seems that you would also need support for features such as CMYK and overprint to get decent color support out of SVG.

This would be a non-trivial task, not just from a language point but also for an SVG implementor.

Rik Cabanier
Adobe Systems, Inc

On Mon, Aug 1, 2011 at 2:29 AM, Nick Hofstede <Nick.Hofstede@inventivegroup.com<mailto:Nick.Hofstede@inventivegroup.com>> wrote:
Another thing to keep in mind are spot/named colors that were introduced by SVG Color.

I assume that as soon as you're compositing those, you're going to fall back to the sRGB color (btw: why not allow the syntax "#CD853F icc-color(cmyk, 0.20, 0.48, 0.75, 0.0) icc-color(FooColors, Sandy23C)" making it possible to use another colors space than sRGB as a (first) fallback?)

This would mean that a rectangle filled with Sandy23C and opacity 50% would fall back to its sRGB value to be composited while most printers are capable of producing an x% coverage of any given named color. I'm not sure if this gives the desired result when it is composited with anything other than 'white' (by which I mean the color of the medium it will be printed on). There are enough logo's out there that consist of several intensities of the same pantone color, and should be printed using that specific toner only with different amounts of coverage, that this might be an important use case.
(Example: http://www.mingle360.com/marketing/logos_and_graphics.html uses Pantone 7545 both with 100% and 53% coverage)

Apologies for making all of this even harder,

Nick Hofstede

-----Original Message-----
From: www-svg-request@w3.org<mailto:www-svg-request@w3.org> [mailto:www-svg-request@w3.org<mailto:www-svg-request@w3.org>] On Behalf Of Nick Hofstede
Sent: donderdag 28 juli 2011 18:28
To: Chris Lilley
Cc: www-svg@w3.org<mailto:www-svg@w3.org>
Subject: RE: icc profiles and compositing

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> [mailto: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<mailto: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<tel:%2B32%203%20821%2001%2070>
nick.hofstede@inventivegroup.com<mailto:nick.hofstede@inventivegroup.com>
www.inventivedesigners.com<http://www.inventivedesigners.com>


-----Original Message-----
From: www-svg-request@w3.org<mailto:www-svg-request@w3.org> [mailto: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<mailto: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

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