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.
Animated GIFs often burn huge amounts of CPU on my machine. A page full of GIFs can bring a modern computer to its knees. (This is one reason many image sharing sites convert uploated GIFs to proper video files, mp4 or webm or whatever.)
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.
You have gif with all its quality loss (256 colors and etc.), and then to make matters worse it's getting shoved through webm/mp4 encoding.
And then there's everyone from Imgur to Twitter missing the point of why gif is even a thing. Because it is simple. Because gif is treated as an image and not a video format. Because you can right click it, and save it for later use. Can't do that with "gifv" (seriously, I had to use curl just to get the video file from Imgur), and definitely can't do that with Twitter.
Neither webm nor mp4 can kill gif yet - mp4 is a patent mess, and webm comes closer (4chan for example has a quite big SFW community of people trading videos), but there are issues with Apple refusing to support it, and lack of hardware support.
A small note on a common misconception - the mp4 format is not something that is patented - that's h264.
Broadly speaking video files are first a container (e.g. mp4, avi, mkv, ts, etc). A container is sort of like a zip file. It groups together metadata about the file as well as the audio, video and possibly subtitle streams. In fact if you view an mp4 file at this level it reads like binary XML with 4 byte tag names.
The video streams are encoded using a video codec - e.g. h264, h265 (HEVC), vp8, vp9, ProRes and many others. Audio codecs are similarly varied - e.g. AAC, mp3, vorbis, theora and others. These are the parts of the file that can be patent encumbered.
In theory there is nothing stopping you from making an mp4 with vp8 video and vorbis audio. You can even ask ffmpeg to do it - it will happily oblige (and ffplay will play it). However the reality is that most non-smart video players will freak out at this kind of file.
Most simple players will expect mp4 to contain h264/AAC. This reality is starting to break with h265 encoded video in an mp4 container. Hopefully some of these assumptions will disappear over time. I believe mkv is currently the only reasonably popular container format that can usually play whatever audio/video is inside (mostly because only "advanced" players can even read it).
To add some confusion WebM is actually a hybrid. WebM is a more restricted mkv container with a VP8 OR VP9 video codec and vorbis or opus audio codec.
Try to save a webm if it serves you an mp4, though. Maybe they changed it lately, but I just could not figure it out - .webm and .mp4 both just silently redirected to .gifv last I tried.
Saving a video off imgur works about half the time in firefox, based on ???. There's a bug for it but it hasn't gotten much attention. It's a problem of imgur playing games with headers, embedding a video inside a web page and using the exact same URL for each. I haven't had any issues in chrome.
Twitter's just putting dumb empty divs over the content. And they make it impossible to get the source gif even in cases where the video version is larger and lower quality. Thanks twitter.
Some sites go to quite some length to ensure that users cannot download videos easily (I believe youtube has some javascript that assembles a lot of different video files while playing to ensure you can't get a direct link to the video) but you can go to similar length to protect normal images.
There are certainly many cases where using video instead of GIF makes much more sense. But if you're talking about continuous animation of 10+ elements, then I'm not sure video is a good idea.
We recently optimized electricitymap.org to use GIFs instead of CSS/SVG animations, reducing CPU usage between 50-95 percentage points (depending on setup). In our case, we were animating ~70 arrows causing 100% CPU on many machines, including my own beefed up MBPr from late 2013.
Looks great indeed, there is also the option to dynamically render the SVG animation to a sprited or multiple canvas once, and avoid to reevaluate and render the SVG for all instances on every frame.
There is no reason clients can't encode a GIF or APNG to H.264, cache that, then use the hardware video decoder on the GPU to render it. Whether that would be a win for performance or battery life probably depends on the exact hardware and how many of these things are displayed at the same time.
Using the optimized video code paths for GIF was discussed by the Mozilla graphics team several times. Basically the conclusion is that it's a lot of work when there's a perfectly good alternative which is using a video element. Effort that can be better spent elsewhere.
maybe let Mozilla know that it would be very helpful to their non-profit cause if they spent some time in rust making this work better.
they spend a lot of time adding new milestones, but this is one which could improve the quality of the web.
or they could design an extension which converts gifs to pdfs and we could continue to use their software for what it is:
zero day gateway with attached subscribers to a non profit software engine company which spends a bunch of time doing what they feel could make their impact last any longer than it already has
The frame data is incomplete with no keyframes - if you want to do a fairly typical memory conservation technique where after user switched away from the browser tab, you pause a GIF, unload it from memory, and then need to reload it from the same frame when user switched back - you will need to replay entire GIF to that frame.
At least for pixel graphics with transparency converting gif to apng would be a far better choice than gif to h.264 or vp9.
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.
ffmpeg is not the issue here, it supports several 444/alpha/lossless codecs quite well, proes is not special in that regard.
Browsers only expose a small subset of codecs that ffmpeg supports. gif and apng are now the most compatible format in browsers for this kind of content.
FourCC of ap4x 'just worked' on IE (I might have installed QuickTime codecs), Safari, and gstreamer with Firefox - it just played in the window (though I did not test alpha channel). I was surprised too ;)
I've noticed that gifs are made into videos too. I wonder if apng's will be efficient. I would think a small animated image like a .gif would be more optimized than a full on video file but I guess not.
Once you understand how videos are encoded, it's pretty obvious why gif (and apng) are not and will never be as small as videos. Videos use temporal data. You have one key frame (where the whole image is stored) and the following frames are encoded as delta (difference) from the previous frame. So a still video could basically be the size of a single image.
Animated images aren't that smart, they're just a bunch of images, so you're storing every single frame.
It's not quite that stark. You can have the non changing background solely in the first frame, and have subsequent frames (smaller frames even, placed at offsets) composed solely of "sprite like" things that overlay. And there are tools like imagemagick that can optimize existing animated gifs in that way. It is crude, but it's more than just a plain sequence of unrelated full size frames .
> Animated images aren't that smart, they're just a bunch of images, so you're storing every single frame.
GIF89a has a sort of limited delta encoding via the "do not dispose" option. If you write a frame with "do not dispose" and then write a frame with some transparent pixels, the transparent pixels will retain the colors from the previous frame.
It's rather primitive but it's better than nothing.
Use gifsicle. It's excellent and very fast, I don't think there's anything that produces smaller gifs than it. [0]
You can also use ImageMagick to produce optimised gifs (it has about 4 different options for that, eg -layers OptimizeTransparency). See [1]. But in my own tests, gifsicle always beats it (often by a huge margin) and is vastly faster. That ImageMagick page may be out of date. Also, Tumblr contracted the author of gifsicle, Dr. Eddie Kohler, to make some improvement for them, hopefully that made it back into gifsicle [2].
I think most GIF optimizers would do it, although I haven't tried any. E.g. https://ezgif.com/optimize says they do it ("makes unchanged parts of the following frames transparent").
Kind of an old reply, but I should honestly test that- encoding on a CPU only environment compared to one with a GPU with specialized support takes around 4-5x more, but I didn't test decoding yet on a CPU only environment yet.
This is true, if you animate CSS properties that trigger reflows you can seriously harm battery usage.
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 had the same approach as this. But not all animations can be made using the transform property, and even if you avoid reflows you can still have a lot of CPU usage with simple animations. In our case, we were moving a gradient inside a div. You wouldn't think this uses a lot of CPU, but if you have enough of them, it becomes a problem - there is apparently a lot of CPU processing involved in re-rendering regardless of reflow. Using the translateZ(0) trick did not eliminate the issue.
In my experience, you really need to work with designers who are willing to consider the technical impacts of design choices within the browser. You need to be able to say, this animation style causes strangeness and performance impacts... are their other designs that don't have the same technical needs and still achieve our product goals? The coder needs to be willing to understand the design constraints and the designer needs to be willing to understand the code constraints and both people need to take joy in finding solutions that tick every box.
If you have a "throw the designs over the wall" workflow, CSS will never work, you have to go to iOS or Unity or something like that where you have minute control over every detail. On some level, this becomes an identity issue... are you Mercedes, or Apple, who will marshal incredible resources to control every detail of a production, or are you a Craigslist, or Bikini Kill, who will sacrifice any and every technical consideration to maintain laser focus on a singular goal.
Put another way, are you the conqueror who flattens an entire ecosystem to build your perfect palace, or a craftsperson who takes a small amount of material each day, and makes something beautiful within the constraints?
In case anybody is wondering how to roll out server-side support for this with a fallback to GIF: they've added "image/apng" to the Accept header for image requests. It's now "image/webp,image/apng,image/,/*;q=0.8". Sites like Imgur could start serving APNG images today.
> Sites like Imgur could start serving APNG images today
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.
Happened to me with a webp (on another site). And of course it had a .png extension because that was the original URL. After finally figuring it out, I had to go back and visit with another browser to get the right format.
APNG started in 2004, I am not sure why it took so long, 13 years before it is landed in Webkit and Blink / Chromium.
The fight with MNG only lasted few years. PNG rejected the APNG proposal multiple times ( Why ? )
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.
> PNG rejected the APNG proposal multiple times ( Why ? )
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 main goal was to create a patent-free replacement for GIF, with a number of improvements for its main uses. GIF animation was not used much at that moment.
Still, it's not like it was impossible to make some last minute changes, while PNG was still relatively young. See https://boutell.com/innards/apng.html
You have to admit it's a little funny that if PNG's one goal in life was to replace GIF, they chose to not support the one thing GIF is used for today.
The popularity of animated GIFs, or the use at any scale of them at all really, only came after PNG was finalized.
The design of PNG started in January 1995 and PNG 1.0 was published in October 1996. Netscape Navigator added animated GIF support in September 1995, and if I remember correctly, it wasn't immediately used at large scale. Anyway, by that time, the PNG team had IIRC already decided to put animation in a yet-to-be-designed MNG.
> This is 2017, and when we look forward to 2020, we still dont have anything to replace gif, jpeg, apng, png.
> 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.
Imgur converts most moving images into mp4 and webm, serving the optimal file to the browser the visitor is using. I think this is part of the reason why people use the word "GIF" for any moving media these days as imgur is a very popular medium.
GIF also has the connotation of the animation or video being short (under 30 seconds), often subtler animation, and without audio - whereas "video" implies more a traditional multimedia presentation.
You won't ever fully replace GIF, at least not in the next decade. There are too many devices and apps/software that ONLY have GIF support due to the low computational footprint (designed for 1989 hardware). There's a reason why all these sites that have replaced GIF with HTML5 video still have a GIF fallback available. The file size is usually much larger, but it is supported everywhere. 100% of devices will be able to support GIFs. It's hard to argue with universal support.
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.
It is said that the MNG decoder uses a few hundred kilobytes of code whereas APNG reuses more code from the PNG library. APNG is sort of a hack where the first frame is a normal PNG and subsequent frames are hidden in custom chunks.
It's not that the first frame is a normal PNG and that the rest of the frames are hidden. That's close, but it's not exact.
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.
Yes most PNGs have just one IDAT, but having multiple IDATs does not imply an animation. In a normal PNG, the specification says that the contents of the IDAT chunks are chained together.
This feature is used if the DEFLATE compressor only uses a small output buffer (because each chunk has a length and CRC). The feature is also used if the PNG is enormous, because the maximum size of a chunk is 2^31 - 1 bytes but by chaining IDATs it is legal to represent image data that can't fit in a single chunk.
When testing APNG for a local project last year which involved only Firefox, I was trying to save some space and have better color support using APNG.
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.
Hard to find any. It's a primitive format ignoring 20 years of video compression research. It tries to be replacement for GIF by repeating its mistakes: it has very basic inter-frame compression, lacks motion vectors, doesn't guarantee keyframes, RGB-only, and frame decoding isn't parallelizable.
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.
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.
Which makes the timing all the more inscrutable. AV1 is supposed to have its bitstream finalized this month. Why now, when WebM is so widespread and there are new formats on the horizon, resurrect APNG after neglecting it at the only time it was relevant?
APNG is the format Apple is using for sticker packs in iMessage. I'm gonna go out on a limb and guess Google is ramping up to announce a sticker store for Allo... sticker pack devs could port them over without any effort.
Small pictures to put in chat clients, rather like large emoji. It seems pointless, but I've had friends complain about going from clients that support stickers back to text chats like irc.
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.
GIF and APNG are not video formats. They are lossless image formats that support sequential animation. They have never been intended to share video clips. You have a very narrow view of what can be done with GIF and APNG.
That's like saying that audio is nothing but 0s and 1s. Video has analog origins, and digital video formats are heavily influenced by this. All the video compression techniques make little sense for animation, unless you like JPG artifacts and banding. There's no video format that supports transparency on most browsers. There's no video format that works with tiny dimensions (I tried to upload a 3x3 gif to Imgur and it failed because it couldn't convert it to "gifv"). Video formats have no concept of palette, frame delays and frame disposition. APNG with its partial transparency support offers so many possibilities in web design that it's really a shame Chrome didn't support it for so long.
If video is so much better then why do we see it used so much less than it ought to be? Possibly partly because generating video is too difficult for many?
> In 8-bit mode it supports even fewer colors than GIF (GIF can combine frames to achieve thousands of colors)
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.
Time-based artifacting? I think you might not be aware that it's not necessary to have a time delay between frames (in fact, time delays and animations are actually a Netscape extension to the format!) In fact breaking a frame up into multiple pieces with different bounding boxes is a compression technique used to reduce the amount of zero bytes that need to be encoded/compressed. ImageMagick and gifsicle will do this.
If you set the delay between frames to 0 or 1 hundredths of a second, browsers will assume it's a mistake and bump it up, usually to 10. The fastest you can actually make the delay is 2/100 of a second. There's no way to have multiple frames show up simultaneously.
User experience is worse with GIF. It takes more bandwidth and consumes more CPU time than a comparable video in cases where video is applicable (and when the other cases occasionally pop up, lossless WebP is probably still a better choice). HTML5 video can be set to autoplay and loop and doesn’t have controls by default:
The user experience is miserable. They take longer to start, impossible to stop, burn bandwidth and CPU. Scroll through something like kotaku sometimes, it's an utter poopfest.
300ms is a good target for a page load, not for a pointless animation. And that's a 3MB gif. The page also contains a 2.6MB one, two 6+MB ones and one over 7MB. The entire page is over 30MB. Scrolling through it takes the sort of bandwidth typically used for a high quality streaming movie. At 1 to 2 MB/sec you can easily miss something is an animation in the first place because it won't have time to load. Of course, you're not really missing anything other than a low-fps repeated distraction you can't choose to start or stop. This is a good user experience the way a fresh pile of manure is warm shelter.
All true, but those aren't necessarily problems with the concept of a gif, and could be fixed with another format, that isn't necessarily a full on video.
I think the concept of gif's is fairly great, but the actual format itself has tons of issues.
It seems to be covered adequately by formats supported by current browsers. Try pasting a link to a gif in Facebook. Facebook will convert it to an mp4 and put a big 'GIF' button on top of it. This doesn't seem to bother or be noticed by (statistically) anybody.
That doesn't really count. A dozen tabs in Firefox might also give you a rash, the solution is to probably stop using Firefox not to convert videos to gifs.
Why is it not a fair comparison? A page full of gifs in a browser gobbles bandwidth, can't be interrupted, eats lots of cpu. A page full of gifvs doesn't have any of these problems. One of these is a lousy user experience, the other one is not. I don't have to make both of these things a shitty user experience just so the comparison is 'fair'.
It's much like PNG vs JPEG. Like JPEG, the most common video codecs all use compression based on the discrete cosine transform (DCT). This makes them well suited for most video content which has a lot of continuous tones. APNG is better suited for simple animations with lots of flat shading, where video codecs would generate ugly artifacts. A classic example where APNG would be preferred is the ubiquitous throbber animation used by various applications to indicate that they are busy with some task.
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.
APNG is great, but animated FLIFs[1] would be even better. Looks like many of their former todos have been completed, and from the remaining ones, only three are related to the file format per se. Hopefully these, too, get completed in time. Although, seems like getting support for new file formats in browsers takes time...
Fucking finally! I've been following this bug for at least 5 years. 5 years ago, when it was first proposed, this could have been a big deal. Not sure these days.. but I sure would love to see GIFs disappear..
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.
Yes. Each frame can specify a region of the overall image, usually just the bounding box of the changed pixels. There are a few options for retention:
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.
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.