PNG (by spec) stores RGBA data alpha-nonpremultiplied. Internally, we have two RGBA input formats for encoding: INPUT_FORMAT_RGBA (nonpremultiplied) and INPUT_FORMAT_HOSTARGB (premultiplied). PNG correctly unpremults data encoded from INPUT_FORMAT_HOSTARGB, while leaving _RGBA data alone. Prior to bug 650720, JPG did the same, as did BMP. Since, both JPG and BMP do not unpremult data coming from _HOSTARGB. It seems to me that the older behavior was correct for RGBA BMPs, though I haven't found mention of it in the spec. It also seems that it makes the most sense to premultiply while encoding from RGBA to RGB formats. Thus, JPGs and non-RGBA BMPs should be premultiplied when encoded from nonpremult sources, while PNGs and RGBA BMPs should be instead unpremult'd when encoded from premult sources.

Try run: https://tbpl.mozilla.org/?tree=Try&rev=d8b068eb33a2

Comment on attachment 583969 [details] [diff] [review] Respect alpha-premult when encoding HOSTARGB/RGBA formats Review of attachment 583969 [details] [diff] [review]: ----------------------------------------------------------------- ::: image/encoders/bmp/nsBMPEncoder.cpp @@ +433,5 @@ > + return (c*a + 127) / 255; > +} > + > +static int UnpremultByte(int c, int a) { > + return (c*255 + a/2) / a; We actually already have GFX_PREMULTIPLY (in gfxColor.h); you could add GFX_UNPREMULTIPLY if you wanted, and use those.

I'll add GFX_UNPREMULTIPLY for now, but ideally my premult/unpremult unification work will be ready soon. Also the try run here seems full of mochi-1 fails, so I'll look into that.

There are issues with touching the BMP encoder/decoder, as we actually don't currently support encoding RGBA BMPs.

This patch just fixes the JPG encoder/decoder, and passes canvas tests on my machine. Running try push at: https://tbpl.mozilla.org/?tree=Try&rev=334cf17cf17e

Try push for JPG is clean.

Splitting off JPG encode/decode to bug 723221.