Bug 5972 – SVGs are not drawn colormatched

• Component: SVG
• Status: RESOLVED WORKSFORME

[Eric Seidel (no email)]

SVGs are not drawn colormatched

The svg specification states that all colors are specified in sRGB unless otherwise defined.  This means we 
have to color match SVGs by default.  This is not currently the case.
http://www.w3.org/TR/SVG/color.html

This is related to 
http://bugzilla.opendarwin.org/show_bug.cgi?id=4515

This will also affect bugs like:
http://bugzilla.opendarwin.org/show_bug.cgi?id=5970

[Eric Seidel (no email)]

This is a pretty basic feature of SVG.  I think it would be a mistake to ship an SVG viewer w/o this feature, but I don't see it as a truely blocking bug.  Adding to the SVG HitList for now and marking as P3.

Supporting this would require adding colorspace infrastructure so that colors would be created in the proper colorspace instead of Device/Generic RGB like they are now.

[Alexander Kellett]

leaving as p3 but removing svghitlist keyword after discussion with macdome

[Alexey Proskuryakov]

Created attachment 9086 [details]
compare CSS, image and SVG colors

An argument can be made against fixing this. 

1) HTML and pictures are not drawn color matched unless a profile is specified, and we probably want to have matching color in compound documents (see the test case, which currently passes).
2) sRGB is the lowest common denominator, so enabling it as a default will suddenly make colors look dull.
3) Color matching often introduces dithering, which may be undesirable (and when it doesn't, it introduces banding on gradients).

[Alexey Proskuryakov]

Created attachment 9087 [details]
effects of color matching

The nice gradient above is drawn using SVG. The second one is a JPEG with an embedded profile - the colors are dull, and banding is visible (even with the dithering performed by CoreGraphics).

Firefox 1.5 doesn't support embedded profiles, so both gradients look the same there.

[Jonathan Payne]

> 2) sRGB is the lowest common denominator, so enabling it as a default will
> suddenly make colors look dull.

Whether colours look more dull will depend on the gamut of the viewers monitor - it will make colours look more dull on a monitor with a larger gamut than sRGB, but more vibrant on a monitor with a smaller gamut than sRGB. What it will do is make the colours look correct.

This obviously doesn't invalidate the other two very good points

[Alexey Proskuryakov]

(In reply to comment #5)
> - it will make colours look more dull on a monitor with a larger gamut than
> sRGB, but more vibrant on a monitor with a smaller gamut than sRGB.

I used to be under an impression that all modern monitors have a gamut that's much larger than sRGB (and mobile devices that are likely to have poorer screens don't have system support for color management anyway). I'll be the first to admit that I have never really investigated this, though.

[Jonathan Payne]

(In reply to comment #6)
> (In reply to comment #5)
> > - it will make colours look more dull on a monitor with a larger gamut than
> > sRGB, but more vibrant on a monitor with a smaller gamut than sRGB.
> 
> I used to be under an impression that all modern monitors have a gamut that's
> much larger than sRGB (and mobile devices that are likely to have poorer
> screens don't have system support for color management anyway). I'll be the
> first to admit that I have never really investigated this, though.
> 

Well my iBook monitor has a gamut smaller than sRGB according to ColorSync Utility (after being calibrated with a Spyder). I am probably in the minority though I suppose.

[Alexey Proskuryakov]

Color gamut of a LED-backlit display vs. sRGB: <http://www.fcenter.ru/img/article/monitors/lcd_2/96026.png>.

Would be nice to know the rationale for requiring sRGB by default - it seems extremely arbitrary and limiting to me.

[Eric Seidel (no email)]

sRGB is just the default colorspace for SVG colors.  The current behavior is to use whatever the device color space is (thus no color matching) which means that your bitmap image and SVG colors don't look the same.   If we were actually to support this, you could change the default profile using @color-profile or <color-profile>.  See http://www.w3.org/TR/SVG/color.html

[Alexey Proskuryakov]

(In reply to comment #9)
> sRGB is just the default colorspace for SVG colors.

  Yes - I'm questioning why it was chosen for the spec, not the validity of this bug. 

> If we were actually to support this, you could change the default profile using
> @color-profile or <color-profile>.  See http://www.w3.org/TR/SVG/color.html

  The problem is that there is no "device RGB" option to request the current (no matching) behavior then, and such behavior is desirable in some cases.

[Eric Seidel (no email)]

Well, at least it's consistent with CSS3:
http://www.w3.org/TR/css3-color/#color-profile

There are a couple possibilities here.  We could invent a "none" or "device" to mean the current behavior.  Or (more likely) we could keep the current behavior (since no browser color matches, period) and only make @color-profile opt-in.

[Jon@Chromium]

http://code.google.com/p/chromium/issues/detail?id=2602

[Dirk Schulze]

Ok, either this big goes fixed somehow, or we have a regression. Anyway, there is no difference between the rects. Can we exclude that the color profile for images (or what ever) is not working?

[Alexey Proskuryakov]

The test case passes on Mountain Lion and newer. If there are any remaining issues, let's track them in separate bugs.