Re: minutes, SVG WG Seattle F2F 2011 day 3 - SVG Color

On Thu, Aug 4, 2011 at 1:36 AM, Nick Hofstede <
Nick.Hofstede@inventivegroup.com> wrote:

>  *From:* www-svg-request@w3.org [mailto:www-svg-request@w3.org] *On Behalf
> Of *Rik Cabanier
> *Sent:* woensdag 3 augustus 2011 21:45
> *To:* www-svg
> *Subject:* Fwd: minutes, SVG WG Seattle F2F 2011 day 3 - SVG Color
>
>
>
> On Wed, Aug 3, 2011 at 1:51 AM, Nick Hofstede <
> Nick.Hofstede@inventivegroup.com> wrote:
>
> How do I match the black? By using the same black as in the image. You’re
> right that I need to know the color profile used in the image, but that
> isn’t unlikely.
>
> The image might be sRGB, so I might just specify #000 for the color of the
> underlying rectangle. Or it might be that my shop standardized on a certain
> CMYK profile for the images. Or I might find out what profile the image
> uses. Point is that I want the same black-preservation setting for the image
> as the underlying black rectangle in this case, which isn’t the decision an
> automatic algorithm would make.
>
>
>
> We're mixing up color management and black preservation here.
>
>
>
> I agree. I brought up black preservation because lcms implements this as an
> intent and I thought that would make it easier to explain why intents are
> important to preserve, but instead it got me in whole other discussion :)
>
>
>
> Maybe we need to discuss what should happen in a CMS workflow and why black
> preservation is needed.
>
>
>
> My original concern is over how cmyk colors are treated in SVG. What
> conversions happen when using what intent when a cmyk-filled rectangle gets
> rasterized to a cmyk device?
>
> Black preservation is another important issue that is separate (but might
> be tackled at the same time if we consider it a rendering intent, or an
> option when converting between spaces. Black point compensation is another
> option when converting and might be specified the same way btw)
>
> I hope it clear why black preservation is important when printing cmyk, but
> you could certainly see it as a separate issue.
>
>
>
> Another item I want to mention, is that there is a lot missing in SVG to
> make it a suitable format for prepress.
>
> True CMYK, spot, DeviceN, overprint, transparency blend spaces and a better
> model for icc are just a start to what's needed.
>
>
>
> True, although my original question relates to the interpretation of
> functionality that has been in the specification for years.
>
> How do you convert a cmyk input color? Do you always composite (and thus go
> through sRGB, or not)?
>
> What is the rendering intent used to transform the sRGB composition space
> to the device space in SVG1.1 (it appears undefined)?
>
> Related to this I had some thoughts about functionality in SVG Color (how
> do you composite intents? how do you composite spot colors?) and missing
> functionality (black preservation).
>
>
>
> I think the goal is admirable and you’ve got to start somewhere. Clarifying
> the current specification isn’t a bad place to start I think.
>
>
>
>  The eyedropper trick might not even work if the image is let’s say cmyk
> swop and I’m outputting to cmyk fogra. The conversion between 0,0,0,1 swop
> and fogra with preserve-black on is different from the conversion with
> preserve-black off.
>
>
>
> It will work if your source elements all have the same profile.
>
> That way all your content will be color managed the same way during the
> swop to fogra color link.
>
> (This is the 'convert to destination workflow' in InDesign where your
> document profile is swop and destination profile is fogra)
>
>
>
> No, it won’t because if you’re automatically enabling black-preservation
> for solid fills and not for images, the underlying rectangle will end up
> with zeros for the cmy values, and the black pixels in the image wont – they
> will most likely end up as some sort of rich black in fogra.
>

read below for a description.


>
>
>
>
> Why do I want my images to use rich black? Imagine an image of Tinkerbel on
> a black background. Tinkerbel, being a fairy, has a halo around it which is
> a gradient from light-green to black. You don’t want the gradient to switch
> from a mix of different colors and gradually more and more black to just
> black as soon as the gradient hits #000. This transition would be noticeable
> in the image as the black only is probably a bit lighter than the
> (supposedly lighter) pixel next to it which is a mix of black and a bit of
> other colors. There is a good reason for why your automatic algorithm
> chooses rich black for images.
>
>
>
> I'm not sure if this is needed.
>
> I know for a fact that gradients that use NChannel color going from black
> to spot just interpolate linearly between the two values in Illustrator and
> InDesign.
>
>
>
> I’m talking about a visual gradient in the raster image of Tinkerbel trying
> to build a visual image for the reader, it isn’t a vector graphics gradient
> and it doesn’t use spot colors, so there is nothing to interpolate between.
> It’s all just pixels, and the almost-black pixel with a tiny bit of blue
> will be closer to rich black than plain black which is what the adjacent
> black pixel will be converted to if black-compensation is enabled.
>

I fail to see why a gradient is different from an image...


>
>
>
>
> Lcms2 implemented this an extension, I don’t believe it’s part of ICC
> (yet?). Not sure how he does it, that part is black magic to me (no pun
> intended). Somehow though there is a special case that avoids adding cmy
> components when black and grays are converted to a cmyk profile.
>
>
>
> I’m not sure “preserve numbers” is what you need. The way I read it, this
> just disables color management. Sure, plain black will be preserved, but so
> will all the other color values, and my SWOP cmyk image won’t look very good
> on my FOGRA calibrated printer …
>
>
>
> from the online documentation:
>
> *Convert to Destination (Preserve Numbers): *Converts colors to the
> destination profile space only if they have embedded profiles that differ
> from the destination profile (or if they are RGB colors, and the destination
> profile is CMYK, or vice versa). Untagged color objects (those without
> embedded profiles) and native objects (such as line art or type) are not
> converted. This option is not available if color management is off. Whether
> the profile is included or not is determined by the Profile Inclusion
> Policy.
>
>
>
> I’m probably a bit thick-headed, but now I’m even more confused. What’s
> being preserved when this is turned on? Native objects? How are their colors
> specified? Always in the device’s color space? What happens if you attach a
> cmyk colorspace to a native object (Is this possible in InDesign? It is in
> SVG)? Is it converted? If so, how is black preserved? If not, you’re aren’t
> color managing native objects.
>
>
>

InDesign lets you aggregate any object with any profile.
Content that is drawn in InDesign itself (such as text and vector art) is
tagged with a document wide profile.
The profiles of placed CMYK images are ignored by default because most of
the time people include profiles by mistake and don't want color managment
on the pixels. (You can override this behavior if you want.)
Placed content such as EPS and PDF will come in with their own profiles, or
if they don't have them, will come in as untagged.

With the preserve numbers options, the following happens:
InDesign vectors, InDesign text and untagged content are not converted. The
CMYK values stay the same but are retagged with the new profile.
Content that has a profile different from the destination profile, will be
converted. (RGB-> CMYK or CMYK->CMYK, there is no intermediate RGB step)
So:
- your text -> same values + output profile
- your image -> by default same values + output profile
- tagged content ->if profile is different do color conversion. otherwise
pass values through

This is the common export path for Print and PDF from InDesign. There are
many more ways to do color managment (including proofing) so most use cases
can be accomplished.
Transparency also throws in some interesting color side effects...

My point here is that the algorithms to do color managment should not be
defined in the language. The SVG spec should be defined such that it can
describe color in a similar way to PDF and PostScript but it should not be
in the business of defining prepress workflows. That route is just to
nebulous to define and is best left to your design application or workflow
system. Adobe originally had grand ideas of tagging everything and designing
workflows around ICC, but it was too hard for customers to set up,
understand and maintain.

There are public and Adobe specific standards (such as job ticket) for
prepress workflows that SVG could adopt.

Rik Cabanier
Adobe Systems

> *From:* Rik Cabanier [mailto:cabanier@gmail.com]
> *Sent:* dinsdag 2 augustus 2011 18:14
>
>
> *To:* Nick Hofstede
> *Cc:* www-svg@w3.org
> *Subject:* Re: minutes, SVG WG Seattle F2F 2011 day 3 - SVG Color
>
>
>
> Hi Nick,
>
>
>
> how would you match the black in the background with the black in the
> image? You might not know what profile was used to create the image.
>
> I think the website is warning you not to rely on Photoshop's black when
> you do CMYK. This is really a design error.
>
> If you can't fix the image, you could use the eyedropper to get the numbers
> and match the border with the rich black. Hopefully nothing else will touch
> that box :-)
>
>
>
> Can you tell me what you mean by:
> > That way any gradient in the image (the example image doesn’t really have
> one, but imagine a picture that fades to black on the edges) is nice and
> continuous.
> How would rich black help with that?
>
>
>
> > Lcms2 added this extra option (no-preservation, black only, black-plane)
> by duplicating its intents
> Reading the comments, I don't really understand how this feature works. Is
> this done just through ICC?
>
> InDesign introduced a way of doing this a couple of releases ago. They call
> this feature "preserve numbers". see
> http://indesignsecrets.com/getting-accurate-colors-when-printing-proofs-from-indesign.php
> .
>
> That page also has a short description how InDesign handles CMYK values.
>
>
>
> Rik Cabanier
>
> Adobe Systems, Inc
>
>
>
> On Tue, Aug 2, 2011 at 12:14 AM, Nick Hofstede <
> Nick.Hofstede@inventivegroup.com> wrote:
>
> No, the profile on the image is correct. I want the image to use rich
> black. That way any gradient in the image (the example image doesn’t really
> have one, but imagine a picture that fades to black on the edges) is nice
> and continuous.
>
> Therefore, if I put the image on a black background or want to put a black
> border on it, I want that black to be rich black as well.
>
> If we’re going to decide automatically that all solid filled black (and
> presumably gray) shapes and strokes will use preserve-black, this isn’t
> going to happen.
>
> That’s why I think we need an extra switch for the preserve black option.
>
> Lcms2 added this extra option (no-preservation, black only, black-plane) by
> duplicating its intents, but an optional switch seems cleaner to me. (
> http://sourceforge.net/apps/trac/mpc-hc/browser/trunk/src/thirdparty/lcms2/src/cmscnvrt.c?rev=3024see DefaultIntents[])
>
>
>
> Nick Hofstede
>
> R&D Manager
>
> *From:* Rik Cabanier [mailto:cabanier@gmail.com]
> *Sent:* maandag 1 augustus 2011 19:26
> *To:* Nick Hofstede
> *Cc:* www-svg@w3.org
> *Subject:* Re: minutes, SVG WG Seattle F2F 2011 day 3 - SVG Color
>
>
>
> Hi Nick,
>
>
>
> I think this is a case where you want to ignore the profile that is
> attached to the image and swap it out with the destination profile instead.
>
>
>
> There was a discussion at the f2f why we would need to swap out the
> attached profile. This seems to be a valid use-case for such a feature.
>
>
>
> Rik Cabanier
>
>
>
> On Mon, Aug 1, 2011 at 12:07 AM, Nick Hofstede <
> Nick.Hofstede@inventivegroup.com> wrote:
>
> Quick note on the black preservation:
>
>    ChrisL: last issue is preserving black.
>    ... For example, in ICC if you specify cmyk(0,0,0,1),
>    color-management systems tend to have a switch that specially treats
>    that value.
>    ... So even if the system does color-manipulation normally, that one
>    color will instead stay solid, total black.
>    ... This is so black text stays pure black and doesn't mix in other
>    colors.
>    ... So, similarly, we need to see if we need it, and see if it's an
>    input or output feature.
>
>    cabanier: We have it in InDesign, and it's an output feature there.
>    ... So we have some special cases there again; you don't want to
>    preserve black on an image.
>
>    ChrisL: So that's basically actually being an input feature.
>
>    heycam: Does it make sense to have this controllable on images, or
>    if we can magically just apply it to solid-color fills and strokes?
>    ... Also, if you have some colored shapes which are composited
>    together, and you happen to get black out of that, should that be
>    preservable?
>
>    TabAtkins_: So it sounds like we can just specify that solid-color
>    strokes and fills automatically preserve black, and nothing else
>    does. It can be applied on output, and doesn't need to be specified
>    on input.
>
>    cabanier: So we look at the operator on printing - if a shape is
>    filled with an image or gradient, we don't preserve black. If it's
>    filled with a color, we preserve.
>
>    TabAtkins_: So if you composite a partially-transparent gradient
>    over a black rectangle, you wouldn't preserve the black in it.
>
>    heycam: So basically, for any image, track if the result color comes
>    partially from a gradient or image. If so, don't preserve black;
>    otherwise, preserve it.
>
>    TabAtkins_: So it sounds like we can do this automatically at the
>    end, and thus don't need a property for it.
>
>    heycam: And in PDF, it's not controllable; it just happens
>    automatically.
>
> I'm not sure automatically deciding when to use black preservation is a
> good idea. I don't think you can always deduce it automatically and I think
> you should therefore be able to specify it.
> Consider the use case talked about here for example:
>
> http://www.blog.spoongraphics.co.uk/articles/the-ultimate-guide-to-designing-with-black
> If you would create this in SVG your underlying rectangle would become
> black-preserved black, and the black from the image would be rich black.
> You're going to want to be able to trigger rich black on the solid-color
> fill.
>
> With kind regards,
>
> Nick Hofstede
>
> ________________________________
>
> Inventive Designers' Email Disclaimer:
> http://www.inventivedesigners.com/email-disclaimer
>
>
> ------------------------------
>
> Inventive Designers' Email Disclaimer:
> http://www.inventivedesigners.com/email-disclaimer
>