Page MenuHomePhabricator

rendered SVG images should use sRGB chunk
Closed, ResolvedPublic


Author: jacobolus


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:

T21960 - 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.



Version: unspecified
Severity: minor



Event Timeline

bzimport raised the priority of this task from to Low.Nov 21 2014, 11:08 PM
bzimport set Reference to bz24768.
bzimport added a subscriber: Unknown Object (MLST).
bzimport created this task.Aug 12 2010, 7:20 PM
TheDJ added a comment.Nov 4 2010, 4:43 AM

The thumbnails are created by librsvg, so this is a bug in librsvg.

jacobolus wrote:

That could be, but if they don’t care we could also easily workaround it after the PNGs have been created.

Moving bug to SVG rendering component

jayvdb added a subscriber: jayvdb.Jul 21 2015, 3:12 AM

Has this been reported upstream?

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJul 21 2015, 3:12 AM

Per the task detail, no bug has been filled upstream:

it might be worth submitting an upstream bug report

gpaumier removed a subscriber: gpaumier.Jul 18 2018, 5:57 PM
Aklapper changed the task status from Open to Stalled.Mar 10 2019, 6:16 PM
Aklapper added a project: TestMe.

Could someone please provide a specific testcase if this problem still happens?

It's hard to re-test bugs (we've switched to Thumbor and upgraded libvsrg a few times since 2010) if no testcase is attached... Thanks in advance!

hashar updated the task description. (Show Details)Mar 11 2019, 9:00 AM
hashar closed this task as Resolved.Mar 11 2019, 9:23 AM

From what I gather, ImageMagick with --thumbnail did strip the color profile when present. That was T21960: Preserve color profile information for thumbs (ImageMagick update) and duplicates:

The SVG spec seems to state that all colors are defined in the SRGB color space and the profile can be changed using color-profile. Eventually I picked a recently uploaded SVG file on commons: Blason ville fr Castéron (Gers).svg, it does not have a color-profile embedded.

The generated thumbnail passed vian ImageMagick identify --verbose yields:

  date:create: 2019-03-11T10:08:31+01:00
  date:modify: 2019-03-11T10:08:31+01:00
  png:bKGD: chunk was found (see Background color, above)
  png:cHRM: chunk was found (see Chromaticity, above)
  png:gAMA: gamma=0.45454544 (See Gamma, above)
  png:IHDR.bit-depth-orig: 8
  png:IHDR.bit_depth: 8
  png:IHDR.color-type-orig: 6
  png:IHDR.color_type: 6 (RGBA)
  png:IHDR.interlace_method: 0 (Not interlaced)
  png:IHDR.width,height: 900, 990
  png:sRGB: intent=0 (Perceptual Intent)
  png:text: 2 tEXt/zTXt/iTXt chunks were found
  signature: c5fb3d453ed415d69cb40b3fccd2882ab3c4f1a399272631cf5698695ed2646e

And from the original bug report:

The PNG spec suggests that PNG encoders embed both an sRGB chunk a gAMA chunk (& optionally a cHRM chunk)

Thus we have the png:cHRM, png:gAMA and png:sRGB chunks inserted. For Chromacity and Gamma:

Gamma: 0.45455
  red primary: (0.64,0.33)
  green primary: (0.3,0.6)
  blue primary: (0.15,0.06)
  white point: (0.3127,0.329)

So I assume the original intent got implemented somewhere in librsvg/imagemagick at some point.

Note that after close to a decade, browser probably respect those chunks nowadays. At least Firefox 60.5 seems to behave properly on the test page