399668 - Canvas's drawImage + getImageData is doubly premultiplying pixels w/ color management

Status: RESOLVED INVALID

(Core :: Graphics: Canvas2D, defect, P2)

Description

[Justin Dolske [:Dolske]]

Attachment: Testcase image

The attached PNG is a flat field of r=g=b=50 pixels, with a=179. [aka, rgb=20%, alpha=70%]

The pixel data returned from canvas's getImageData() should be 50/50/50/179... Due to bug 389366, we seem to be emitting pre-multipled alpha pixels, which in this case should be 37/37/37/179.

On current OS X trunk, I'm getting 26/26/26/179. Note that 37 * 0.7 = 26.

Comment 1

[Justin Dolske [:Dolske]]

Attachment: Testcase

Comment 2

[Justin Dolske [:Dolske]]

You need to save the testcase and testcase image locally (as test-my30.png).

I tried including the image as a data: URI, but that throws a security error. Nice. *grumble*

On OS X, I get an alert reading "pixel = 26 / 26 / 26 / 179".

Comment 3

[Justin Dolske [:Dolske]]

On Vista I get 35 / 35 / 35 / 179... closer, but not the expected 37/37/37. That might be rounding errors somewhere; probably another bug for that?

Comment 4

[Stuart Parmenter]

is this the same as/dup of 389366?

Comment 5

[Justin Dolske [:Dolske]]

no, they're different problems (but might well have the same root fix?).

Bug 389366 is about the pixel format getImageData() should return. Legitimate format, but not what the spec required.

This bug is about incorrect results when an image is drawn on to a canvas, and the result is read out with getImageData(). Even if the spec said getImageData() should use premultiplied alpha, this would still be a bug.

Comment 6

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Do you have color management turned on?  If so, you won't get the exact image out.

Also, the default canvas operator is OVER -- though that shouldn't matter for this testcase, but the problem is probably the same as bug 389366.

Comment 7

[Justin Dolske [:Dolske]]

Ah, yes, color management seems to be important here...

With gfx.color_management.enabled set to true (as I've been using), OS X gives me "pixel = 26 / 26 / 26 / 179" as in comment #2. With it disabled, I get "pixel = 35 / 35 / 35 / 179". I'm fairly sure the pref was disabled when I tested on Windows as well.

Comment 8

[Justin Dolske [:Dolske]]

Small update: with the patch from bug 389366 applied, I get:

w/ colormgt: 37/37/37/179
no colormgt: 49/49/49/179 (expected result)

Comment 9

[Stuart Parmenter]

given that i don't think we're going to enable color correction for release by default, probably don't want to block on this but I'm open to push back.

Comment 10

[Bobby Holley (:bholley)]

Dolske - Color management transforms the pixel values, so you wouldn't expect to get exact pixel values back out. Do you have any reason to believe that the transformation is faulty?

Comment 11

[Justin Dolske [:Dolske]]

Hmm, that seems to be the case.

I ran this again, using a 50% gray image with *no* transparency, and checked pixels values in a screenshot. Without colormgt, I get 127/127/127. With colormgt, I get 108/108/108. And that also matches what Safari shows.

I guess I'm surprised that gray pixels were changed so much, and it was unfortunate coincidence the percent change was similar to the percent alpha in the original test case.