490964 - PNG alpha channel handling differs from PNG spec, section 13.16.

Status: NEW

(Core :: Graphics: Color Management, defect)

Description

[Daniel Neville]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10

Firefox composites semi-transparent PNGs onto the background incorectly. The PNG spec (Section 13.16, "Alpha channel processing") requires the blending to be done in the linear-light ("uncompressed") colour space. If the system's encoding gamma is unknown, then an encoding gamma of 1/2.2 (and thus a decoding gamma of 2.2) should be assumed. Firefos acts as if it (correctly) assumes (or gets right) a decoding gamma of 2.2 for displaying images, but incorrectly (and rather inconsistently) assumes a decoding gamma of 1.0 during the composition of semi-transparent images.

I've created some test images that are composited within the browser and reference images that a composited according to the PNG specification. (See URL).

Reproducible: Always

Steps to Reproduce:
1. Find or create any PNG image with partially transparent pixels. Thin lines and regions at opacities close to 50% show the strongest effect.
2. Have Opera (or Firefox) display the semi-transparent image on any background. Complementary and triad colours show the strongest effect.
Actual Results:  
The right side of the test images of radial lines, composited within the browser show lines of grossly varying colour and intensity (The left sides are pre-composited according to the PNG spec at http://www.w3.org/TR/PNG/#13Alpha-channel-processing.)

Expected Results:  
Thin lines drawn in the same colour should appear the same colour and intensity whatever orientation the line is drawn. Moiré should be minimal. 50% black plus 50% white should comes to a shade significantly lighter than mid-grey (#bababa on a gamma 2.2 system, as the PNG spec implies).

Though most computer programmers are not aware of it, most simple images on PCs are stored in a compressed form - even ostensibly uncompressed images. The compression is in the form of assigning equal steps in the recorded pixel level values to equal steps of human-perceived brightness, though at non-linear steps of intensity. Thus images that would require 13 bits per channel normally can be squeezed into a mere 8 bits per channel.

However, all image operations including blending, scaling, rotation, sub-pixel positioning and even simple brightness adjustments can only be performed correctly with image/pixel values in their linear, "uncompressed" form. Performing image arithmetic directly on gamma-compressed images produces strange colour shifts and brightness variations. It's like working with JPEGs in Photoshop, though those are spatially compressed as well.

The results of performing linear operations directly on gamma-compressed images are plain weird, though I understand many computer types have become so used to it that they consider the artifacts normal, but video engineers having been trying to tell them otherwise for about thirty years.

Outside of fixing the PNG compositing in browsers, there is no ready solution. Contriving PNGs with alpha values and foreground colours to display the desired colours in anticipation of how browsers incorrectly blend them into the background image means the artist must contrive PNGs to blend correctly for particular background colours or images. It's a mild form of the old practice of pre-compositing the background colour into "anti-aliased" GIFs. It's hard work for artist types like me.

I'd love to see browsers like Firefox display PNGs according to the specification. It would make designing semi-transparent images _so_ much easier!

Comment 1

[Daniel Neville]

Attachment: PNG compositing test page and images (zipped)

The top-left quadrant of the image shows a uniformly greenish image correctly composited onto a uniformly orange-red background. The bottom-left quadrant of shows a uniformly pinkish image correctly composited onto a uniformly light blue background. Both assume a decoding gamma of 2.2, as most images are by default. The result of the composition is according to the PNG specification on alpha channel processing.

The quadrants on the right side are a screenshot of what Firefox displays when compositing the foreground and background images. Noticeable effects are: Jagged edges; strong Moiré; Shifting of colour hues (the blue in particular); intensity variations (the green varies from being a bit lighter to much darker than the background) and the thicknesses of the same line drawn at different angles.

This image is uploaded just in case my toy site www.realhamster.com/test/ falls over or gets slashdotted while the bug is being investigated.

Comment 2

[me]

Attachment: Wrong rendering example

Is this rendering issue caused by this bug (from the text it seems so).

Comment 3

[Daniel Neville]

Attachment: Synthetic examples of gamma correction to show the similarity between text and PNG rendering

The edge artefacts displayed by poorly rendered text is very similar to those of poorly composited PNGs. In the case of textural images, the problem is identical.

Naïvely rendered text tends to appear stroked with uneven weights: Compared to the surrounding text, letters with diagonal strokes like those in "Awww!" is rendered as if it were in bold when drawn in black on white, thinned if rendered in white on black.

The PNG standard of assuming a decoding gamma of 2.2 produces acceptable results—far better than the naïve method (which ignores the fact that displays are often stored gamma-compressed format optimised for compact prerecorded images rather than for realtime synthetic images as is becomming more common on highly interactive desktops).

In the case of text, Maxim Shemanarev suggest using a gamma of 2.0. I guess that cause for that working so well is that on low resolution displays, humans are partially judging the width of the glyph strokes in pixels rather than the total area of coverage that is faithfully emulated by a more pshyically realistic gamma correction.

Comment 4

[Daniel Neville]

(In reply to comment #2)
> Created attachment 504085 [details]
> Wrong rendering example
> Is this rendering issue caused by this bug (from the text it seems so).

Yes, text rendering and PNG composition both involve composition of images, though most often, the anomalies displayed by naïve text rendering are limited to inconsistent stroke weights (like a blotting fountain pen) because text is mostly black on white or white on black. 

Your example includes a rounded border. I've recreated the same border but with a fully black outline in uncorrected and corrected modes on Attachment 504187 [details]. It's possible that some artists are motivated to use subdued stroke colours in order to reduced edge artefacts in addition to more artistic reasons. (It's like how the Commodore 64 had dull colours in order to not overload the the simple video output modulator). Gamma correction removes the restriction.

Comment 5

[Benoit Girard (:BenWa)]

Jeff are you sure this bug falls within color management?