Closed Bug 399668 Opened 12 years ago Closed 11 years ago

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

Categories

(Core :: Canvas: 2D, defect, P2)

x86
macOS
defect

Tracking

()

RESOLVED INVALID

People

(Reporter: Dolske, Unassigned)

References

Details

Attachments

(2 files)

Attached image 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.
Flags: blocking1.9?
Attached file Testcase
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".
Blocks: 386651
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?
is this the same as/dup of 389366?
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.
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.
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.
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)
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.
Flags: wanted1.9+
Flags: blocking1.9?
Flags: blocking1.9-
No longer blocks: 386651
Priority: -- → P2
Summary: Canvas's drawImage + getImageData is doubly premultiplying pixels → Canvas's drawImage + getImageData is doubly premultiplying pixels w/ color management
Blocks: 418538
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?
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.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.