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> 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] On Behalf Of
> Nick Hofstede
> Sent: donderdag 28 juli 2011 18:28
> To: Chris Lilley
> Cc: 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] 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
>
> --
> 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
>