Lossless webp and has_alpha

[msa...@google.com]

Hi Webp Discuss,

I had a question about how webp decoders should handles lossless webp.  Sorry if this is answered somewhere in the documentation!

It looks like lossless webp is encoded as BGRA (which indicates that it always has an alpha channel).  However, it also seems that the has_alpha feature is still set (or not set) by a flag in the header.  Does this mean that lossless webps are allowed to not have alpha?  In this case, should we ignore the alpha channel and treat the image as opaque?  Or should we always respect the alpha channel?

Thanks!

Matt

[Urvang Joshi]

Hi Matt,

On Thu, Mar 24, 2016 at 9:11 AM msarett via WebP Discussion <webp-d...@webmproject.org> wrote:

Hi Webp Discuss,

I had a question about how webp decoders should handles lossless webp.  Sorry if this is answered somewhere in the documentation!

It looks like lossless webp is encoded as BGRA (which indicates that it always has an alpha channel).  However, it also seems that the has_alpha feature is still set (or not set) by a flag in the header.  Does this mean that lossless webps are allowed to not have alpha?

From the spec:

"The alpha_is_used bit is a hint only, and should not impact decoding. It should be set to 0 when all alpha values are 255 in the picture, and 1 otherwise."

Even though lossless WebP is encoded as ARGB, it's possible that the alpha in the source image was trivial (that is, alpha channel in all pixels was 255). The lossless encoder should detect such a case automatically, and set alpha_is_used = 0 in that case.

 

 In this case, should we ignore the alpha channel and treat the image as opaque?  Or should we always respect the alpha channel?

alpha_is_used bit is a hint only, as noted in the spec. But yes, you can assume that -- alpha_is_used = 0 implies the image is opaque -- for the encoder in libwebp in particular.

 

Thanks!

Matt

--
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 https://groups.google.com/a/webmproject.org/group/webp-discuss/.
For more options, visit https://groups.google.com/a/webmproject.org/d/optout.

--

Thanks & Regards,

Urvang

[Jyrki Alakuijala]

https://developers.google.com/speed/webp/docs/webp_lossless_bitstream_specification#1_introduction

"""The alpha_is_used bit is a hint only, and should not impact decoding. It should be set to 0 when all alpha values are 255 in the picture, and 1 otherwise."""

--

[Matt Sarett]

Ping.  Any thoughts?

[James Zern]

On Friday, August 12, 2016 at 10:57:10 AM UTC-7, Matt Sarett wrote:

Ping.  Any thoughts?

There were some answers in this thread already [1]. Anything else we can help with?

[1] https://groups.google.com/a/webmproject.org/d/msg/webp-discuss/2rFPKOzxuSM/uabYhmSNJAAJ

[Leon Scroggins]

Hi,

I'm reviving this thread as we look to add animated webp to Skia's decoder (CL is here https://skia-review.googlesource.com/c/16707/). It seems that Chromium's WEBPImageDecoder does respect the alpha reported by libwebp, although I find it a little inconsistent. Sometimes it uses WebPIterator.has_alpha, and sometimes it checks whether ALPHA_FLAG is set in WebPDemuxGetI(demux_, WEBP_FF_FORMAT_FLAGS). The latter seems to report whether *any* frame has alpha. (The documentation does not specify that it is a hint, but I'm guessing that it is?) AFAICT Chromium truly wants to know whether a particular frame has alpha in each case. Why doesn't Chromium always use WebPIterator.has_alpha? (Or neither, if they're only hints?)

urvang@, it looks like this code dates back to the introduction of animated webp support in https://chromiumcodereview.appspot.com/13980003. Do you remember why you used one or the other?

(FWIW, I found a webp file checked into Chromium, which I've attached, whose WEBP_FF_FORMAT_FLAGS report that there is alpha, while all the individual frames' WebPIterators report that they are opaque. It seems the two values are encoded into the stream, so either one could be more trustworthy than the other.)

[James Zern]

On Monday, May 15, 2017 at 7:52:58 PM UTC+2, Leon Scroggins wrote:

Hi,

I'm reviving this thread as we look to add animated webp to Skia's decoder (CL is here https://skia-review.googlesource.com/c/16707/). It seems that Chromium's WEBPImageDecoder does respect the alpha reported by libwebp, although I find it a little inconsistent. Sometimes it uses WebPIterator.has_alpha, and sometimes it checks whether ALPHA_FLAG is set in WebPDemuxGetI(demux_, WEBP_FF_FORMAT_FLAGS). The latter seems to report whether *any* frame has alpha. (The documentation does not specify that it is a hint, but I'm guessing that it is?)

The flag at the file/vp8x level is indeed a hint (for that bit the docs say: Set if any of the frames of the image contain transparency information ("alpha").), as noted earlier in the thread. This is meant as guidance for the output format should the application want to vary the format based on its presence. Like any container it is possible that these could fall out of sync with the bitstreams, but those produced by libwebp should be correct.

 

AFAICT Chromium truly wants to know whether a particular frame has alpha in each case. Why doesn't Chromium always use WebPIterator.has_alpha? (Or neither, if they're only hints?)

The has_alpha iterator field is set if either we have an alpha chunk in the lossy case or by inspecting the bitstream (through WebPGetFeatures).

 

urvang@, it looks like this code dates back to the introduction of animated webp support in https://chromiumcodereview.appspot.com/13980003. Do you remember why you used one or the other?

(FWIW, I found a webp file checked into Chromium, which I've attached, whose WEBP_FF_FORMAT_FLAGS report that there is alpha, while all the individual frames' WebPIterators report that they are opaque. It seems the two values are encoded into the stream, so either one could be more trustworthy than the other.)

I don't remember the origin of this file, this may have been intentional for testing purposes; It's worth noting, however: 'Background color MAY contain a transparency value (alpha), even if the Alpha flag in VP8X chunk is unset.' [2].

[2] https://developers.google.com/speed/webp/docs/riff_container#animation