In 8-bit mode it supports even fewer colors than GIF (GIF can combine frames to achieve thousands of colors), and in 24-bit mode it's larger than GIF.
For full-motion video it requires 10x-15x more data than VP9 to be decompressed by the CPU, and there's no hardware acceleration.
https://kornel.ski/efficient-gifs
There's false dichotomy between "animations" and "videos", mostly due to historical reasons and that older codecs (and AWebP) used 4:2:0 subsampling which made them blurry. VP9 supports alpha, 4:4:4 mode, and it's cheaper to decode (it's more complex, but using 10x less data offsets that), so it'd be best to forget that GIF and APNG ever existed.
Technical limitations result in different cultural and artistic usages. Twitter's arbitrary 140 character limit resulted in a distinct culture. And it seems like not being allowed to embed images at all on Hacker News is part of this site's distinct culture.
And similarly with gifs. The question is whether you can move to a modern format (for better battery life) without also removing the limitations that resulted in a genre that's not just embedding an arbitrary video in a page.
The only problem is that VP9 is still lossy with RGB -> YUV -> DCT -> YUV -> RGB, similar to JPEG at quality 100. It kills it for universal use.
Moreover, it's a poor choice for vector animation and there's a high demand for it. But the same applies to APNG and GIF.
That's... technically possible but it gives you a ridiculous level of time-based artifacting when you need more than 256 colors to appear at the same time.
APNG beats animated GIF for most cases where animated GIF is useful. Just like PNG beats GIF for most cases where non-JPEG images are useful.
There are some good arguments in "Why not simply support WebM in <img>?": https://developers.google.com/speed/webp/faq#why_should_i_us...
It's why I find it hard to understand the excitement of many here about it.
This is very likely to take us backwards since most people don't get it.
Gifs/apng load and play instantly* and loop. There is no play button to click. No volume button, sliders, etc.
One simple link. Instant load and play.
*assuming good bandwidth
<video autoplay loop src="…"></video>Alpha channel demo: https://simpl.info/videoalpha/
In ffmpeg, the -lossless 1 parameter gives you a lossless encode. I don't use it much because mp4 lossless (-qp 0) has better compression and is faster.
A nice feature of APNG (and GIF) versus the more modern CSS/SVG animations is the CPU efficiency. It's really easy to accidentally waste a ton of battery life by adding a tiny spinning gear to a page.
It varies depending on the browser and whether the GPU is used for compositing, but it's much easier to optimize blitting a rectangle each frame versus blitting a rotation of some complex vector shape on top of the page.
I’ve never quite understood why implementations of GIF viewers in web browsers were so bad. In many cases it seems like they could cache every frame in GPU memory somewhere and very cheaply loop them. Caveat: I haven’t studied this in any detail, and am not an expert on image/video formats.
Imgur automatically converts larger GIF files to "GIFV" (WebM or MP4). The size difference is nuts: their example is a 50MB gif being reduced to 3.5MB
Their announcement post about it: http://blog.imgur.com/2014/10/09/introducing-gifv/
The thing is that you want 4:4:4 (no chroma subsampling) + alpha + lossless for pixel graphics. While some video standards support that in theory browsers often don't support those advanced profiles.
I try to stick to only animating the transform property, which should perform better than a raster format, since it doesn't require any new data per frame
I saw it many times that "GIFs" were used to denote what actually were small MPEG4 short clips. Made me cringe internally.
This is good news though; finally we can start to abandon the cruddy old GIF format and move to something more modern.
Technically it is more modern — replaces 1989 tech with 1995 tech.
But it's far from being modern. It's very lacking even compared to MPEG-1 from 1993.
Also, FLIF is much better than APNG, animated WebP, MNG, etc. If we are going to adopt a new universal standard as a replacement, that's the smarter route.
They are quite common in cheap cams
This is 2017, and when we look forward to 2020, we still dont have anything to replace gif, jpeg, apng, png. With Video we went from MPEG-1, MPEG-2, MPEG-4 ( Divx, Xvid, Rmvb, WMV, VP8 era ) H.264/AV to H.265/HEVC. Our Screen went from Low Res to 4K.
Surely all these browser Vendor can sit down and at least talk about this. How about supporting bpg for a start?
And lastly, I was naively thinking having APNG now would means x years before it is roll out to large number of consumers. But to my surprise even Chrome has a very high usage in China, 60% and growing. China is historically a region of IE6, I remember IE was still 40 - 50% in 2013 or 2014. You could now start to use APNG and soon have 60%+ of your users seeing it. Amazing.
Because it is not a still image, and therefore should have a different file signature, MIME type, and file name extension. It is simply out of scope for PNG. When designing PNG as a replacement for GIF, they very deliberately and decidedly dropped the animation feature. Implementing APNG as an extension of PNG confuses categories that should not be confused.
The goal was to replace GIFs. And look what happened: "GIF" became synonymous with "animation".
You had one job PNG. One job!
> How about supporting bpg for a start?
There’s FLIF ( http://flif.info/ ) with very promising compression results when compared against WebP, BPG, PNG and lossless JPEG. It also supports animations, which I linked to elsewhere in this thread. Seems like the format is also nearly complete.
Too bad, I can't put simple vimeo previews that work on all web browsers as a result.
I think there'd be a problem when customers copy/paste an image from the site into another application that doesn't support APNG. Seems like a common use-case that would cause a lot of customer confusion.
APNG_DISPOSE_OP_NONE: no disposal is done on this frame before rendering the next; the contents of the output buffer are left as is.
APNG_DISPOSE_OP_BACKGROUND: the frame's region of the output buffer is to be cleared to fully transparent black before rendering the next frame.
APNG_DISPOSE_OP_PREVIOUS: the frame's region of the output buffer is to be reverted to the previous contents before rendering the next frame.https://en.wikipedia.org/wiki/APNG
https://en.wikipedia.org/wiki/Multiple-image_Network_Graphic...
PNGs are stored as files with multiple kinds of chunks inside. The relevant one here is the IDAT chunk, which holds image data. Most PNGs have just one IDAT, but APNGs carry multiple (one for each frame). Readers that don't care about animating will simply display the first IDAT and stop reading there.
So it's a bunch of PNGs, coalesced into one, with some frame timing data. And the code for reading them is tiny if you already have a PNG library, because you display them like you would a regular PNG, but making sure to read out every IDAT, at the speed denoted by the acTL and fcTL chunks.
I would hazard a guess this is getting implemented now to try to make WebP look worse.
I found it to be quite buggy, slow, and even occasionally leading to crashes. I switched to webp. APNG was never given enough love, despite being a very useful format.
The gif animations are really video. They play in IMG tags; they are silent and do not have video controls. Put them in VIDEO tags and they ought to get video controls.
Putting a proper video format in an IMG tag should work like an animated gif does: silent, without video controls.
A plain image is a 1-frame video. It should work in a VIDEO tag, just to keep things consistent and orthogonal and all. A 1-frame video is an image; it should work with an IMG tag.