Re: Progressive Webp

[prasannatsmkumar]

Webp supports progressive decoding. It is documented in
https://developers.google.com/speed/webp/docs/api see advanced
decoding API section for more details.

Regards,
PrasannaKumar

On 20 March 2013 04:18, <ufuka...@gmail.com> wrote:
> Hello,
>
> We're using webp images on memecenter.com for chrome, and progressive jpeg
> on other browsers. Even though we achieved a much greater bandwidth usage,
> end user experience is a bit questionable.
> Progressive jpegs' perceived load time seems a lot better than webp. Is webp
> capable of doing progressive decoding? If not, is it even possible with
> webp's algorithm?
>
> Ufuk
>
> --
> 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.
>
>

[Ufuk Altinok]

Ah that's great, does chrome support it?

[Vikas Arora]

Ufuk -

What WebP supports is incremental decoding in constraint memory environment like Android.

Instead of requiring full encoded image in buffer, incremental WebP decoding, decodes the image with incremental (sliding) input buffer and outputs the rows that have been decoded so far. Both Chrome & Android supports incremental decoding.

WebP currently doesn't support 'progressive' decoding (like Progressive jpegs). We do have plan to support progressive WebP using the RIFF container and using the LAYER chunks. However, details of these are not finalized yet.

Thanks,

Vikas

[Ufuk Altinok]

That's great. I have two more questions if you don't mind:

1- As far as I understood we'll need to re-encode existing WebP images when this feature is implemented. Will there be a faster option to re-encode existing WebPs to "progressive WebP" ?

2- As this seems a breaking change, will this cause additional split in image format as we'll have to keep both version for older browsers and newer ones ?

[Urvang Joshi]

Hi Ufuk,

On Fri, Mar 22, 2013 at 1:20 AM, Ufuk Altinok <ufuka...@gmail.com> wrote:

That's great. I have two more questions if you don't mind:

1- As far as I understood we'll need to re-encode existing WebP images when this feature is implemented. Will there be a faster option to re-encode existing WebPs to "progressive WebP" ?

2- As this seems a breaking change, will this cause additional split in image format as we'll have to keep both version for older browsers and newer ones ?

Indeed, backward compatibility is one of the important design goals for progressive WebP. Specifically, it would be desirable if at least the first layer of a progressive WebP file can be decoded even by older decoders. 

For example, one design could be such that an image with consist of one VP8(L) chunk, and enhancement layer(s). In fact, In the latest WebP container specification, we have kept a provision of 'Unknown chunks' for such extensibility.

Meanwhile, as Vikas mentioned, 'progressive' feature is in early design phase right now. So, any design suggestions are welcome!

[Pascal Massimino]

Hi,

On Mar 22, 2013 9:20 AM, "Ufuk Altinok" <ufuka...@gmail.com> wrote:
>
> That's great. I have two more questions if you don't mind:
>
> 1- As far as I understood we'll need to re-encode existing WebP images when this feature is implemented. Will there be a faster option to re-encode existing WebPs to "progressive WebP" ?

Be aware that there's two concepts with similar naming here:

. incremental decoding: this is just a decoder-side 'trick'. We try to show pixels as soon as possible. This doesn't require a format change.

. progressive decoding: this is the multi-layer mechanism that allow progressive refinement of the image. This needs a format iteration and new specification using the reserved chunks...

[Sébastien Ménard]

I know this thread is old but I'm interested in "progressive WebP" (in comparison to progressive JPEG). What is the status of the implementation?

[Pascal Massimino]

Hi,

On Fri, Dec 13, 2013 at 8:06 PM, Sébastien Ménard <capitai...@gmail.com> wrote:

I know this thread is old but I'm interested in "progressive WebP" (in comparison to progressive JPEG). What is the status of the implementation?

For lossy format, the main problem is about keeping the format (VP8) unchanged and offering layers on top of it without breaking compatibility.

I've tried several approaches for layering (by splitting the input image differently), but the cost is typically 10-15% extra bytes

for same distortion compared to non-layered. I haven't looked at the alpha plane yet, which is a separate problem.

For lossless, layering is a moot point considering the typical file sizes at play. One might be better off sending a small thumbnail (in lossy)

up-front before the lossless chunks.

Still investigating...

[oX Triangle]

does handle vp8 (webm) no scaling (global moving) outside the i or b-frames?

[kty...@gmail.com]

Hi,

Is there any update on this?

Progressive rendering of images can be important for users on slow networks, such as the many users in India, Brazil and other emerging markets.

Thanks,

Kevin

[oX Triangle]

exists any way to use the algos from FLIF-format for progressive saving?

http://flif.info/