Chromium: Add support for Animated PNG
chromium.googlesource.com
chromium.googlesource.com
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 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
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?
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.
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.
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].
[0] https://www.lcdf.org/gifsicle/ [1] http://www.imagemagick.org/Usage/anim_opt/#compress_opt [2] https://engineering.tumblr.com/post/80003435120/who-doesnt-l...
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
at least then the pdf would open in chrome :)
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/
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.
Twitter though, doesn't seem possible
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.
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.
That’s just because their implementations are bad. Browsers have a “Save” context menu entry for videos by default.
youtube-dl works with basically everything that matters, including imgur gifv and twitter videos.
youtube-dl https://twitter.com/Footballogue/status/841905302438043648
youtube-dl http://i.imgur.com/te50Z9W.gifv
youtube-dl is the best thing since sliced bread.thanks to youtube-dl it is simple to download videos in a nice format instead of as gif.
gif as a format has served it's purpose. let gif die.
If people upload a video, then the gifv has more or less full fidelity.
If you right click a video, you can download it. See http://imgur.com/eOsqgv3
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.
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.
https://en.wikipedia.org/wiki/Apple_ProRes#ProRes_4444_and_P...
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.
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.
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.
Too bad, I can't put simple vimeo previews that work on all web browsers as a result.
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!
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.
None the less, a funny end result.
> 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.
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.
Not if you have aliased frames.
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
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.
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.
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.
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.
http://www.ubergizmo.com/2016/06/line-270m-a-year-sticker-sa...
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.
There are some good arguments in "Why not simply support WebM in <img>?": https://developers.google.com/speed/webp/faq#why_should_i_us...
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.
VP9 can also be lossless if desired, and what is a video if not "sequential animation"?
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
When I paste that in an incognito window it displays and plays instantly.
I think the concept of gif's is fairly great, but the actual format itself has tons of issues.
<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.
I would hazard a guess this is getting implemented now to try to make WebP look worse.
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.
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.