Bug 5972 - SVGs are not drawn colormatched
Summary: SVGs are not drawn colormatched
Status: RESOLVED WORKSFORME
Alias: None
Product: WebKit
Classification: Unclassified
Component: SVG (show other bugs)
Version: 420+
Hardware: Macintosh OS X 10.4
: P3 Normal
Assignee: Nobody
URL:
Keywords:
Depends on: 5962 121856
Blocks: 6034 5970 6033
  Show dependency treegraph
 
Reported: 2005-12-06 04:09 PST by Eric Seidel (no email)
Modified: 2015-01-19 11:06 PST (History)
9 users (show)

See Also:


Attachments
compare CSS, image and SVG colors (761 bytes, application/xhtml+xml)
2006-06-29 02:50 PDT, Alexey Proskuryakov
no flags Details
effects of color matching (15.19 KB, application/zip)
2006-06-29 03:09 PDT, Alexey Proskuryakov
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Eric Seidel (no email) 2005-12-06 04:09:32 PST
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
Comment 1 Eric Seidel (no email) 2006-01-26 15:03:08 PST
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.
Comment 2 Alexander Kellett 2006-01-27 17:33:12 PST
leaving as p3 but removing svghitlist keyword after discussion with macdome
Comment 3 Alexey Proskuryakov 2006-06-29 02:50:17 PDT
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).
Comment 4 Alexey Proskuryakov 2006-06-29 03:09:07 PDT
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.
Comment 5 Jonathan Payne 2006-06-29 08:58:56 PDT
> 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
Comment 6 Alexey Proskuryakov 2006-06-29 13:38:28 PDT
(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.
Comment 7 Jonathan Payne 2006-07-01 11:30:16 PDT
(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.
Comment 8 Alexey Proskuryakov 2007-01-24 06:07:30 PST
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.
Comment 9 Eric Seidel (no email) 2007-01-24 06:18:27 PST
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
Comment 10 Alexey Proskuryakov 2007-01-24 07:03:42 PST
(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.
Comment 11 Eric Seidel (no email) 2007-01-24 07:40:35 PST
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.
Comment 13 Dirk Schulze 2012-02-01 21:22:30 PST
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?
Comment 14 Alexey Proskuryakov 2015-01-19 11:06:01 PST
The test case passes on Mountain Lion and newer. If there are any remaining issues, let's track them in separate bugs.