Last modified: 2012-03-04 10:55:53 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T26768, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 24768 - rendered SVG images should use sRGB chunk
rendered SVG images should use sRGB chunk
Status: NEW
Product: Wikimedia
Classification: Unclassified
SVG rendering (Other open bugs)
unspecified
All All
: Low minor (vote)
: ---
Assigned To: Nobody - You can work on this!
: upstream
Depends on:
Blocks: svg
  Show dependency treegraph
 
Reported: 2010-08-12 19:20 UTC by Jacob Rus
Modified: 2012-03-04 10:55 UTC (History)
4 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Jacob Rus 2010-08-12 19:20:48 UTC
# Two-sentence summary:

By the SVG spec, and in order to properly display the colors of such images as flags, logos, and infographics pertaining to color, the PNG files rendered from SVG by Wikimedia sites should have the sRGB chunk included, so that at least those browsers which do color management of properly constructed images will treat them appropriately. Currently, the rendered PNG files have no included information on the color space of their contents, and browsers therefore display these images improperly.


# More detail:

The SVG specification demands that: [1]

"At a minimum, SVG user agents shall conform to the color behavior requirements specified in the color units section and the minimal gamma correction rules defined in the CSS2 specification."

In particular: [2, 3]

"All RGB colors are specified in the sRGB color space (see [SRGB]). User agents may vary in the fidelity with which they represent these colors, but using sRGB provides an unambiguous and objectively measurable definition of what the color should be, which can be related to international standards."

Since Wikimedia sites render PNG files out of SVGs, the user agent should (in my opinion) be considered the combination of SVG -> PNG rendering on the Wikimedia servers plus browser display of the generated PNG files.

Currently, the PNG files produced on Wikimedia sites include no color management information. It might be argued that this should be sufficient, and that browsers should treat untagged images as sRGB by default. Unfortunately, browsers do not do this. [4, 5, 6, 7] (From the last of those links: "The big hurdle that we ran into, though, was with the drawing we did not control, namely the Flash plug-in. The problem is that designers specify colors in Flash and colors in CSS in the Web page, and they expect those colors to match.")

The PNG file format [8] makes it easy to concisely and unambiguously declare an image to be sRGB, twiddling only a few bits in the middle of the file (i.e. no need for a large embedded profile) by adding an "sRGB chunk". For the kinds of images typical of Wikimedia site SVG files – such as logos, maps, & infographics – the "relative colorimetric" intent should be used. ("Perceptual" might be better for some photographs, though I typically prefer relative colorimetric for those too; the other two intents should be reserved for niche use cases.)

The PNG spec suggests that PNG encoders embed both an sRGB chunk a gAMA chunk (& optionally a cHRM chunk), but I personally do not know whether common PNG decoders such as those in browsers deal properly with images including both types of color management hint. I would recommend only including the sRGB chunk unless/until browser behavior is more precisely known: I remember there were some poorly behaved browser PNG decoders w/r/t various edge cases, in the past (e.g. I believe when pngcrush writes an sRGB chunk it leaves off the gAMA chunk). If only the sRGB chunk is included, then decoders which know how to deal with it will do the correct thing, and decoders which do not will behave as they currently do with Wikimedia site SVG renders.


# What should be done to fix this bug:

I don’t know the details of Wikimedia site’s current SVG -> PNG rendering. There are two approaches I can imagine: (1) Flip a parameter somewhere and have the current SVG renderer start including the sRGB chunk in PNG files it creates; or (2) If that is impossible, pass rendered PNG files through a second program which adds the sRGB chunk. This could 

If the SVG renderer does not currently have an option for including color management information, it might be worth submitting an upstream bug report, so that even if option (2) is immediately necessary, option (1) might someday become possible. Again, I don’t know even what the current SVG -> PNG renderer is.


# See also:

Bug 19960 - Preserve color profile information for thumbs (ImageMagick update) [9]

This previous bug was about preserving color profiles for thumbnails of images. This current bug is sort of the same idea, but for SVG source files, instead of PNGs/JPEGs.


# References:

[1] http://www.w3.org/TR/SVG11/color.html#ColorIntroduction
[2] http://www.w3.org/TR/2008/REC-CSS2-20080411/syndata.html#color-units
[3] http://www.w3.org/Graphics/Color/sRGB.html
[4] http://regex.info/blog/photo-tech/color-spaces-page2
[5] http://regex.info/blog/photo-tech/color-spaces-page3
[6] http://regex.info/blog/photo-tech/color-spaces-page7
[7] http://webkit.org/blog/73/color-spaces/
[8] http://www.w3.org/TR/PNG/#11sRGB
[9] https://bugzilla.wikimedia.org/show_bug.cgi?id=19960
Comment 1 Derk-Jan Hartman 2010-11-04 04:43:29 UTC
The thumbnails are created by librsvg, so this is a bug in librsvg.
Comment 2 Jacob Rus 2010-11-04 04:58:45 UTC
That could be, but if they don’t care we could also easily workaround it after the PNGs have been created.
Comment 3 Antoine "hashar" Musso (WMF) 2012-03-04 10:55:53 UTC
Moving bug to SVG rendering component

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links