Add RGBX BGRX support to WEBPImportPicture

When importing BGRA or RGBA data for encoding, provide variants of
the WEBPImportPicture API for RGBX and BRGX data meaning the alpha
channel should be ignored.

Note: the existing WEBPImportPictureRGBA|BGRA routines also ignore
the alpha channel, but won't in a future version of libwebp. Thus,
if WebKit continues using the existing routines, the alpha channel
will be imported and encoded in libwebp.next, and hence will break
canvas.toDataURL("image/webp") and its layout tests.

BUG=130144
TEST=Webkit test pass when using the new functions.


Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=140264

[skal, 2012-06-04 04:34:55]

https://chromiumcodereview.appspot.com/10496016/diff/1/third_party/libwebp/en...
File third_party/libwebp/enc/picture.c (right):

https://chromiumcodereview.appspot.com/10496016/diff/1/third_party/libwebp/en...
third_party/libwebp/enc/picture.c:598: // In libwebp.next, assert
picture->user_argb_input here.
not necessarily. What if you want to convert to YUV?

I'd just remove this comment

https://chromiumcodereview.appspot.com/10496016/diff/1/third_party/libwebp/en...
third_party/libwebp/enc/picture.c:606: // In libwebp.next, assert
picture->user_argb_input here.
here too

https://chromiumcodereview.appspot.com/10496016/diff/1/third_party/libwebp/we...
File third_party/libwebp/webp/encode.h (right):

https://chromiumcodereview.appspot.com/10496016/diff/1/third_party/libwebp/we...
third_party/libwebp/webp/encode.h:255: // Same again, RGBA buffer, ignoring the
alpha channel
you can add a comment about why this is useful compared to
WebPPictureImportRGBA. Something like:
"useful when input is totally opaque, but one want to retain the 32-bit packed
layout and avoid converting to 24-bit RGB".

[Noel Gordon, 2012-06-04 05:17:37]

On 2012/06/04 04:34:55, skal wrote:
>
https://chromiumcodereview.appspot.com/10496016/diff/1/third_party/libwebp/en...
> File third_party/libwebp/enc/picture.c (right):
> 
>
https://chromiumcodereview.appspot.com/10496016/diff/1/third_party/libwebp/en...
> third_party/libwebp/enc/picture.c:598: // In libwebp.next, assert
> picture->user_argb_input here.
> not necessarily. What if you want to convert to YUV?

The current functions WEBPImportPictureRGBA, WEBPImportPictureBGRA convert to
YUV on import.  In the next
libwebp, the picture->use_argb_input forces the import code into that YUV
conversion branch, which is what I
want.  The assert would just check for that.  I have a webkit test for this, so

> I'd just remove this comment

ok, I'll remove it, and let the webkit test keep libwebp honest.
 
>
https://chromiumcodereview.appspot.com/10496016/diff/1/third_party/libwebp/en...
> third_party/libwebp/enc/picture.c:606: // In libwebp.next, assert
> picture->user_argb_input here.
> here too

Same again.
 
>
https://chromiumcodereview.appspot.com/10496016/diff/1/third_party/libwebp/we...
> File third_party/libwebp/webp/encode.h (right):
> 
>
https://chromiumcodereview.appspot.com/10496016/diff/1/third_party/libwebp/we...
> third_party/libwebp/webp/encode.h:255: // Same again, RGBA buffer, ignoring
the
> alpha channel
> you can add a comment about why this is useful compared to
> WebPPictureImportRGBA. Something like:
> "useful when input is totally opaque, but one want to retain the 32-bit packed
> layout and avoid converting to 24-bit RGB".

Opaque or not is irrelevant.  Someone about the data being in 32-bit format, and
encoding the RGB only without
needing an intermediate conversions into a 24-bit RGB temporary buffer, yada,
yada, something like that ...

[skal, 2012-06-04 06:33:15]

lgtm

LGTM

[Hironori Bono, 2012-06-04 06:45:30]

LGTM2.

Regards,

Hironori Bono

[commit-bot: I haz the power, 2012-06-04 06:45:51]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/noel@chromium.org/10496016/7001

[commit-bot: I haz the power, 2012-06-04 08:09:23]

Change committed as 140264