WebP support added to OpenCV

[prasannatsmkumar]

Hi all,

I am very happy to inform that WebP support is added to OpenCV image
processing library. Now WebP images can be read / written and
processed using OpenCV library.

Please see links
1. https://github.com/Itseez/opencv/tree/master/modules/highgui/src
2. https://github.com/Itseez/opencv/pull/610
3. https://github.com/Itseez/opencv/pull/539
4. https://github.com/Itseez/opencv/pull/463

Glad I have made a small contribution from my part to WebP project.

Thanks and Regards,
PrasannaKumar Muralidharan

[Vikas Arora]

Hi Prasanna -

Thats Great !

Thanks for adding WebP support to OpenCV.

Thanks & Regards,

Vikas 

--
You received this message because you are subscribed to the Google Groups "WebP Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to webp-discuss...@webmproject.org.
To post to this group, send email to webp-d...@webmproject.org.
Visit this group at http://groups.google.com/a/webmproject.org/group/webp-discuss/?hl=en.
For more options, visit https://groups.google.com/a/webmproject.org/groups/opt_out.

[Pascal Massimino]

Hi PrasannaKumar,

On Sat, Mar 16, 2013 at 2:47 AM, prasannatsmkumar <prasanna...@gmail.com> wrote:

Hi all,

I am very happy to inform that WebP support is added to OpenCV image
processing library. Now WebP images can be read / written and
processed using OpenCV library.

thanks for doing this, that's great!

 

Please see links
1. https://github.com/Itseez/opencv/tree/master/modules/highgui/src

i noticed that, in WebPDecoder::WebPDecoder(), you're hard-coding a signature
that is only correct for lossy format. It doesn't include the lossless one.

You should use WebPGetInfo(), which will do this parsing for you.
Or even better: WebPGetFeatures() from latest version.

 

2. https://github.com/Itseez/opencv/pull/610
3. https://github.com/Itseez/opencv/pull/539
4. https://github.com/Itseez/opencv/pull/463

 

Glad I have made a small contribution from my part to WebP project.

Thanks and Regards,
PrasannaKumar Muralidharan

[James Zern]

Hi,

On Saturday, March 16, 2013 2:47:31 AM UTC-7, Prasanna Kumar wrote:

Hi all,

I am very happy to inform that WebP support is added to OpenCV image
processing library. Now WebP images can be read / written and
processed using OpenCV library.

Great!

 

Please see links
1. https://github.com/Itseez/opencv/tree/master/modules/highgui/src
2. https://github.com/Itseez/opencv/pull/610
3. https://github.com/Itseez/opencv/pull/539
4. https://github.com/Itseez/opencv/pull/463

I see you're decoding to bgr. Note that the format supports alpha so you could alternatively use WebPGetFeatures() to detect that case.

[prasannatsmkumar]

> i noticed that, in WebPDecoder::WebPDecoder(), you're hard-coding a
> signature
> that is only correct for lossy format. It doesn't include the lossless one.
> You should use WebPGetInfo(), which will do this parsing for you.
> Or even better: WebPGetFeatures() from latest version.

Yes I overlooked the loss less header, thanks for the info. I will
make necessary changes. WebPDecoder::checkSignature() function can be
called for any image (which may not be webp image) so using
WebPGetInfo did not look good here as it needs the full image file
contents. Reading full file contents to determine whether a given file
is a webp image or not looks like wastage of resources.

Note:
Inside WebPDecoder::readHeader() WebPGetInfo() is used to get the
height, width of the image, if it fails the image will not be decoded
further.

Thanks and Regards,
PrasannaKumar

[prasannatsmkumar]

> I see you're decoding to bgr. Note that the format supports alpha so you
> could alternatively use WebPGetFeatures() to detect that case.

OpenCV needs the images to be decoded in BGR format only. OpenCV is
used to process the data (it is an image processing library - things
like recognising objects / filtering / applying transforms etc can be
done) so it does not care about the alpha content. OpenCV works on the
image provided and not the alpha blended one (basically there is
nothing to blend this image with). The alpha content in the webp image
is discarded intentionally. Please feel free to get back if more info
is needed.

Hope this helps,
PrasannaKumar

[Pascal Massimino]

Hi PrasannaKumar,

On Mon, Mar 18, 2013 at 11:04 PM, prasannatsmkumar <prasanna...@gmail.com> wrote:

> i noticed that, in WebPDecoder::WebPDecoder(), you're hard-coding a
> signature
> that is only correct for lossy format. It doesn't include the lossless one.
> You should use WebPGetInfo(), which will do this parsing for you.
> Or even better: WebPGetFeatures() from latest version.

Yes I overlooked the loss less header, thanks for the info. I will
make necessary changes. WebPDecoder::checkSignature() function can be
called for any image (which may not be webp image) so using
WebPGetInfo did not look good here as it needs the full image file
contents. Reading full file contents to determine whether a given file
is a webp image or not looks like wastage of resources.

actually, neither WebPGetInfo() nor WebPGetFeatures() need the full

data to be available to verify the bitstream (and even get the width/height

information). They only need the headers (roughly: ~60bytes, depending

on the content) and can reasonably operate with truncated input. 

WebPGetFeatures() returns a finer diagnostic about input: 

  * VP8_STATUS_OK if the header-parsing was OK

  * VP8_STATUS_NOT_ENOUGH_DATA if the header is not complete and

    more bytes are needed

  * any other error status if there's a real format error (like: invalid signature,

    damaged data, etc.) in the header.

(In fact, you even have a fully incremental decoding mode where input bytes

can be processed as they arrive and attempted decoding. See WebPINewDecoder

as a starting point).

Note:
Inside WebPDecoder::readHeader() WebPGetInfo() is used to get the
height, width of the image, if it fails the image will not be decoded
further.

Thanks and Regards,
PrasannaKumar

[prasannatsmkumar]

On 19 March 2013 12:14, Pascal Massimino <pascal.m...@gmail.com> wrote:
> actually, neither WebPGetInfo() nor WebPGetFeatures() need the full
> data to be available to verify the bitstream (and even get the width/height
> information). They only need the headers (roughly: ~60bytes, depending
> on the content) and can reasonably operate with truncated input.
> WebPGetFeatures() returns a finer diagnostic about input:
> * VP8_STATUS_OK if the header-parsing was OK
> * VP8_STATUS_NOT_ENOUGH_DATA if the header is not complete and
> more bytes are needed
> * any other error status if there's a real format error (like: invalid
> signature,
> damaged data, etc.) in the header.

This can be used if the header's length necessary for WebPGetInfo() is
known. Using this API will make sure that future versions of the webp
format with different signature will also be taken care of properly.
Is that documented some where? Just asking this just to make sure
future changes to WebPGetInfo() function will not break this code.

Note:
1. If the current documented header ("VP8 " / "VP8L" / "VP8X") will
not change in future then WebPDecoder::checkSignature() need not use
WebPGetInfo() function. As WebPDecoder::checkSignature()'s purpose is
just to check for the signature and determine the type of the image
and not to do anything else.
2. WebPDecoder::readHeader() reads the file contents fully to get the
height and width of the image. Reading full file content seems not
necessary. The information on size of the header needed for
WebPGetInfo() will be useful there also.

>
> (In fact, you even have a fully incremental decoding mode where input bytes
> can be processed as they arrive and attempted decoding. See WebPINewDecoder
> as a starting point).
>

Guess progressive decoding cannot be done in this case because OpenCV
reads the file contents (finds the length of the signature and reads
only that many bytes) and provides that data for signature comparison.

Thanks and Regards,
PrasannaKumar

[Pascal Massimino]

PrasannaKumar,

On Tue, Mar 19, 2013 at 1:23 AM, prasannatsmkumar <prasanna...@gmail.com> wrote:

On 19 March 2013 12:14, Pascal Massimino <pascal.m...@gmail.com> wrote:
> actually, neither WebPGetInfo() nor WebPGetFeatures() need the full
> data to be available to verify the bitstream (and even get the width/height
> information). They only need the headers (roughly: ~60bytes, depending
> on the content) and can reasonably operate with truncated input.
> WebPGetFeatures() returns a finer diagnostic about input:
>   * VP8_STATUS_OK if the header-parsing was OK
>   * VP8_STATUS_NOT_ENOUGH_DATA if the header is not complete and
>     more bytes are needed
>   * any other error status if there's a real format error (like: invalid
> signature,
>     damaged data, etc.) in the header.

This can be used if the header's length necessary for WebPGetInfo() is
known. Using this API will make sure that future versions of the webp
format with different signature will also be taken care of properly.
Is that documented some where? Just asking this just to make sure
future changes to WebPGetInfo() function will not break this code.

the format won't change, they are details summarized in src/dec/webp.c

(beside the official doc https://developers.google.com/speed/webp/docs/riff_container):

// RIFF layout is:

//   Offset  tag

//   0...3   "RIFF" 4-byte tag

//   4...7   size of image data (including metadata) starting at offset 8

//   8...11  "WEBP"   our form-type signature

// The RIFF container (12 bytes) is followed by appropriate chunks:

//   12..15  "VP8 ": 4-bytes tags, signaling the use of VP8 video format

//   16..19  size of the raw VP8 image data, starting at offset 20

//   20....  the VP8 bytes

// Or,

//   12..15  "VP8L": 4-bytes tags, signaling the use of VP8L lossless format

//   16..19  size of the raw VP8L image data, starting at offset 20

//   20....  the VP8L bytes

// Or,

//   12..15  "VP8X": 4-bytes tags, describing the extended-VP8 chunk.

//   16..19  size of the VP8X chunk starting at offset 20.

//   20..23  VP8X flags bit-map corresponding to the chunk-types present.

//   24..26  Width of the Canvas Image.

//   27..29  Height of the Canvas Image.

// There can be extra chunks after the "VP8X" chunk (ICCP, FRGM, ANMF, VP8,

// VP8L, XMP, EXIF  ...)

// All sizes are in little-endian order.

// Note: chunk data size must be padded to multiple of 2 when written.

 

So, for short, you need 30 bytes of data at max.

Note:
1. If the current documented header ("VP8 " / "VP8L" / "VP8X") will
not change in future then WebPDecoder::checkSignature() need not use
WebPGetInfo() function. As WebPDecoder::checkSignature()'s purpose is
just to check for the signature and determine the type of the image
and not to do anything else.

that's pretty much what WebPGetFeatures() is doing, just with extra few

checks (like: are the chunk sizes looking valid? are the bits / values within reasonable

range etc?)

 There's no extra processing or decoding done, beside these checks. So i'd

encourage using these functions instead of just string-matching validation.

It won't use more CPU, and is robust to all header variants...

[prasannatsmkumar]

Good.

>>
>> Note:
>> 1. If the current documented header ("VP8 " / "VP8L" / "VP8X") will
>> not change in future then WebPDecoder::checkSignature() need not use
>> WebPGetInfo() function. As WebPDecoder::checkSignature()'s purpose is
>> just to check for the signature and determine the type of the image
>> and not to do anything else.
>
>
> that's pretty much what WebPGetFeatures() is doing, just with extra few
> checks (like: are the chunk sizes looking valid? are the bits / values
> within reasonable
> range etc?)
> There's no extra processing or decoding done, beside these checks. So i'd
> encourage using these functions instead of just string-matching validation.
> It won't use more CPU, and is robust to all header variants...
>

Great. I will try to make necessary changes soon.

And thanks for your prompt and detailed response :).

Thanks,
PrasannaKumar

[James Zern]

I see. Though it looked like PNG was decoding to BGRA, is that discarded later?

[prasannatsmkumar]

On 21 March 2013 06:46, James Zern <jz...@google.com> wrote:
>
> I see. Though it looked like PNG was decoding to BGRA, is that discarded
> later?
>

Not sure. Need to ask OpenCV community. If alpha channel is supported
I will make the necessary changes to the webp code.

It seems that the reading alpha from PNG was added recently. Some
older forum links / blogs like
(http://comments.gmane.org/gmane.comp.lib.opencv/51470) say alpha is
not supported. Based on the discussion it looks like reading PNG files
with alpha channel was not supported previously but it is available
now.

Still I am sure how useful the alpha will be from an image processing
perspective (other than just loading the alpha channel is discarding
it).

Thanks and Regards,
PrasannaKumar

[PrasannaKumar Muralidharan]

Sending first 30 bytes of the file to WebPGetFeatures returns an error (error code 3). When I send first 32 bytes of webp file WebPGetFeatures API succeeds. So I am using it that way as of now. Please let me know if I have missed something which needs to be changed.

Sorry for the late reply, got held up with my course work and was not able to try out the suggested changes.

Thanks and Regards,

Prasanna Kumar

[Jason Beach]

I know is this kind of an old thread, but I'm curious...is it possible to use OpenCV and the work you've done here to create an animated webp image?

Thanks,
Jason

[James Zern]

Hi,

On Wed, Dec 20, 2023 at 9:15 AM Jason Beach <jason....@gmail.com> wrote:

I know is this kind of an old thread, but I'm curious...is it possible to use OpenCV and the work you've done here to create an animated webp image?

Looking quickly, I see a request for animated webp input [1], but no mention of output for webp (or gif). Other options would be tools like those provided by libwebp, ImageMagick, ffmpeg or various image libraries depending on the language (imageio in python for example).

[1]: https://github.com/opencv/opencv/issues/22569

 

--

You received this message because you are subscribed to the Google Groups "WebP Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to webp-discuss...@webmproject.org.

To view this discussion on the web visit https://groups.google.com/a/webmproject.org/d/msgid/webp-discuss/7c385730-52a9-401b-a1ca-5a7e215a0dc8n%40webmproject.org.