Page MenuHomePhabricator

PNG thumbnails of SVG images should use sRGB chunk
Open, LowPublic

Description

Author: jacobolus

Description:

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.

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


Version: unspecified
Severity: minor

Details

Reference
bz24768

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

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

Has this been reported upstream?

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

it might be worth submitting an upstream bug report

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!

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:

Properties:
  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
Chromaticity:
  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 http://regex.info/blog/photo-tech/color-spaces-page2

VZpolodov added a subscriber: VZpolodov.

gAMA of 0.45454544 is not sRGB, not at all, the sRGB tranfer function is piecewise. It destroyes the picture in mastercard article (see my comment there on talk page) and in SMPTE color bars (in both cases it should be the same 8 bit values, check with Chrome, Photoshop still does not support gAMA, sigh).

PNG spec says that if you do not know the colorspace of the original file (here you do know, but it is just because all of web is like that) you do not use any chunks on the file. Please add sRGB chunk (it will override gAMA and cHRM) or remove all of the chunks. Thanks.

Indeed Chrome supports gAMA chunk.

Also your file https://upload.wikimedia.org/wikipedia/commons/a/a9/Blason_ville_fr_Cast%C3%A9ron_%28Gers%29.svg converted to png does not have sRGB chunk, which is wrong. Please use normal tools, like exiftool to check for sRGB chunk.

You will also have to regenerate all of images from svg on wikimedia, or at least remove gAMA chunk using pngcrush -rem gAMA (you can also try -m 44 while reencoding or ffmpeg with -compression_level 9 -pred mixed to reduce the size of png). What can I say.

Or you can try some other tool, since pngcrush will reencode.

Why you are not just using SVG directly??

Aklapper renamed this task from rendered SVG images should use sRGB chunk to PNG thumbnails of SVG images should use sRGB chunk.May 5 2021, 10:32 AM
Aklapper added a project: Thumbor.
Aklapper removed a subscriber: wikibugs-l-list.

Hi @VZpolodov, the last question is off-topic for this ticket - please feel free to bring up such questions in general discussion places. Thanks.

off-topic for this ticket

This is just an idea on how to not regenerate all images.

@VZpolodov: Yes, however, this task is only about PNG thumbnails of SVG images should use sRGB chunk, not about discussing the general image setup...

Any updates? ImageMagick agreed this is a bug.

No updates, otherwise they'd be mentioned here. (In general.)

No updates, otherwise they'd be mentioned here. (In general.)

The PNG file is created by librsvg, so librsvg should insert the sRGB chunk.

Has this been reported upstream?

I did not find any bug report upstream at Gnome.

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!

This issue came up on Commons about a month ago. Users were confused because RGB values on their screen did not match the RGB values in the SVG file (that is the expected result of color correction).

The simple test would look at the PNG produced by any vanilla SVG file. That PNG file should have an sRGB chunk.

http://www.libpng.org/pub/png/spec/1.2/PNG-Chunks.html#C.sRGB

Hashar above suggests that ImageMagick identify --verbose applied to the PNG file should list the chunks "IHDR", "IDAT", "sRGB", and "IEND".

https://imagemagick.org/script/identify.php

ImageMagick fixed the issue. Apprently it was a one == vs != mistake violating the documentation.

gAMA chunk is no longer written in SVG case.

https://github.com/ImageMagick/ImageMagick/commit/b51609986ae9d40ed0ea68bd8698a90f6d498b1f

So regenerate all?

ImageMagick fixed the issue. Apprently it was a one == vs != mistake violating the documentation.

gAMA chunk is no longer written in SVG case.

https://github.com/ImageMagick/ImageMagick/commit/b51609986ae9d40ed0ea68bd8698a90f6d498b1f

So regenerate all?

There is an step before that. First ImageMagick needs to be upgraded, see T233196. Not sure that upgrade is to an 3 day old version (as of this comment).