823243 - PNG decoding is not precise

Status: RESOLVED INVALID

(Firefox :: Untriaged, defect)

Description

[vik.nuckchady]

Attachment: Captured_Image.png

User Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20100101 Firefox/17.0
Build ID: 20121128204232

Steps to reproduce:

I created a PNG image file and loaded it in a <Canvas> for pixels processing. The values RGBA channels for a given pixel in the <Canvas> are slightly different to the corresponding pixel in the actual image file. The fact that <Canvas> slightly modifies the pixels makes Firefox an unstable platform for my web application. For comparison, IE10 behaves correctly while Chrome (Version 23.0.1271.97 m) behaves just like Firefox (ver 17.0.1). I did not test on other firefox versions.


Actual results:

When i open the image file in an editor and examine say the 1st pixel, i get the RGBA values of 0, 13, 48, 254. When i look at that corresponding pixel (i.e. pixel at 'coordinate' (0,0)) i obtain the values 0, 12, 47, 254. As you can notice the Green and Blue channel deviate from the true color by 1.


Expected results:

Well in case of correct behavior, the RGBA channels of the pixels in the canvas should be exactly equal to the one in the image file

Comment 1

[Matthias Versen [:Matti]]

Please attach a testcase.

Comment 2

[Robert Longson [:longsonr]]

Have you turned off antialiasing? see mozImageSmoothingEnabled in https://developer.mozilla.org/en-US/docs/DOM/CanvasRenderingContext2D#Gecko-specific_attributes

Comment 3

[Masatoshi Kimura [:emk]]

PNG uses a unpremultiplied alpha while canvas 2D uses a premultiplied one. It's inevitable that the exact RGB values are lost for pixels whose alpha values are not 255 as long as you use canvas 2D.
WebGL has an unpremultiplied alpha mode. Is it reproducible with WebGL? (Contrary to the impression, WebGL is also usable for 2D graphics.)

Comment 4

[vik.nuckchady]

Attachment: Test code to demonstrate the problem

Comment 5

[vik.nuckchady]

Attachment: Sample date to be used with test code in order to demonstrate the problem

Comment 6

[vik.nuckchady]

Attachment: Screenshot of the issue when running test code with sample_image.png and having antialiasing OFF

Comment 7

[vik.nuckchady]

Attachment: Screenshot of the issue when running test code with sample_image.png and having antialiasing ON

Comment 8

[vik.nuckchady]

Attachment: This is not the correct image i wanted to upload.

Comment 9

[vik.nuckchady]

Attachment: Screenshot of corresponding in actual image when inspecting with an image editor (Paint.NET)

Comment 10

[vik.nuckchady]

(In reply to Matthias Versen (Matti) from comment #1)
> Please attach a testcase.

Thanks Matti for your reply. I have attached to the report a test case (test code + data. Ref: attachment 694242 [details] and 694243). There are also additional attachment with screenshots demonstrating the problem in FF and the correct behavior in IE.

Comment 11

[vik.nuckchady]

(In reply to Robert Longson from comment #2)
> Have you turned off antialiasing? see mozImageSmoothingEnabled in
> https://developer.mozilla.org/en-US/docs/DOM/CanvasRenderingContext2D#Gecko-
> specific_attributes

Thanks Robert for the tip. I have tried setting on and off the antialiasing behavior but to no avail. Please find attached to the report screenshots demonstrating the problem. I have also attached sample code + data in case you want to have a deeper look.

Comment 12

[vik.nuckchady]

(In reply to Masatoshi Kimura [:emk] from comment #3)
> PNG uses a unpremultiplied alpha while canvas 2D uses a premultiplied one.
> It's inevitable that the exact RGB values are lost for pixels whose alpha
> values are not 255 as long as you use canvas 2D.
> WebGL has an unpremultiplied alpha mode. Is it reproducible with WebGL?
> (Contrary to the impression, WebGL is also usable for 2D graphics.)

Thanks for the explanation Masatoshi. However, my point is that the behavior of a neutral code which is suppose to be cross-browser compatible has different results on different. So, on IE10 it runs fine (i.e. is correct) while on Firefox it is incorrect. I am simply reporting the issue here as a problem in Firefox. I have attached to this case several screenshots to demonstrate this as well as test code and data for you to explore further in case you are interested. Sadly, I do not have a computer where i can run WebGL.

Comment 13

[vik.nuckchady]

Comment on attachment 694246 [details]
This is not the correct image i wanted to upload.

As i have no idea how to remove attachments, i am stating here that this is attachment should ignored for this bug.

Comment 14

[Masatoshi Kimura [:emk]]

(In reply to vik.nuckchady from comment #12)
> Thanks for the explanation Masatoshi. However, my point is that the behavior
> of a neutral code which is suppose to be cross-browser compatible has
> different results on different.

Different browsers may perform the different rounding when calculating the premultiplied alpha.

http://www.w3.org/TR/2dcontext/#dom-context-2d-putimagedata
> The handling of pixel rounding when the specified coordinates do not
> exactly map to the device coordinate space is not defined by this
> specification, except that the following must result in no visible
> changes to the rendering:
>
> context.putImageData(context.getImageData(x, y, w, h), p, q);

Note that it is NOT guaranteed that
  context.putImageData(imageData, p, q);
  imageData = context.getImageData(x, y, w, h);
will preserve the pixel values.

> Note: Due to the lossy nature of converting to and from premultiplied
> alpha color values, pixels that have just been set using putImageData()
> might be returned to an equivalent getImageData() as different values.

Comment 15

[vik.nuckchady]

(In reply to Masatoshi Kimura [:emk] from comment #14)
> (In reply to vik.nuckchady from comment #12)
> > Thanks for the explanation Masatoshi. However, my point is that the behavior
> > of a neutral code which is suppose to be cross-browser compatible has
> > different results on different.
> 
> Different browsers may perform the different rounding when calculating the
> premultiplied alpha.
> 
> http://www.w3.org/TR/2dcontext/#dom-context-2d-putimagedata
> > The handling of pixel rounding when the specified coordinates do not
> > exactly map to the device coordinate space is not defined by this
> > specification, except that the following must result in no visible
> > changes to the rendering:
> >
> > context.putImageData(context.getImageData(x, y, w, h), p, q);
> 
> Note that it is NOT guaranteed that
>   context.putImageData(imageData, p, q);
>   imageData = context.getImageData(x, y, w, h);
> will preserve the pixel values.
> 
> > Note: Due to the lossy nature of converting to and from premultiplied
> > alpha color values, pixels that have just been set using putImageData()
> > might be returned to an equivalent getImageData() as different values.

Thanks again Masatoshi for the prompt reply and the W3C link. Based on that, i think that there is no bug. So, this case can be closed.