Issue 378 in webp: Support interlaced webp images (and better document lack of support in the meantime)

[jabron… via monorail]

Status: New
Owner: ----
Labels: Type-Defect Priority-Medium

New issue 378 by jabron...@gmail.com: Support interlaced webp images (and better document lack of support in the meantime)
https://bugs.chromium.org/p/webp/issues/detail?id=378

I recently experimented with converting a bunch of (~3 to ~400K) interlaced png images that are displayed on a landing page into webp (using ImageMagick’s `convert` command). I was happy to see the results had smaller sizes, but unhappy to see they didn’t seem to support interlacing; passing e.g. `-interlace Plane` seemed to have no effect.

Searching the webp project for whether the format supports interlacing did not yield any definitive answers. I assume it doesn’t?

If not, is there any interest in adding support for interlacing? In the meantime, webp unfortunately seems like a nonstarter for sites with large images that need to show users who have slow connections that something is happening during the (sometimes several seconds) time it takes each image to load. Users only tend to wait that long for an image to load when they can see the progress being made along the way.

Thanks for the great work on webp!

--
You received this message because:
1. The project was configured to send all issue notifications to this address

You may adjust your notification preferences at:
https://bugs.chromium.org/hosting/settings

[jz… via monorail]

Comment #1 on issue 378 by jz...@google.com: Support interlaced webp images (and better document lack of support in the meantime)
https://bugs.chromium.org/p/webp/issues/detail?id=378#c1

Thanks for the report. The webp format is finalized at this point, we chose not to do something like progressive jpeg or interlaced png as this has a high cpu and memory cost. WebP does allow incremental decoding of the image [1] which is used by chrome to render as much as is available providing some progress on slow connections.
A separate low quality thumbnail would be needed to display a full lower quality version at this point. There may be room for integrating this into a future codec.

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

[jabron… via monorail]

Comment #2 on issue 378 by jabron...@gmail.com: Support interlaced webp images (and better document lack of support in the meantime)
https://bugs.chromium.org/p/webp/issues/detail?id=378#c2

Thanks for confirming that interlacing isn't currently supported by webp. It'd be helpful to surface the info you just provided here somewhere more accessible. (e.g. A Google search for "webp features" turns up pages like https://developers.google.com/speed/webp/ and https://developers.google.com/speed/webp/faq but there seems to be no mention of whether interlacing is supported in any of them.)

More info about this use case since it might be helpful:

The landing page I'm testing uses https://github.com/mlisook/plastic-image to detect for webp support, provide smaller webp images if webp is supported, and larger – but interlaced – pngs if webp is not supported. The plastic-image element also uses IntersectionObserver to start loading below-the-fold images only once they're scrolled into view.

Fwiw, when I test with a slow (2G) mobile connection, the UX when the webp images are used is worse than when the pngs are used, despite Chrome's incremental decoding, due to webp's lack of interlacing. I put this version up at https://linktag.co in case you'd like to test too. I'll unfortunately have to remove the use of webp in a future version though unless there is something I can do to make the UX as good as with the pngs.

[jabron… via monorail]

Comment #3 on issue 378 by jabron...@gmail.com: Support interlaced webp images (and better document lack of support in the meantime)
https://bugs.chromium.org/p/webp/issues/detail?id=378#c3

I've dropped webp from the latest version of the https://linktag.co homepage in the interest of better UX. Hope that was enough time to take a look at the previous version if you were interested.

Also, https://github.com/webmproject/libwebp#readme is one more (maybe quicker to update) place you could include the info about interlacing status.

[jz… via monorail]

Comment #4 on issue 378 by jz...@google.com: Support interlaced webp images (and better document lack of support in the meantime)
https://bugs.chromium.org/p/webp/issues/detail?id=378#c4

> The landing page I'm testing uses https://github.com/mlisook/plastic-image to
> detect for webp support, provide smaller webp images if webp is supported,
> and larger – but interlaced – pngs if webp is not supported. The
> plastic-image element also uses IntersectionObserver to start loading
> below-the-fold images only once they're scrolled into view.
>
> Fwiw, when I test with a slow (2G) mobile connection, the UX when the webp
> images are used is worse than when the pngs are used, despite Chrome's
> incremental decoding, due to webp's lack of interlacing. I put this version
> up at https://linktag.co in case you'd like to test too. I'll unfortunately
> have to remove the use of webp in a future version though unless there is
> something I can do to make the UX as good as with the pngs.

Sorry I didn't get a chance to look at the page. I'm not familiar with these
frameworks, is it possible that's affecting the decode? Do standalone img's or
srcset's exhibit the behavior you're seeing? And is that one final image
displayed at once or row based updates?

[jabron… via monorail]

Comment #5 on issue 378 by jabron...@gmail.com: Support interlaced webp images (and better document lack of support in the meantime)
https://bugs.chromium.org/p/webp/issues/detail?id=378#c5

(((
I don't think it's possible that the <plastic-image> custom element is affecting the decode process. All it's doing is deferring the loading of an image until the user has scrolled it into view. It does this regardless of the image format, so comparing results with a webp image vs. a png should be an apples-to-apples comparison. Once an image starts loading, the decode process itself should not be affected.

That being said, let's rule this out by comparing what happens when loading standalone images.
)))

I observe this behavior clearly when I load the following webp and png versions of the same image in Chrome, while keeping the Developer Tools open to the Network tab, and choosing the "Slow 3G" preset:

https://linktag.co/static/masthead-bg-lp.png (652270 bytes)
https://linktag.co/static/masthead-bg-lp.webp (368968 bytes)

The png version starts showing something useful -- a pixelated version of the final image -- almost immediately, and then progressively refines the image over the next ~15 seconds until it finishes loading.

The webp version shows nothing for over 9 seconds until the image is fully loaded, and then displays it all at once.

Are you able to reproduce this behavior? (Tip: You can append any new value for the "v" query string parameter to try loading an image again while making sure caches are bypassed, e.g. https://linktag.co/static/masthead-bg-lp.webp?v=123. Ticking the "Disable cache" checkbox in the Developer Tools seems to be flaky.)

---

As an experiment, I tried generating a new webp version of this image from the png. The result is only 45730 bytes, which is not big enough to observe progressive loading while using the "Slow 3G" preset. But if you add a new "Custom" preset with a download speed of only 100 kb/s and try loading it, you should see it takes about 5 seconds to load, but with this version you see row-based updates:

https://linktag.co/static/foo.webp

I'm not sure why this smaller version of the image shows row-based updates but the larger version does not. To create the smaller webp version, I ran `convert masthead-bg-lp.png foo.webp` using ImageMagick version 7.0.7-28 Q16 x86_64 2018-03-25, installed via homebrew, along with homebrew webp version 0.6.1. I am observing this behavior using Chrome Version 65.0.3325.181 (Official Build) (64-bit) on macOS 10.12.6.

---

In any case, I think the proposal in this bug's title -- Support interlaced webp images (and better document lack of support in the meantime) -- should still be done. I'm glad to hear there may be room for interlace support in a future codec. I suggest the docs update about current lack of support not wait for that.

[jabron… via monorail]

Comment #6 on issue 378 by jabron...@gmail.com: Support interlaced webp images (and better document lack of support in the meantime)
https://bugs.chromium.org/p/webp/issues/detail?id=378#c6

To give users a faster loading experience, I have replaced the larger non-progressive webp images with smaller progressive versions generated from the pngs as mentioned in the previous post. So what used to be at https://linktag.co/static/foo.webp before has been moved on top of https://linktag.co/static/masthead-bg-lp.webp.

If you didn't get a chance to try to reproduce my results yet, I copied the old version of masthead-bg-lp.webp to https://drive.google.com/open?id=188CKg7-IfdeZLvZI6W5kkTcufEJ5ApHq in case you'd still like to have a look.

[jz… via monorail]

Comment #7 on issue 378 by jz...@google.com: Support interlaced webp images (and better document lack of support in the meantime)
https://bugs.chromium.org/p/webp/issues/detail?id=378#c7

Sorry for the late reply, I pulled the clip in comment #6 soon after and saw the behavior, but didn't look at the image closely enough until now.

The issue in chrome with this image is that it's a single frame animated webp. The animated path doesn't support incremental decoding. Using cwebp on the original or extracting the frame with webpmux or decoding with anim_dump and reencoding (this one is encoded losslessly) as a single image would display incrementally.

[jabron… via monorail]

Comment #8 on issue 378 by jabron...@gmail.com: Support interlaced webp images (and better document lack of support in the meantime)
https://bugs.chromium.org/p/webp/issues/detail?id=378#c8

Interesting, thanks for taking a look! I had no idea I'd ended up with animated webp's (running `file` on those files didn't mention anything that indicated that to me at the time I generated them – maybe `file` didn't yet know the difference). I've only ever needed static images, so whatever process I originally used to encode the webp's must have been wonky (maybe just using an older version of `convert`, wish I could remember). Anyway, glad to hear the newly-generated versions aren't animated (which I infer since Chrome is rendering them incrementally as they're downloaded).

Thanks again for the info, and for considering supporting interlacing in a future version.

[jz… via monorail]

Updates:
Labels: Milestone-Release2.0
Status: WontFix

Comment #9 on issue 378 by jz...@google.com: Support interlaced webp images (and better document lack of support in the meantime)
https://bugs.chromium.org/p/webp/issues/detail?id=378#c9

I'm glad new images are working for you. I'm going to close this one for now, but as mentioned we're exploring things like displaying the average color and small thumbnails as preview options for any future version.

[jabron… via monorail]

Comment #10 on issue 378 by jabron...@gmail.com: Support interlaced webp images (and better document lack of support in the meantime)
https://bugs.chromium.org/p/webp/issues/detail?id=378#c10

Cool, hope one of those ends up happening and gets a post somewhere like https://developers.google.com/speed/webp/ so more of us will notice. Thanks for your work on webp!