Alpha Channel (transparency) would be a key "selling point"

[Jari Pennanen]

Hi!

I know this is discussed here earlier, but in order to make the weppy
relevant it should standout from the pack. There is a rising need for
lossy images that would in addition support alpha transparency.

In fact I think it could be major "selling point" for this format.

Please consider this as an addition to format.

[MaxSt]

Indeed, web designers would love this "alpha-channel" plus "lossy
compression" combination.

[Pascal Massimino]

Hi,

since it would require a format change, that's something to carefully consider.

I'd have one question for the savvy alpha-plane users: 

would half-resolution be enough for the alpha-plane (like chroma plans)? 

Or shall it be kept at full resolution, like luma plane?

skal

 

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

[Urvang Joshi]

Hi Justin,

Experiemental support for alpha channel with lossy WebP images was announced in November last year:

http://googlecode.blogspot.in/2011/11/lossless-and-transparency-encoding-in.html

In fact, the alpha channel in WebP can either be at full resolution or could be quantized (e.g. for mobile devices) based on parameter 'alpha_quality'.

The alpha support is planned to be released with Libwebp v0.1.4 in a matter of weeks.

Thanks,

Urvang

On Fri, Jun 15, 2012 at 8:42 AM, <justin...@gmail.com> wrote:

YES, in fact even 1 bit per pixel (on / off) would be an amazing option as mobile displays are dense enough to work well with something like that.

On Thursday, January 13, 2011 6:53:02 PM UTC-5, skal wrote:

Hi,

On Wed, Jan 5, 2011 at 2:25 PM, Jari Pennanen <jari.p...@gmail.com> wrote:

Hi!

I know this is discussed here earlier, but in order to make the weppy
relevant it should standout from the pack. There is a rising need for
lossy images that would in addition support alpha transparency.

In fact I think it could be major "selling point" for this format.

Please consider this as an addition to format.

since it would require a format change, that's something to carefully consider.

I'd have one question for the savvy alpha-plane users: 

would half-resolution be enough for the alpha-plane (like chroma plans)? 

Or shall it be kept at full resolution, like luma plane?

skal

 

--
You received this message because you are subscribed to the Google Groups "WebP Discussion" group.
To post to this group, send email to webp-d...@webmproject.org.

To unsubscribe from this group, send email to webp-discuss+unsubscribe@webmproject.org.

For more options, visit this group at http://groups.google.com/a/webmproject.org/group/webp-discuss/?hl=en.

--
You received this message because you are subscribed to the Google Groups "WebP Discussion" group.

To view this discussion on the web visit https://groups.google.com/a/webmproject.org/d/msg/webp-discuss/-/SyXkyINekngJ.

[Urvang Joshi]

Hi,

On Wed, Jun 20, 2012 at 4:00 PM, <justin...@gmail.com> wrote:

Awesome, I'm glad I decided to start using libvpx :) Is alpha support available through a beta or anything right now?

As of now, you can compile the binaries from the latest source, available at: http://git.chromium.org/gitweb/?p=webm/libwebp.git

To get the source:

git clone http://git.chromium.org/webm/libwebp.git

Compilation:

cd libwebp
./autogen.sh
./configure
make  

This will create cwebp & dwebp binaries under directory examples/.

Thanks,

Urvang

 

To view this discussion on the web visit https://groups.google.com/a/webmproject.org/d/msg/webp-discuss/-/p5-VVLqEw6EJ.

[toby]

On Friday, 15 June 2012 04:59:34 UTC-4, Urvang Joshi wrote:

Hi Justin,

Experiemental support for alpha channel with lossy WebP images was announced in November last year:

http://googlecode.blogspot.in/2011/11/lossless-and-transparency-encoding-in.html

In fact, the alpha channel in WebP can either be at full resolution or could be quantized (e.g. for mobile devices) based on parameter 'alpha_quality'.

The alpha support is planned to be released with Libwebp v0.1.4 in a matter of weeks.

I found the container document unclear on the expected position of the ALPH chunk among the extended chunk. Am I missing something?

Also, the diagrams of chunks with flag bits are confusing and doesn't seem to match the implementation in libwebp code (in particular, VP8X flags). Can the diagram be clarified in all cases where flag bits are shown? Perhaps by treating flag words *not* as multi-byte words (where endianness matters), but as non-endian byte sequences (i.e. depict bytes or FOURCC signatures in file order, first to last = left to right, and always show bits in a single byte in most-to-least significance (L to R) order. This would be unambiguous and conventional.

Only multi-byte integers would have endianness (always LE, in this container) and would be shown to span bytes, as the diagrams do now.

--Toby
 

Thanks,

Urvang

On Fri, Jun 15, 2012 at 8:42 AM, <justin...@gmail.com> wrote:

YES, in fact even 1 bit per pixel (on / off) would be an amazing option as mobile displays are dense enough to work well with something like that.

On Thursday, January 13, 2011 6:53:02 PM UTC-5, skal wrote:

Hi,

On Wed, Jan 5, 2011 at 2:25 PM, Jari Pennanen <jari.p...@gmail.com> wrote:

Hi!

I know this is discussed here earlier, but in order to make the weppy
relevant it should standout from the pack. There is a rising need for
lossy images that would in addition support alpha transparency.

In fact I think it could be major "selling point" for this format.

Please consider this as an addition to format.

since it would require a format change, that's something to carefully consider.

I'd have one question for the savvy alpha-plane users: 

would half-resolution be enough for the alpha-plane (like chroma plans)? 

Or shall it be kept at full resolution, like luma plane?

skal

 

--
You received this message because you are subscribed to the Google Groups "WebP Discussion" group.
To post to this group, send email to webp-d...@webmproject.org.

To unsubscribe from this group, send email to webp-discuss...@webmproject.org.
For more options, visit this group at http://groups.google.com/a/webmproject.org/group/webp-discuss/?hl=en.

[toby]

On Thursday, 13 January 2011 18:53:02 UTC-5, skal wrote:

Hi,

On Wed, Jan 5, 2011 at 2:25 PM, Jari Pennanen <jari.p...@gmail.com> wrote:

Hi!

I know this is discussed here earlier, but in order to make the weppy
relevant it should standout from the pack. There is a rising need for
lossy images that would in addition support alpha transparency.

In fact I think it could be major "selling point" for this format.

Please consider this as an addition to format.

since it would require a format change, that's something to carefully consider.

I'd have one question for the savvy alpha-plane users: 

would half-resolution be enough for the alpha-plane (like chroma plans)? 

Or shall it be kept at full resolution, like luma plane?

I think optional downsampling like chroma is quite interesting. Especially since a high quality upsample can be applied when reading. The difference would be negligible on any image with an alpha that is not entirely hard edges or fine textures.

I reviewed the enc/alpha.c code and its clever use of the quality parameter. I think in the end you didn't implement any downsampling? Could it be added in future?

--Toby

 

[James Zern]

On Thursday, June 27, 2013 9:01:09 PM UTC-7, toby wrote:

[...]

Also, the diagrams of chunks with flag bits are confusing and doesn't seem to match the implementation in libwebp code (in particular, VP8X flags). Can the diagram be clarified in all cases where flag bits are shown?

Yes this can be clarified. The order for the flags is correct and presented in MSB order, typical in e.g., RFC documentation -- there's a reference for that, but there's nothing in the document currently describing this convention on a quick glance.

 

Perhaps by treating flag words *not* as multi-byte words (where endianness matters), but as non-endian byte sequences (i.e. depict bytes or FOURCC signatures in file order, first to last = left to right, and always show bits in a single byte in most-to-least significance (L to R) order. This would be unambiguous and conventional.

FourCC's are presented in file order as in the header [1], ChunkHeader() uses the same ordering.

[1] https://developers.google.com/speed/webp/docs/riff_container#webp-file-header

[toby]

On Friday, 28 June 2013 19:56:38 UTC-4, James Zern wrote:

On Thursday, June 27, 2013 9:01:09 PM UTC-7, toby wrote:

[...]

Also, the diagrams of chunks with flag bits are confusing and doesn't seem to match the implementation in libwebp code (in particular, VP8X flags). Can the diagram be clarified in all cases where flag bits are shown?

Yes this can be clarified. The order for the flags is correct and presented in MSB order, typical in e.g., RFC documentation -- there's a reference for that, but there's nothing in the document currently describing this convention on a quick glance.

I don't find the term "MSB order" self explanatory in itself. "MSB to LSB, left to right" would be clearer. I guess my biggest quibble is labelling the MOST significant bit "bit 0"? (Yes, I know RFCs are similar, and they are similarly ambiguous as a result; I had a look at the TCP RFC for example.)

Thought experiment: If this were a *BigEndian* format, how would you lay this out differently?

 

 

Perhaps by treating flag words *not* as multi-byte words (where endianness matters), but as non-endian byte sequences (i.e. depict bytes or FOURCC signatures in file order, first to last = left to right, and always show bits in a single byte in most-to-least significance (L to R) order. This would be unambiguous and conventional.

FourCC's are presented in file order as in the header [1], ChunkHeader() uses the same ordering.

--Toby
 

[1] https://developers.google.com/speed/webp/docs/riff_container#webp-file-header

[James Zern]

On Friday, June 28, 2013 8:36:51 PM UTC-7, toby wrote:

On Friday, 28 June 2013 19:56:38 UTC-4, James Zern wrote:

On Thursday, June 27, 2013 9:01:09 PM UTC-7, toby wrote:

[...]

Also, the diagrams of chunks with flag bits are confusing and doesn't seem to match the implementation in libwebp code (in particular, VP8X flags). Can the diagram be clarified in all cases where flag bits are shown?

Yes this can be clarified. The order for the flags is correct and presented in MSB order, typical in e.g., RFC documentation -- there's a reference for that, but there's nothing in the document currently describing this convention on a quick glance.

I don't find the term "MSB order" self explanatory in itself. "MSB to LSB, left to right" would be clearer. I guess my biggest quibble is labelling the MOST significant bit "bit 0"? (Yes, I know RFCs are similar, and they are similarly ambiguous as a result; I had a look at the TCP RFC for example.)

I think RFC 1700 has something like the above:

Whenever an octet represents a numeric quantity the left most bit in the

diagram is the high order or most significant bit.  That is, the bit

labeled 0 is the most significant bit.