Add support for WebP file format #82

Closed
wants to merge 1 commit into
from

Projects

None yet

3 participants

@matekm
Contributor
matekm commented May 22, 2011

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
Contributor
dewyatt commented May 22, 2011

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

@matekm
Contributor
matekm commented May 22, 2011

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
Contributor
lgritz commented May 22, 2011

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
Contributor
dewyatt commented May 22, 2011

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
Contributor
lgritz commented May 23, 2011

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
Contributor
dewyatt commented May 23, 2011

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

@matekm
Contributor
matekm commented May 23, 2011

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
Contributor
lgritz commented May 28, 2011

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
Contributor
lgritz commented May 28, 2011

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.
@matekm matekm Added support for webp format. For now plugin reads the whole content…
… of the file before decoding. The same with encoding
1eac541
@matekm
Contributor
matekm commented Jun 12, 2011

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

@lgritz
Contributor
lgritz commented Jun 13, 2011

LGTM

@matekm
Contributor
matekm commented Jun 13, 2011

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

@lgritz
Contributor
lgritz commented Jun 13, 2011

Merged.

@lgritz lgritz closed this Jun 13, 2011
@dichen001 dichen001 referenced this pull request in dichen001/Paper-Reading Jun 28, 2016
Open

Summary of the 20 issues in Herbsleb's 2014 FSE paper. #6

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment