Change Details

**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: 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 -------------------------- **Version**: unspecified **Severity**: minor

**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

**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: Bug 19960T21960 - 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