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.
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.
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.
Can you repro with Windows builds of Firefox run under Wine?
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.
Attached is the same png without the sRGB, gAMA, and cHRM chunks. Does this exhibit the same behavior?
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.
Assignee: nobody → glennrp+bmo
Status: NEW → ASSIGNED
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
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.
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.
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
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → INVALID
Alternative fix: replace the red-green.png file by the stripped file. That's probably the least intrusive fix to apply to the test.
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.
The test was buggy, was requiring canvas2D drawImage to not do colorspace conversion.
You need to log in before you can comment on or make changes to this bug.