Questions about Progressive Webp on iOS

[caiz...@gmail.com]

I have read the Doc for decoding progressive webp. But I have some questions.

WebPIDecoder* idec = WebPINewDecoder(NULL, NULL, &config);
// Question1: In libwebp, WEBP_EXTERN(WebPIDecoder*) WebPINewDecoder(WebPDecBuffer* output_buffer); 
// It takes only one parameter "WebPDecBuffer", but the doc takes 3.
CHECK(idec != NULL);
// Question2: What is bytes_remaining? If I'm downloading an image, and whenever I received some data, should I process the data?
// Or must I do the decoding after the whole data for the image is downloaded?(Because I don't know the byte_remaining until it is fully downloaded)
while (bytes_remaining > 0) {
// Question3: what is the input parameter? What is bytes_read?
  VP8StatusCode status = WebPIAppend(idec, input, bytes_read);
  if (status == VP8_STATUS_OK || status == VP8_STATUS_SUSPENDED) {
   bytes_remaining -= bytes_read;
  } else {
   break;
  }

// generate image

}
WebPIDelete(idec); 

Could you please help me figure out the Questions above?

And I would be grateful if you can attach sample code here...

Thanks

[Pascal Massimino]

Hi,

On Fri, Nov 4, 2016 at 7:48 AM, <caiz...@gmail.com> wrote:

I have read the Doc for decoding progressive webp. But I have some questions.

WebPIDecoder* idec = WebPINewDecoder(NULL, NULL, &config);
// Question1: In libwebp, WEBP_EXTERN(WebPIDecoder*) WebPINewDecoder(WebPDecBuffer* output_buffer); 
// It takes only one parameter "WebPDecBuffer", but the doc takes 3.

Good catch! It should be: " WebPIDecoder* idec = WebPINewDecoder(&config.output);"

Online doc will be fixed soon.

CHECK(idec != NULL);
// Question2: What is bytes_remaining? If I'm downloading an image, and whenever I received some data, should I process the data?
// Or must I do the decoding after the whole data for the image is downloaded?(Because I don't know the byte_remaining until it is fully downloaded)

Agreed, this code snippet looks more 'pseudo-code' than intended.

The intent was rather:

  while (there-is-more-data-available) {

     VP8StatusCode status = WebPIAppend(idec, fresh_data_received, size_of_fresh_data_received);

     ...

  }

Actually, the doc in decode.h is more up-to-date and explicit than the web page.

See: https://github.com/webmproject/libwebp/blob/master/src/webp/decode.h#L251

I'll copy-paste it here for simplicity:

	// WebPInitDecBuffer(&buffer);
	// buffer.colorspace = mode;
	// ...
	// WebPIDecoder* idec = WebPINewDecoder(&buffer);
	// while (has_more_data) {
	// // ... (get additional data)
	// status = WebPIAppend(idec, new_data, new_data_size);
	// if (status != VP8_STATUS_SUSPENDED ||
	// break;
	// }
	//
	// // The above call decodes the current available buffer.
	// // Part of the image can now be refreshed by calling to
	// // WebPIDecGetRGB()/WebPIDecGetYUVA() etc.
	// }
	// WebPIDelete(idec);

while (bytes_remaining > 0) {
// Question3: what is the input parameter? What is bytes_read?

yes, 'input' is the buffer pointing to the fresh data. 'bytes_read' is the fresh data size.

 

  VP8StatusCode status = WebPIAppend(idec, input, bytes_read);
  if (status == VP8_STATUS_OK || status == VP8_STATUS_SUSPENDED) {
   bytes_remaining -= bytes_read;
  } else {
   break;
  }

// generate image

}
WebPIDelete(idec); 

Could you please help me figure out the Questions above?

And I would be grateful if you can attach sample code here...

I think the above code taken from decode.h is clearer. If not, i'll post a more detailed sample...

hope it helps,

skal/

[Pascal Massimino]

Hi again,

both doc page [1] and code doc [2] have been updated. Hope it's clearer now.

Thanks for pointing this out!

skal/

[1] https://developers.google.com/speed/webp/docs/api

[2] https://chromium-review.googlesource.com/#/c/408078/

[caiz...@gmail.com]

Thanks a lot! By the way, is all webp images support progressively decode? Or only those are encoded "progressively"?

在 2016年11月4日星期五 UTC+8下午9:36:48，skal写道：

[Pascal Massimino]

Hi,

On Mon, Nov 7, 2016 at 7:35 PM, <caiz...@gmail.com> wrote:

Thanks a lot! By the way, is all webp images support progressively decode? Or only those are encoded "progressively"?

they are all decodable as 'progressive', no need to do anything special at encoding time.

 

--
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+unsubscribe@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.

[蔡哲人]

It's great. And for decoding, there are three types: interlaced, baseline, progressive.

Is there any option to choose the progressive decoding?

Actually I am trying to adopting the interlaced or progressive decoding to make better experience in our app. Baseline decoding may be helpful but interlaced or progressive decodings are better(For example: apply blur before the final image is downloaded).

Thanks for your patience!

在 2016年11月8日星期二 UTC+8下午1:58:59，skal写道：

Hi,

To unsubscribe from this group and stop receiving emails from it, send an email to webp-discuss...@webmproject.org.

[Pascal Massimino]

Hi,

On Mon, Nov 7, 2016 at 10:54 PM, 蔡哲人 <caiz...@gmail.com> wrote:

It's great. And for decoding, there are three types: interlaced, baseline, progressive. 

Is there any option to choose the progressive decoding?

These are JPEG terminology. For WebP, the proper term is actually 'incremental decoding': you get displayable pixels in raster order as soon as possible, whenever some fresh bytes are received.

Progressive decoding (interlaced or real-progressive. That is, your examples #0 and #1) put a lot of strain on users' side: memory and CPU consumption are ~3x larger than baseline. With 'incremental decoding' (your example #2), you don't need any extra memory or CPU.

Actually I am trying to adopting the interlaced or progressive decoding to make better experience in our app. Baseline decoding may be helpful but interlaced or progressive decodings are better(For example: apply blur before the final image is downloaded).

Yes, it's a good tradeoff between user perception and extra resource consumption is: send a very small 'preview' thumbnail, display it upscaled and blurred, while the larger image is downloading in parallel. There's been numerous blog posts around this idea, for instance [1] or [2]

hope it helps,

skal/

[1] https://jmperezperez.com/medium-image-progressive-loading-placeholder/

[2] https://code.facebook.com/posts/991252547593574/the-technology-behind-preview-photos/

To unsubscribe from this group and stop receiving emails from it, send an email to webp-discuss+unsubscribe@webmproject.org.

[蔡哲人]

I have trouble understanding "you get displayable pixels in raster order as soon as possible, whenever some fresh bytes are received".

What does raster order mean? In the picture above, the ice-scream is webp format.

If I get the webp data progressively. For example, the image data is 200 bytes totally. And when downloading data from the Internet, I received the first 80 bytes. And what might be the decoded result for the 80 bytes?

在 2016年11月8日星期二 UTC+8下午3:26:17，skal写道：

[蔡哲人]

Finally, I tested decoding progressively. Is it the "raster order" you mentioned?

在 2016年11月8日星期二 UTC+8下午3:26:17，skal写道：

[Pascal Massimino]

Hi,

On Tue, Nov 8, 2016 at 12:56 AM, 蔡哲人 <caiz...@gmail.com> wrote:

Finally, I tested decoding progressively. Is it the "raster order" you mentioned?

This 'raster order' corresponds to the 'baseline' case:

One trick, to experience incremental refresh using Chrome, is to force a slow connection with the developer tools:

 

If you open the 'Developer Tools', in the Network tab, you can disable the cache and select a GPRS connection.

Then, if you try to upload a webp image like this one http://www.gstatic.com/webp/gallery/5.webp

you should see the image being incrementally displayed as bytes arrive.

skal/

[蔡哲人]

😂It's sad... Will webp format support 'interlaced' encoding and decoding?

Or for some reason it won't?

在 2016年11月9日星期三 UTC+8下午3:45:12，skal写道：

[Pascal Massimino]

Hi,

On Wed, Nov 9, 2016 at 12:18 PM, 蔡哲人 <caiz...@gmail.com> wrote:

😂It's sad... Will webp format support 'interlaced' encoding and decoding?

Or for some reason it won't?

First, VP8 doesn't support this 'interlaced' modes natively (it would require some bitstream spec change).

And, most of all, interlaced modes have some user-side disadvantages:

  - much more CPU and memory is used to keep track of the unfinished images. Think of it, you're performing Fourier transform and YUV->RGB conversion for each passes. That's roughly ~3x more decoding than incremental decoding.

    These can be detrimental on resource-constrained mobile devices.

  - user-study [1] tend to indicate the progressive refinement from blurry to crisp isn't that pleasant (i'd agree). Better perceived is the 'blurred preview' approach [2].

hope it helps,

skal/

[1] http://www.webperformancetoday.com/2014/09/17/progressive-image-rendering-good-evil/

[2] https://jmperezperez.com/webp-placeholder-images/

在 2016年11月9日星期三 UTC+8下午3:45:12，skal写道：

Hi,

On Tue, Nov 8, 2016 at 12:56 AM, 蔡哲人 <caiz...@gmail.com> wrote:

Finally, I tested decoding progressively. Is it the "raster order" you mentioned?

This 'raster order' corresponds to the 'baseline' case:

One trick, to experience incremental refresh using Chrome, is to force a slow connection with the developer tools:

 

If you open the 'Developer Tools', in the Network tab, you can disable the cache and select a GPRS connection.

Then, if you try to upload a webp image like this one http://www.gstatic.com/webp/gallery/5.webp

you should see the image being incrementally displayed as bytes arrive.

skal/

--
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+unsubscribe@webmproject.org.

[蔡哲人]

OK, thank you for helping me😄

在 2016年11月10日星期四 UTC+8上午12:23:36，skal写道：

Hi,

To unsubscribe from this group and stop receiving emails from it, send an email to webp-discuss...@webmproject.org.