I have a 2-pixel PNG image with the following rgba:
image.setAt(0, 0, { red:255, green:10, blue:10, alpha:100 });
image.setAt(1, 0, { red:255, green:255, blue:55, alpha:255 });
image.setAt(0, 1, { red:90, green:10, blue:65, alpha:250 });
image.setAt(1, 1, { red:60, green:255, blue:0, alpha:14 });
(using node's pngjs-image module)
When the image is loaded by the browser (firefox) and copied to canvas to test the rgba data, the following is returned:
255 7 7 100
255 255 55 255
89 9 64 250
54 255 0 14
It seems like only Alpha channel values are preserved while pixel colors are arbitrarily changed.
What's going on?
(using Firefox 41 on Linux)
EDIT
From intro on pngtoy nodejs module I have found the following:
Low-level implementation of PNG file parser/reader/decoder using JavaScript on client size.
Why this when browsers support PNG already?
The browser will simply load and convert any PNG type into RGBA bitmaps. It will also apply ICC and gamma correction to the image resulting in different values than in the original bitmap.
However, I thought that PNG itself should have ICC and Gamma correction chunks so that the browser applies them. Does the browser make such image manipulation to any png file even without ICC/gamma chunk inside the file?
Firefox converts images with alpha to pre-multiplied alpha for internal use. If your workflow is recovering the image from Firefox' internal image buffer, there will be loss of precision when reversing the pre-multipled alpha. In the extreme, pixels with alpha equal to zero will be returned as transparent black, regardless of the underlying color in the original PNG. This effect doesn't depend upon whether color management chunks are present or not.
Note that this doesn't happen when you click on a PNG image and "save as..."; in this case the original PNG is returned.
Firefox may also modify the internal image (depending upon the setting of gfs.color_management.mode in "about:config") when color management chunks (iCCP, sRGB, gAMA, and/or cHRM) are present, but that does not seem to be the case for this particular question. Again, "save as..." will return the original pixels and the color management chunks unchanged.