Add support for WebP file format

[robert-matusewicz]

Here's a simple WebP reader/writer that uses Google libwebp library. For now the plugin is very naive: before decompressing an image it waits till all data will be read from file. The same with writing: before compressing an image it waits till receive all image data, then compress the image and write it to the file.

[dewyatt]

Nice! I figured webp support would be pretty easy. I guess I can scratch this off my list!

[robert-matusewicz]

When I noticed that one of Your tasks is too write WebP plugin it was to late to stop;)

I forgot to point to sample files: http://code.google.com/speed/webp/gallery.html

[lgritz]

Sorry, Daniel, I'm sure Robert didn't mean to step on your toes. On the other hand, I really think that a good implementation of PSD will keep you busy the whole summer, you shouldn't be worried about this.

[dewyatt]

Oh no, it's no problem and I agree with you. A thorough PSD plugin alone will definitely be challenging and likely take the whole summer.

[lgritz]

Robert, can you fill us in a little about WebP, just for our info? My cursory look at the code seems to indicate that webp is always 8 bit unsigned, and either RGB or RGBA? Is that right? How is it typically used, and what problem was it designed to solve if it seems to limited?

Also, what's up with the library? You seem to take it from the external project area, but is it common enough that it will typically be found in some standard location?

[dewyatt]

I know you asked Robert, but I might be able to answer some questions.
WebP uses VP8 which I believe means data is always stored as Y'UV (Y'CbCr).
Chapter 2 "Format Overview" of VP8 bitstream specs:
http://tools.ietf.org/id/draft-bankoski-vp8-bitstream.txt

However, libwebp provides decoding functions that convert to variants of RGB:
WebPDecodeRGB returns RGB image samples in [r0, g0, b0, r1, g1, b1, ...] order.
WebPDecodeRGBA returns RGBA image samples in [r0, g0, b0, a0, r1, g1, b1, a1, ...] order.
WebPDecodeBGR returns BGR image samples in [b0, g0, r0, b1, g1, r1, ...] order.
WebPDecodeBGRA returns BGRA image samples in [b0, g0, r0, a0, b1, g1, r1, a1, ...] order.

Or, you can get Y'UV directly:
uint8_t* WebPDecodeYUV(const uint8_t* data, uint32_t data_size,
int width, int *height, uint8_t* u, uint8_t** v,
int stride, int uv_stride);

The libwebp API docs are incomplete (http://code.google.com/speed/webp/docs/api.html) but the code seems to have plenty of comments.

For how it's meant to be used, the FAQ explains it pretty well (it's mainly meant for use on the Web):
http://code.google.com/speed/webp/faq.html

libwebp code repository info is here:
http://www.webmproject.org/code/#webp-repositories

[robert-matusewicz]

I think Daniel explanation is good enough. The whole decode magic is in webp library and we have the ability to choose if we want return data in RGB/RGBA/... formats.

As for the library question: I'm not sure what the problem is? Cmake search for webp library in external area or in area pointed by WEBP_HOME variable (which can point to standard install location?) - I just mimic the behavior for searching HDF5 and Field3d library. ff this is not correct way of doing this I would be thankfull for any advice of how to do this right;)

[lgritz]

OK, so from our point of view, WebP is inherently 8 bit and either RGB or RGBA?

Sounds good, then.

-- lg

On May 22, 2011, at 6:08 PM, dewyatt wrote:

I know you asked Robert, but I might be able to answer some questions.
WebP uses VP8 which I believe means data is always stored as Y'UV (Y'CbCr).
Chapter 2 "Format Overview" of VP8 bitstream specs:
http://tools.ietf.org/id/draft-bankoski-vp8-bitstream.txt

However, libwebp provides decoding functions that convert to variants of RGB:
WebPDecodeRGB returns RGB image samples in [r0, g0, b0, r1, g1, b1, ...] order.
WebPDecodeRGBA returns RGBA image samples in [r0, g0, b0, a0, r1, g1, b1, a1, ...] order.
WebPDecodeBGR returns BGR image samples in [b0, g0, r0, b1, g1, r1, ...] order.
WebPDecodeBGRA returns BGRA image samples in [b0, g0, r0, a0, b1, g1, r1, a1, ...] order.

Or, you can get Y'UV directly:
uint8_t* WebPDecodeYUV(const uint8_t* data, uint32_t data_size,
int width, int *height, uint8_t* u, uint8_t** v,
int stride, int uv_stride);

The libwebp API docs are incomplete (http://code.google.com/speed/webp/docs/api.html) but the code seems to have plenty of comments.

For how it's meant to be used, the FAQ explains it pretty well (it's mainly meant for use on the Web):
http://code.google.com/speed/webp/faq.html

libwebp code repository info is here:
http://www.webmproject.org/code/#webp-repositories

Reply to this email directly or view it on GitHub:
#82 (comment)

Larry Gritz
lg@larrygritz.com

[lgritz]

The code basically LGTM, but I have a few hints/requests:

1. I don't think you need webp_pvt.h at all -- just put the class defs in webpinput.cpp and webpoutput.cpp. We usually use format_pvt.h if there are some definitions that need to be shared between the reader and writer. If there are totally separate, no need for the third file.
2. I think the "buffer the whole file" approach is fine for now. If the format becomes a popular one that we lean on and would expect to be efficient to have lots of them open with the ImageCache, we can at that point try to do something more clever with incremental reads or writes (assuming those are supported by the underlying library). You may want to add a clear comment somewhere, however, indicating what the current limitations are that where the work would go if somebody in the future wanted to improve it in this area.
3. Test cases? Is there a validation suite that we should build a testsuite entry around, as we have for many of the other formats?
4. Tell me when you're ready for a merge, and I'll do it for you. Either you can, or right before merging, I will -- squash this all down to one commit.

[robert-matusewicz]

ok, after some fighting with rebasing the commits everything is ok now. Is the code good enough to merge it with the master?

[lgritz]

LGTM

[robert-matusewicz]

I'ts look like I don't have write access to OIIO master, so feel free to push this changes;)

[lgritz]

Merged.