This chart offers some dubious suggestions, even ignoring the "Burn it with fire" bit. Unfortunately, it doesn't explain any of its reasoning.
A photograph that's not real big is probably still better suited for JPG. And there's no reason to use GIF for any still image - PNG will be superior in all situations. A moving image may be better off as an MP4 for modern browsers in terms of file size and quality, but there's no mention of that here.
One of the problems with PNG is that many applications default to full-color-with-alpha-channel as the only save method, even though PNGs can do paletted images just as well as GIF and end up basically the same size. So people look at their PNG files and wonder why they are so big compared to the old GIFs because their application sucks.
Edit: I just tried it with your example:
% giftopnm favicon.gif | pnmtopng > favicon.png
pnmtopng: 5 colors found
% ls -l
-rw-r--r-- 1 jandrese jandrese 216 Aug 7 17:33 favicon.gif
-rw-r--r-- 1 jandrese jandrese 255 Aug 7 17:33 favicon.png
I actually pngcrushed the result after that just to see how many of the remaining 39 bytes I could get back, but had the same result. PNG has just a smidge more fixed overhead than GIF.
oxipng got it down to 248 bytes. And yes, PNG has a little more fixed overhead, such as the IEND chunk and some of the required IHDR metadata. That only tends to be an issue in files this small, though, and gets dwarfed by potential savings in larger files.
You are right, I tried creating a 16x16 image with 3 colors and despite my best attempts, the GIF came out to 93 bytes and the PNG 139 bytes. So there are cases where the GIF will be smaller than the PNG.
On the other hand, if you are loading enough small PNGs for this to make a difference, perhaps any performance issues that come up might be helped by switching from PNG to GIF.
Hasn't apng been made obsolete by mp4 before it managed widespread adoption? Basically they were supposed to be easy like the old animated gifs, but developers dragged their heels on it so long that they forced people to adopt the full fat alternatives in the meantime.
mp4 with fallback to gif doesn't make much sense. More appropriate would be webm, or in the future AV1 with a fallback of h264 mp4 for video or high quality animated images. Using gif for small animations is fine, especially if you have transparency.
That's not a big real world issue though, but yeah if you want to provide 100% compatibility it would help a little. It's hard to justify the extra (less efficient & slower) encoding to support those few edge cases.
h.264 gives you good performance, hardware encoders/decoders, best compatibility. Most of the time just using it alone is the best value.
All that depends on how many videos you need to transcode though. If you just have a few, do all the main codecs.
The "Yes" path for `Is it transparent?` leads to the node, `Does it move?`, for which "No" leads to `JPG or PNG`. But clearly the answer should be just `PNG`, right?
And in that case almost everything can be a webp - animations, transparency, lossy for compression or lossless if need be. You can still burn the bathroom selfies if you want. Except vector, you still want SVG for those.
WebP will never take off due to Apple not supporting it. If Apple chooses to support the AV1-based AVIF, that will become the next big format instead. Apple has joined the AOM so there is a reason to believe they will (but then again they also joined the Blu-ray consortium and never shipped a Blu-ray drive)
SVG to me is always overlooked as a means to present not merely vector graphics but also other things like JPEGs with alpha transparency at a smaller size than equivalent, non-indexed PNGs for larger images (link a JPEG for the image and another JPEG/PNG/GIF for the mask, or both together as one image and use half for one and the other).
It's a rather flexible format, even if you're only embedding it within an img element/via CSS (ie: disabling its other possible functionality like video/JS/interactivity, though this comes at the downside of requiring base64'ing the embedded images, offsetting the some of the filesize savings...).
One can also utilize CSS animations within them (or alternatively SMIL in any Blink or Gecko based browser), whether embedded as an object or image.
I tried writing a breakdown of image formatting for the web (specifically ecommerce) that mostly focused on JPG vs PNG. It's still WIP but if anyone wants to check it out or has feedback please reach out. It's specifically not blogspam, more of a working document that I hope to be able to share with clients: https://aloagency.com/blog/preparing-images-for-web
I know you say that in jest, but I've always been curious if anyone has ever compared the size of tokenizing an OS X Quartz 2D stream that renders a screen against a PNG of the same screen. I wonder what we lost on the road not taken when as an industry we solidly branched away from Display Postscript as a possible industry-wide rendering engine, and it is unlikely we will ever explore that branch in the foreseeable future.
As noted in a thread comment elsewhere, under the hood our display rendering engines are already entirely or significantly vector engines, but what we appear to lack is an industry-wide representation scheme.
That's an excellent point. Screenshots are currently the exception, but shouldn't be - most UI is vector but OS screenshot tools don't record them properly.
Safari doesn't support WebP, unless they added it recently, in which case there are still a lot of non-(WebP-supporting) Safari browsers out in the wild.
As always we need to wait for Apple to get their shirt together.
The <picture> tag provides a nice, no-JS <img> tag upgrade that works in browsers (it doesn't break in IE so long as you have an <img> in there) to deliver the right image to the user. That means the user gets a smaller download, faster to render, higher quality image. It's essentially progressive enhancement for images (everyone gets the JPG or PNG, some users get a better format if they can handle it).
You can even add media queries to the <source> tags to deliver different images based on the user's device.
caniuse.com currently states that "Safari is experimenting with supporting WebP images." I Googled around for more info, but the most conclusive thing I could find is this July 2016 blog post mentioning that "WebP Comes to iOS 10, macOS Sierra Betas". Since we're well past MacOS Sierra and iOS 10, does that mean Apple has given up trying to support WebP?
More realistically though until they support it I'll just stick to JPGs and PNGs and forget about this fallback mess. It adds unnecessary complexity to sites that are dynamically generated.
What this tells me is that when you build a site that has images uploaded by a user, you do nothing to those images. You just take the upload and stick it in an img tag to display it.
This is the exact problem with developers building for the Web. You'd rather avoid a relatively small amount of additional complexity than build something that's better for users (loads faster, reduces bandwidth, renders quicker).
Even ignoring WebP, you really should be resampling the upload to the right size and running it through something like imagemin to optimize the file size. And there are APIs out there that will do it all for you - it's a post request at most if you don't want to set it up on a server.
Not exactly true, this isn't about user-uploaded images. I get it, but optimized JPGs are working, and if it isn't broken, don't fix it. When everyone supports WebP I'll switch to WebP and ditch JPG but I'm not in any hurry and have plenty of other broken things that need to be fixed first.
A photograph that's not real big is probably still better suited for JPG. And there's no reason to use GIF for any still image - PNG will be superior in all situations. A moving image may be better off as an MP4 for modern browsers in terms of file size and quality, but there's no mention of that here.