Webkit's stance is basically "we're only doing it if upstream libpng supports it" (because APNG support basically requires a couple hooks in libpng itself) but the libpng devs refuse to accept the patch for apng support because they are of the opinion that libpng should process only PNG, not derivative formats, which is what they consider APNG.
No need to fork libpng. Currently, vanilla libpng and apng patch are both hosted on sourceforge, and it's trivial to automatically download both and apply the patch. In fact, a few distros (Arch, Gentoo, Mandriva, FreeBSD) already do exactly that for their libpng packages.
But keep in mind that apng patch only adds a few functions to libpng API, and it's entirely up to applications to actually use those API calls to request extra frames.
Honestly, I tuned out. Animations are procedural and are best represented with a scripting language - not with a declarative image format. Resource-constraining javascript within an (i)frame is probably a better way to spend a browser developer's time.
I believe there is a niche for simple animations: just a sequence of frames in a loop. No need for JavaScript, since it's just a simple loop. Easy to upload to image hosting services. And all browsers already support such simple-loop animated GIFs, so the code is already there, just not utilized to full (true color) potential.
This is true for the majority of animations, but .gifs have come to serve a niche for short video content sans audio that they uniquely fulfill on the web. If APNG or MNG or whatever could replace huge animated .gifs for things like r/cinemagraphs I'd be thrilled.
Having seen animated gifs, I can assure you that mngs (pronounced as mings) would be likewise huge. It's better to just have a 1-line JS script do this, and a standard for sandboxing nonthreatening JS.
But you can't upload that 1-line JS script to imgur.
Animated GIFs are getting very popular again because even with 5Mb-8Mb sizes GIFs are easier to handle today, comparing to downloading that 200Kb Dancing_Baby.gif in the 90s.
Animated GIFs are still humongous and slow to load, even with today's fast network links... Surely one of the bet reasons to replace them is to actually do a bit better.
The type of deltas used in GIF can be easily implemented as it's the standard alpha blending method, available at OS and GPU level. Can't say that about more complex delta-PNG algorithm from MNG spec.
I have to say, I never understood the need for a gif-like animation in a png-like format. Gifs have incredibly basic animation that's difficult to control in most (all?) browsers, and it's pretty useless for everything except brief clips on tumblr.
Here's your animated png format, put all frames of the animation in a png sprite sheet, and fill early pixels with metadata. Add in a small library and you've got a format that's allows for more advanced animation than gifs, with the better compression and alpha of pngs, and is supported right now in any browser with decent canvas support.
Of course the patents that were the heart of such controversy are now expired so GIF code is no longer 'not-open' but it has a bad reputation so we don't play with it any more :-).
I like PNG though, the library development, while a bit rocky at first, matured quite nicely and about 5 years ago crossed the point where enough people took the time to figure out how to use it that is dropped into everything that dealt with images. That has been pretty handy.
Yup, great point. I think if there weren't patent concerns over GIF years ago, there wouldn't have been nearly as wide support for the format, which means far fewer people would be using it today.
Sounds like there's need for a startup that fakes patents for obsolete file formats to create pressure for the industry to switch to technically superior alternatives. Who wants to fund me?
I know nothing behind the standard that is "GIF". But am i the only one who thinks its completely unreasonable that a few GIF's can turn my browser into a 5fps mess? How is there not a better option for this?
I've experienced this under Firefox, and on hardware that has no excuse for breaking a sweat on any webpage. It's usually pages where there are a large number of animated GIFs (e.g. [1]) Once all the GIFs are loaded and complete one animation cycle, everything's fine.
Are you sure you're not referring to animated GIFs? The slow FPS rate occurs as they load, and is contained to the GIF itself. Surely a static GIF would not reduce your browser FPS.
Don't be so sure it's a loading issue. I very often have animated gifs play very laggily the first time they run, even when they were already fully downloaded. And across multiple browsers I have seen issues playing gifs smoothly when there is anything else in the browser using CPU.
Those photographic comparisons are pretty subjective and zoom in on muddy/blurred areas of the image for comparison - it would have been nice to see the entire photos. The non-photographic images clearly give JPEG2000 an edge, but he then compares it to PNG. Lossy compression isn't for compressing things like pictures of text, which this guy notes but makes the comparison anyway.
The output quality is also codec dependent, and the one used in those tests has been shown to be towards the back of the pack in a 2005 shoot-out[1].
There is also no comparison between lossless JPEG2000 and PNG on a photograph.
More numerous perhaps, but not more important--going by the insane explosion in animated GIFs in the last two years... I think folks would have stuck by JPEG if it offered transparency.
That's hard to say. Saving the 512x512 FireFox logo, for example (with white background for fair comparison) at 99% quality JPEG from GIMP saves less than 5% space over PNG, and for images with even more solid white and simple gradients, PNG will beat high quality JPEG.
Even more importantly, frequency-domain compression is really not a very good alternative for most alpha channels for two main reasons.
First, most alpha channels are dominated by large regions of full transparency or full opacity. PNG thrives under those conditions. JPEG does OK.
Second, ring artifacts are a big problem for alpha channels. Whereas a ring artifact in a chroma channel will often be completely imperceptible to the viewer, a ring artifact on an alpha channel can turn transparent pixels opaque. Unless you correct the non-alpha channels to account for those artifacts on the alpha channel, you'll end up with noticeable black halos, even at relatively high quantization. That correction is difficult, and even if you do it well, the results are not stellar.
So while a hybrid format might work well, JPEG + alpha is not as simple as it sounds.
"...going by the insane explosion in animated GIFs in the last two years... I think folks would have stuck by JPEG if it offered transparency."
That does not make sense as JPEG doesn't support animation. Regardless, the blurriness caused by normal JPEG-compression levels makes it a bad option for most non-photo images.
Indeed, it seems that way after reading through it again and inserting a dot.
I would still argue that images used in the layout of the average site, most of which are already prone to having transparent parts, are better off using a lossless rather than a lossy format.
You're underestimating the number of non-photographic JPEG files in use despite lacking transparency. It appears a significant number of people don't care about artifacts.
That said, JPEG does today support lossless compression, if you really want to go there. It sort of even supports transparency[1].
Well, besides the fact that we don't actually live in a "Retina world", the use of JPEG, even on high quality settings, for an artificial (= not taken from a camera) image pretty much precludes the ability to produce derivative works from it without a much more serious loss of quality. That's not to mention that there are some things which high resolutions cannot make up for, like color bleeding and other pretty serious fuzzing that JPEG can introduce at low quality settings.
The point is that at high DPI, the "serious fuzzing" is much less noticeable for a variety of images. A retina screen has 4x the amount of pixels. Which means the 2x2 undersampled color errors are probably below our perception threshold. Especially if you pre-blur your high res image to a small degree, acting like an anti-aliasing filter when you scale it down by a factor of e.g. 1.5. For mobile, where users will be zooming a lot anyway, this is a very useful strategy to consider, which can absolutely beat PNG in image quality. Doesn't mean you have to do it everywhere, but I'd prefer it to having to download megabytes of images on retina devices.
It is very rare that a website has only perfect vector line art in its images. PNG sucks at compressing non-trivial gradients for example.
You've set up a false dichotomy, I think. Why use high-res low-quality images instead of just sticking with low-res high-quality images? It's all going to look fuzzy when you zoom in.
Also, palette images should get some love too. A high-res dithered GIF or 8-bit PNG might meet your needs (looks good on retina displays at normal zoom, stays crisp when zoomed in, smallish file size) better than the other options.
I really wonder why GIFs are still around. Apart for being used as short videos for funny things they have not a huge use afaik. They really feel like an old technology. They are also a pain to support on android.
GIF has a certain mindshare that the other formats don't, crossing over into folks who are less deeply technical.
I've worked with a couple web designers and developers that said "Gif" to mean any image, as in "Move that gif up twenty pixels" when referring to a logo that's actually JPEG. I think it's a holdover from the days of BBSes and AOL and CompuServe, where everything really was a GIF. "Check out this new cheerleader Gif I got." It's not a far leap to imagine these users just out of habit and familiarity clicking GIF in the save-as dialog without really thinking about it. So GIF persists out of familiarity and inertia.
GIFs are simpler, more widely supported, animated, and in many common cases result in smaller filesizes. But I believe the real reason they're still around is people don't want to fix what isn't broken.
There are a lot of cases where PNGs are superior, mostly because of the extra color depth. But that's not enough for a speedy transition.
I wonder what the pain point that is stopping the wider public from switching to a real video format for those short clips is. Given that real video codecs have much better compression at comparable quality, is it just the lack of simple tiny video hosting options comparable to imgur? <video> tags being harder to use on random posting platforms than <img tags>? Chroma subsampling "blurring" clips with sharp edges like from cartoons or 2d videogames? Something less obvious?
An <img> tag pointing to animated gif should work on every combination of image host + CMS + browser.
I'm not sure off the top of my head what HTML 5 market share is like (anyone with recent data want to chime in?), but I'm guessing lots of people are running browsers that still don't have <video> capability.
The percentage of users not able to use <video> is roughly equivalent to the percentage of users running IE8, which is about 20% right now, and probably will stay there in the near future, as XP users cannot upgrade to IE9 (thanks, MS!).
The other problem with <video> is that there is still no common format which every browser supports, so even if you would ignore IE8 (or provide a fallback via Flash) you'd still have to encode all videos twice (to H.264 and WebM/VP8).
Sad as it is, but Flash for video and animated GIF will stay with us for some years.
> Apart for being used as short videos for funny things they have not a huge use afaik
I wouldn't be surprised if those short videos were the bulk of the GIFs around. At least of the GIFs actually used and being dormant in some long forgotten archives.
I think it's because of IE. I know IE sopports transparent PNGs for quite a while, but until not very long ago there were not so many options and people don't really like to upgrade IE apparently.
Binary transparency PNGs (i.e. no separate alpha channel) have worked in IE since at least 6. So except for animation support there really is no reason to use GIF.
I believe the only reasonable use of GIFs today is to use for all kinds of 1px gradients for background where you can't use CSS3 for that. And even if image is big - it might be better off with PNG.
basically, if you use just few colors and no semi-transparency and you picture is small - yo might be better off with GIF, otherwise - either PNG or JPG depending on if you need semi-transparency or not, and if you need loss-less compression or not.
I wish h264 and the upcoming hevc encoded images would become a real alternative. far better quality (for pictures especially), at a lower bitrate from what ive read.
Neither APNG or MNG are supported in 2 of the big 3 browsers. If either format were supported in 2/3 of IE, Chrome/Webkit and Firefox/Gecko, it would get picked up by the other within 2 releases. Unfortunately the webkit/gecko guys are punting to the libpng guys, and nobody has budged.
"The PNG image file format is now more popular than GIF"... On the Web!
PNG has been more popular than GIF since a very long time for basically anything non-web needing lossless picture compression.
From smartphones icons to OS icons, software logos and icons, etc. I'd say the proportion is about 100:1. Actually I was suprised while just running a "find" on my Linux distro to even find a few .gif files. But thousands of PNGs, of course.
Screenshots taken from OS X and Linux are saved to PNG files (for OS X it actually depends on the version of OS X, sometimes PDF are used, but not GIFs).
And games... Lots of games ship with PNG pictures (as well as jpg of course). But GIF? Common...
It's actually a very, very long time that PNG files are more popular than GIFs.
I assume you're talking about IE6 not supporting alpha-channel transparency and IE7 getting the gamma wrong?
Both of those problems can be easily fixed (in most cases) by using iepngfix for IE6 and stripping gamma information from your PNGs (which you should do anyway, to minimize the size of your images). I've been using PNGs successfully in my projects for several years, and during most of those years I had to support IE6/7. In fact, if you need to support any version of IE, PNG should be the least of your problems.
> can be easily fixed (in most cases) by using iepngfix for IE6
It could be even more easily fixed by using GIFs instead. I assume that's what many people thought. Thankfully, IE6 is finally dead and no one have to worry about PNGs anymore.
Wonder what happened to the WebP format from Google? Last when I tried using it, there were no nice image converters that would convert my PNGs into WebP properly.
Mozilla is still against it. Makes me kinda angry, actually. They killed MNG/JNG, because it added like 100kB to the installer and because we should just use Flash instead (seriously). It's now a decade later and we still don't have a lossy RGBA format.
If quantized PNG8s aren't good enough, you can only use gigantic PNG32 files, which are over 5 times larger than JNG or WebP files. I've seen websites which were over 5MB thanks to that limitation. It's ridiculous.
I wish they had at least kept JNG. It's a fairly simple JPG/PNG mashup format. If you already use JPG and PNG libraries, supporting JNG won't add much weight.
Parallax websites are actually easy, because images are divided into many sprites/layers, so there's many palettes to work with.
I've got a pretty large collection of PNGs to test quantisation on and 68% of them end up converted in great quality, 89% are within acceptable range. It's about double of what you can get with Fireworks.
Actually this is a non-issue. You could always implement comma separated image fallbacks[1]:
background-image: image("wavy.svg", 'wavy.png' , "wavy.gif"); and so on...
It seems that Google lowered emphasis on the project, or is still working on it behind-the-scenes. I'd much prefer to have 'less of images' moving over the web (without cutting back on visuals, you know) and save precious bandwidth.
That only works for background images. Plus, the UA will send a request for the webp image even if it can't read the format. It needs the mime type to figure that out.
Ah yes. Then probably paste image raw data in the second fallback image? Though I do agree with you that something which benefits the web should be adopted across the board.
WebP seemed fairly pointless; its advantages over existing formats were slim, it had some disadvantages, and lacked any compelling new functionality (e.g. good HDR support). Basically it was pretty "meh."
Given the huge effort required to get any sort of widespread adoption of a new format—and without widespread adoption there's little point unless you've got some unusual features (which WebP didn't)—I'm not sure there was ever much chance WebP would go anywhere.
I'm generally no fan of Microsoft, but MS's new image format, JPEG XR†, seems vastly superior to WebP in almost every way... and it actually does have compelling new features.
http://caniuse.com/apng