RE: luminanceToAlpha values in FEColorMatrix

> Maybe my disconnect comes from thinking about the destination/document profile. Looking through the SVG spec, I can't find what colorspace the colors are mapped to. Is it the device profile or sRGB?

The way I read it, everything gets composited in sRGB or Linear sRGB (after conversion from the specified color space using the specified intent) and then presumably converted to the device profile (with an undefined intent).

Chris has stated recently that pixels that don't have to be composited will be converted from the specified color directly to the device profile using the specified intent.
I'm not sure there are implementations following this interpretation, nor is it very clear to me how this will be handled in future specifications.

In the meantime I'm inclined to state that even though SVG accepts all kinds of input colors, the only feasible working or output space is sRGB (and that's a shame as support for cmyk and spot colors would be more than welcome for those wanting to print SVG vector art)

With kind regards,

Nick Hofstede
R&D Manager

Phone: +32 3 821 01 70<><>
[Description: Linked-In]<>[Description: twitter]<>[Description: newsletter]<>
From: [] On Behalf Of Rik Cabanier
Sent: maandag 12 september 2011 6:26
To: Chris Lilley
Cc: David Woolley; Dean Jackson;; www-svg
Subject: Re: luminanceToAlpha values in FEColorMatrix

On Mon, Sep 5, 2011 at 1:59 PM, Chris Lilley <<>> wrote:
On Sunday, September 4, 2011, 6:06:01 AM, Rik wrote:

RC> I agree.I don't know what makes sRGB so special that it is the
RC> default colorspace in SVG and used all over the spec.

Because it was proposed (and accepted) as a standard default space, in the days when colour management was something that applied solely to high-end printing and Apple was trying to bring it to the desktop while other platforms were silent on the subject or in ostrich mode.

So HTML 3.2 and 4 use it, and CSS 1 and 2. Thus, SVG did also.

RC> Shouldn't SVG be color space agnostic (like PDF and Postscript)?

Agnostic can easily translate to 'throw any value as at the screen and hope for the best'. That wasn't really good enough in 1980 and is certainly not good enough, even as a lowest common denominator, now. Consumer electronics has settled on sRGB while desktops and laptops (but not mobile, yet) has settled on ICC v.4 as a base capability.

Well, by defining it as the standard, you are limiting colors on devices that have a wider gamut than sRGB.

Acrobat lets the user choose what his default space is. Why not let a SVG renderer do the same? You could say in the spec that sRGB is a reasonable default.
Maybe my disconnect comes from thinking about the destination/document profile. Looking through the SVG spec, I can't find what colorspace the colors are mapped to. Is it the device profile or sRGB?

So sRGB as a default was a reasonable choice in 1996 and remains (arguably, has wider industry support) as a fallback for less capable devices in 2011.

So I would disagree on 'agnostic'[1] as a goal, but if you rephrase to "shouldn't SVG allow other colour spaces as well" then I would be in full agreement. As long as there is a clear fallback.

Yes, SVG should support other color spaces natively.
There's been some discussion on spot and cmyk colors but I'm not sure if there is a enough momentum to define it. Especially browser vendors might be hesitant to implement this.

RC>  There are several parts in the spec that talk about 'linear RGB' vs sRGB that are very confusing.

Could you explain why it is confusing. The equations (in both directions) are given, and are fairly simple.

It's not so much about the equations.
Why is it needed? I don't believe that Adobe does this if you're just drawing in RGB or CMYK. (We do play some tricks if you convert to a different colorspace but I don't think that's relevant.)

RC> Maybe there is some history here that I'm not aware of...

Quite a bit, yes.

[1] Either from Ancient Greek ???????? (agn?stos, ?ignorant, not knowing?) or from a- + Gnostic. Deriving (either way) from Ancient Greek ?- (a-, ?not?) + ???????? (gign?sk?, ?I know?).

 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:

Received on Monday, 12 September 2011 08:16:38 UTC