746348 - PNG file is mis-read on Windows

Status: RESOLVED INVALID

(Core :: Graphics: ImageLib, defect)

Description

[Benoit Jacob [:bjacob] (mostly away)]

Attachment: the PNG image we fail to read on Windows

The attached png file, also at this URL,

      http://people.mozilla.org/~bjacob/red-green.png

is misread on windows. It's a 1x2 image, should contain the RGBA values

      255,0,0,255
      0,255,0,255

but on Windows, the following pixel values are read instead:

      255,0,0,255
      1,255,0,255

Testcase here:

      http://people.mozilla.org/~bjacob/pngbug.html

This png image is from the WebGL conformance test suite,

      https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/conformance-suites/1.0.1/conformance/resources/red-green.png

and this bug is preventing us from passing this WebGL 1.0.1 conformance test on Windows:

      https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/conformance-suites/1.0.1/conformance/textures/tex-image-and-sub-image-2d-with-image.html

This doesn't seem to happen exactly 100% of times.

Comment 1

[Benoit Jacob [:bjacob] (mostly away)]

Note: replacing the png file by the equivalent data URL,

   data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAACCAYAAACZgbYnAAAAEklEQVQImWP4z8Dwn4HhP8N/ABL3A/3bzyckAAAAAElFTkSuQmCC

makes the problem go away. so this seems like a bug in the actual reading of PNG files.

Comment 2

[Benoit Jacob [:bjacob] (mostly away)]

On a different Windows 7 machine, the pixel values read were even more different:

      252,25,25,255
      2,255,0,255

I'm afraid that there might be uninitialized values here, which would be a security issue, but I can't test it with valgrind as this is Windows-specific.

Comment 3

[Joe Drew (not getting mail)]

Can you repro with Windows builds of Firefox run under Wine?

Comment 4

[Benoit Jacob [:bjacob] (mostly away)]

I haven't tried yet but that's a good idea.

I tried a plain Linux build, just in case. Valgrind memcheck doesn't report any relevant error in my linux build.

Comment 5

[Glenn Randers-Pehrson]

Attachment: The PNG with color managment chunks removed

Attached is the same png without the sRGB, gAMA, and cHRM chunks.  Does this exhibit the same behavior?

Comment 6

[Glenn Randers-Pehrson]

Note that the "equivalent data url" in comment #1 lacks the color management chunks as well, so if the problem is in cms it would not fail.

Comment 7

[Glenn Randers-Pehrson]

Here is a data url for the PNG that includes the color management chunks sRGB, gAMA, and cHRM:

data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAACCAIAAAAW4yFwAAAAAXNSR0IArs4c6QAAAARnQU1BAACxjwv8YQUAAAAgY0hSTQAAeiYAAICEAAD6AAAAgOgAAHUwAADqYAAAOpgAABdwnLpRPAAAAA5JREFUGFdj+M8ABP8ZAAj/Af820qgYAAAAAElFTkSuQmCC

Comment 8

[Glenn Randers-Pehrson]

When I tried Mozilla's "data URI kitchen" to convert red-green.png to a data url, the color-management chunks disappeared.  I made the data url in comment #7 manually with uuencode.

Comment 9

[Benoit Jacob [:bjacob] (mostly away)]

Hah! Thanks a lot Glenn.

Here's an updated version of the testcase that will use the stripped file:

http://people.mozilla.org/~bjacob/pngbug-stripped.html

It passes on my Windows machine, contrary to the original one.

So what's the difference between Windows and Linux here: is it that we only do color management on Windows, or only on Linux? Or do we, in some other way, do it differently?

More important question: if this WebGL conformance test requires pixel-exact rendering of this PNG image, is this a bug in this test? Or should all browsers on all platforms render a given PNG in exactly the same way?

Note that WebGL has an option to disable all colorspace conversions on images. If it's a bug in this test that it requires pixel-exact rendering of PNGs by default, then we could turn on that option.

Comment 10

[Benoit Jacob [:bjacob] (mostly away)]

Had a conversation with Jeff in which he confirmed that this is a bug in the test. It is valid for a browser to color-correct images by default, so that drawing them onto a canvas and reading pixels will give different results based on the color profile.

This means that there is a bug in this WebGL conformance test, making it non-passable on color-corrected browsers+devices. It can be fixed in two different ways:
 - instead of comparing webgl pixels to abstract reference pixel values, compare them to pixels read from a 2d canvas onto which the image was painted.
     pro: will still test the default (possibly color-corrected) path
     con: less trivial to implement
 - set UNPACK_COLORSPACE_CONVERSION_WEBGL to NONE.
     pro: very easy fix
     con: the tests won't test color-corrected paths anymore

Comment 11

[Benoit Jacob [:bjacob] (mostly away)]

Alternative fix: replace the red-green.png file by the stripped file. That's probably the least intrusive fix to apply to the test.

Comment 12

[Benoit Jacob [:bjacob] (mostly away)]

Wait... this test,

https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/conformance-suites/1.0.1/conformance/textures/tex-image-and-sub-image-2d-with-image.html

does call

gl.pixelStorei(gl.UNPACK_COLORSPACE_CONVERSION_WEBGL, gl.NONE);

Further investigation needed; this is starting to look like a possible bug in our WebGL implementation.

Comment 13

[Benoit Jacob [:bjacob] (mostly away)]

The test was buggy, was requiring canvas2D drawImage to not do colorspace conversion.