Ken Shirriff Reporter
	Description • 11 years ago

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.0.1547.66 Safari/537.36

Steps to reproduce:

I have a 4700x5000 png. I load the image into the browser and click the magnifying glass to view it full size, and take a screenshot.


Actual results:

Most of the pixels are correct, but some are off by 4: #000004 and #0000fb when they should be #000000 and #0000ff. The difference is small, so it looks correct visually, but the displayed pixels are wrong.



Expected results:

Image should have pixel values of #000000 and #0000ff in certain places.

Note: I originally found this while using getImageData() in JavaScript and my program failed because of the unexpected values. For simplicity, I reproduced the problem by simply displaying the image. This shows the problem isn't in the screen rendering / cut-and-paste process but in the underlying pixel data.

The image displays correctly in Chrome. I've verified in Gimp that the pixels in the original PNG are as expected.

Since the image is very large, I hesitate to attach it unless someone requests it. I couldn't reproduce the problem with a smaller image unfortunately.

I am using Windows 7. This happens on Firefox 23.0.1. (It happened to me 13.0 but still happens after upgrade to 23.)

	Mardeg
	Comment 1 • 11 years ago

Can you reproduce this with the about:config pref:
gfx.color_management.mode
set to 0?

	Ken Shirriff Reporter
	Comment 2 • 11 years ago

Yes, it reproduces with color_management.mode set to 0 (old value was 2).

	Glenn Randers-Pehrson
	Comment 3 • 11 years ago

Does the PNG contain an iCCP or sRGB chunk?  Does it have an alpha channel?
You can use "pngcheck -v file.png" or "pngcrush -n -v file.png" to find out.

	Glenn Randers-Pehrson
	Comment 4 • 11 years ago

Possible dupe of bug #903674, although that was seen in a small image.  The blue channel was off more than the red and blue channels in that image too, and it seems to be due to how the sRGB chunk is handled.

	Ken Shirriff Reporter
	Comment 5 • 11 years ago

E:\Users\Ken\Downloads\pngcheck-2.3.0-win32>pngcheck -v stack3.png
File: stack3.png (530862 bytes)
  chunk IHDR at offset 0x0000c, length 13
    4700 x 5000 image, 24-bit RGB, non-interlaced
  chunk sRGB at offset 0x00025, length 1
    rendering intent = perceptual
  chunk pHYs at offset 0x00032, length 9: 2835x2835 pixels/meter (72 dpi)
  chunk tIME at offset 0x00047, length 7:  7 Sep 2013 15:27:03 UTC
  chunk IDAT at offset 0x0005a, length 8192
    zlib: deflated, 32K window, maximum compression
  chunk IDAT at offset 0x02066, length 8192
...
  chunk IDAT at offset 0x8035a, length 5696
  chunk IEND at offset 0x819a6, length 0
No errors detected in stack3.png (70 chunks, 99.2% compression).

(Can I attach the 530K file, or is that too big?)

I ran pngcrush -rem cHRM -rem gAMA -rem iCCP -rem sRGB to remove the sRGB section, and I still see the problem. So the problem is not caused by sRGB or alpha. So I think it is not a dupe of bug #903674.

	Mardeg
	Comment 6 • 11 years ago

(In reply to Ken Shirriff from comment #5)
> (Can I attach the 530K file, or is that too big?)
That size is fine, go ahead.
Possibly related: bug 652222, bug 693366, bug 823243, bug 867594, bug 899535.

	Ken Shirriff Reporter
	Comment 8 • 11 years ago

Bug 652222 looks like it is very possibly related. The other bugs look to me like they are not related.

I've attached the image that is causing me problems. Specifically, look at the blue letters DF in the upper left corner. The colors should be #000000 and #0000FF (black and blue). If you look at the lower limb (the bowl?) of the D, the blue along the top is #0000FB and the black just below it is #000004. There are other bad pixels on the borders between regions as well.

	Glenn Randers-Pehrson
	Comment 9 • 11 years ago

The behavior seems to be related to the "image.high_quality_downscaling.enabled" setting in about:config.  I disabled it and there were fewer interpolated pixels but there were still some.

	Glenn Randers-Pehrson
	Comment 10 • 11 years ago

See also bug #908711