Fun fact: You can use webpmux to create a single static image which combines lossy and lossless parts

[Jos Hirth]

This is the background image: http://i.imgur.com/xHBo2Zd.jpg (30kb)

And this is the transparent foreground image (the text): http://i.imgur.com/NG69rIE.png (10kb)

cwebp -lossless -m 6 text.png -o text.webp

cwebp -q 50 background.jpg -m 6 -o background.webp

webpmux -frame background.webp +0 -frame text.webp +0 -loop 1 -o combined.webp

This is the result:

http://b.webpurr.com/xkM.webp (12.9 kb)

The background image was 8.6kb in size and the foreground one was 4.3kb in size.

If you hit F5, you can see the text flash. I guess +0 doesn't actually mean "0 msec".

[Vlastimil Miléř]

>
> If you hit F5, you can see the text flash. I guess +0 doesn't actually mean
> "0 msec".
>

According to spec, it should and in my editor, you'll only see 1
frame. I was talking about chrome ignoring this part of the spec in a
previous thread, but I am too laze to actually report a bug to the
Chrome team. It is your spec after all, guys...

[Jos Hirth]

If it's like the GIF behavior, then < 20 msec gets turned into 100 msec and 20 msec is the shortest delay you can actually use.

[Urvang Joshi]

Yes, this is something that browsers unfortunately have to do to avoid images flashing too fast: https://google.com/url?sa=D&q=https%3A%2F%2Fcode.google.com%2Fp%2Fchromium%2Fcodesearch%23chromium%2Fsrc%2Fthird_party%2FWebKit%2FSource%2Fplatform%2Fgraphics%2FImageSource.cpp%26l%3D144

And this is generic to any animated image (including GIF and WebP).

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

[Vlastimil Miléř]

Sorry, but no, that is just a lame excuse. Without knowing anything
about the actual code used in Chrome, I can say that it is trivial to
fix it. The only thing they need to do is to wait a bit before
finalizing a frame and sending it from a decoder to the browser. It is
easy to do and does not affect anything outside the decoder...

[Jos Hirth]

On Friday, January 30, 2015 at 7:43:41 PM UTC+1, Urvang Joshi wrote:

Yes, this is something that browsers unfortunately have to do to avoid images flashing too fast

20 msec = 50 FPS

http://en.wikipedia.org/wiki/Photosensitive_epilepsy

> [web] pages shall be designed to avoid causing the screen to flicker with a frequency greater than 2 Hz and less than 55 Hz.

Regular animations already fall into this range. So, that's clearly not the reason. Also, you can render as fast as possible with Canvas anyways.

Anyhow, a delay of 0 means that it shouldn't be displayed at all. This frame should be collapsed with the next one.

If every frame has a delay of 0, draw nothing if it's set to loop forever. If it's not set to loop forever, draw what you'd get after collapsing all the frames. Either way, the image wouldn't be actually animated.

Clamping the minimum delay is legacy cruft which shouldn't be copied from GIF. Back in the 90s, PC simply couldn't display it that quickly. That's why many used a delay which was too short. Photoshop's preview is still kinda like that. It renders animations way too slowly.

[James Zern]

This has come up a few times. I've started a bug [1] to see what the reaction of Blink developers would be. 

[1] https://code.google.com/p/chromium/issues/detail?id=454693

[Jos Hirth]

Thanks, James. :)

[fex]

Maybe a compromise is to add a flag to the webp header to indicate accurate timing. So any animated GIF converted to webp would have this flag off and have the existing clamped behavior, and any natively created webp could have this flag enabled so they are rendered properly on supported browsers/viewers.

[Jos Hirth]

I'd prefer if that GIF-related legacy stuff stays in the GIF-related tools.

E.g. gif2webp could have an "emulate_clamping" switch which defaults to true.

The clamping isn't part of any standard. Each browser does whatever it wants. I really don't think it's a good idea to copy this. There also isn't any reason for doing so. Today's machines actually can display some animation at 125 fps. If you specify a delay of 8 msec, you might actually mean 8 msec.

[Vlastimil Miléř]

Indeed, gif and webp are not the same and it makes no sense to copy
the bad things from gif. Handling of gif quirks should be left to
converters, webp is well defined and no additional flag, an "I am
sure" flag, is needed.

Handling of animations that are too fast can be a problem, but it is a
different problem than handling frames with 0 delay. Also the
solutions should be different. Slowing down fast animation can be
acceptable, but skipping frames would make more sense. On the other
hand, converting a 0-delay frame (which is not really a frame
according to the standard) to an actual frame is just wrong.

Let's no follow gif into the sad place it is now. It is *crucial* that
the webp spec and the one software that everyone will use to test
their webps against (Chrome) are in sync. It is Chrome that will
decide the future of webp. If it slows down fast webps like it slows
down fast gifs, people (using software made by lazy software authors)
will start relying on that feature and produce invalid webp files.
Once this happens, it will be too late to fix Chrome. If it converts
images with 0-delay frames into actual animations, people will again
start relying on that feature and the spec will mean nothing. Gone
will be optimization opportunities this feature offers for some
animations, gone will be the unexpected ability to combine lossless
and lossy in one frame...

Since webp animations are exceptionally rare now, there is still time
to fix this and not break anything. Chrome can (and should) be as
strict as it wants when treating webp files that are too fast. Simply
not displaying (or not animating) them would be better for the future
than slowing them down, because that will actually make the people
producing them produce them correctly. Simply not showing/animating
webp images with 0-delay frames would also be better than slowing them
down.

Microsoft learned this lesson the hard way with the Win32 API.
Documentation is nice, but the behavior of real software rules.

V.