JPG vs. PNG vs. GIF vs. SVG
uxdesign.ccThis 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.
> there's no reason to use GIF for any still image - PNG will be superior in all situations
For small icons with few colors, I find GIFs to be consistently smaller than PNGs.
For example, my website's favicon:
http://alexvh.me/favicon.gif 216 bytes http://alexvh.me/favicon.png 1041 bytesOne 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
Don't forget to run oxipng or optipng, as well; pnmtopng doesn't produce optimal PNGs.
(In this case, it just saves 3 bytes, but it can make a huge difference sometimes.)
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.
Neat trick! I exported from GIMP and then used pngcrush. Interesting that this case isn't covered by that workflow.
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.
Sorry, that should read "might not be helped".
Also apng. Time to retire gifs already.
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.
They have different perf characteristics. I use apng a lot. There's a good place for them.
apng also supports transparency while h.264 doesn't.
It might happen! IE and Edge were the last holdouts and now MS is switching to Chromium.
Why use a chart? It's what, four questions?
Is it a vector image? -> Use .svg
Is it an illustration (bitmap) with transparency (i.e. a cutout of a man) -> Use .png
Is it animated? -> Use .mp4 and fallback to .gif
Is it a photo? -> Use .jpg and compress as much as possible
Oh yes. Especially, never ever loose vector information if available. Vectors can scale. Bitmaps cannot. The chart gets this plain wrong.
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.
mp4 is for efficiency, gif is for compatibility.
if an mp4 doesn't play, a webm probably won't play either.
you can do mp4 -> webm -> gif if needed, but that's extra encoding that probably isn't needed.
Won't webm be more efficient than h264? (I'm assuming by mp4 you mean h264).
So you'd want to do webm → mp4/h264 → gif.
(I agree this isn't worth the time to set up in most cases)
You're right, you would try WebM first. Like I said I'm not sure why you'd do both. Anything that plays VP8/9 should play h.264.
WebM will play in cases where MP4/h264 won't play due to missing patent-encumbered codecs.
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.
gif supports transparency, mp4 doesn't.
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?
Correct
But just in general all of it needs to be redone when Webp is more widely used.
https://developers.google.com/speed/webp/
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)
webp can be a bad choice because it is always chroma-subsampled. png and jpeg support full chroma.
Anything coming off developers.google should be avoided like a plague.
There's no real reason to use a gif over png for non-animated images. You'll have bloated filesizes and a limited color pallette.
In many cases, .GIFs are quite a bit smaller than .PNGs. They're useful for putting small bits and pieces of artwork into data URIs, for instance.
CNCF spends a lot of time dealing with images, including the 1,172 on our Cloud Native Landscape <https://landscape.cncf.io/>. Here's our advice: https://www.cncf.io/blog/2019/07/17/what-image-formats-shoul...
Quite ironic that the chart (PNG by the way) does not even render in Firefox.
It requires javascript from a third party domain. Hah.
Works fine with NoScript and everything blacklisted.
Firefox 66.0.4 for Fedora
It'll work without Javascript if you already have the image cached.
Sorry for the late reply, but I just tried a clear cache+refresh and it still loads the image fine.
Privacy Badger was breaking it for me
What ? It does for me on Linux with Firefox 68.
PNG are handled by Firefox since Firefox 1 or 2, over ten years ago.
It's not the image, it's the 3rd-party script they use.
Wish i could read this. Ugh, Medium is the worst.
I think some people are taking this entirely too seriously.
This is clearly aimed at people who already know this. It's a joke.
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.
Is it a vector? Yes
Is it a logo? No
Result: GIF
I can't even
Only if it's a vector image that's not for a website. The chart assumes only websites know how to handle SVG.
But why would you downgrade an SVG to a raster-only format...
The SVG is also probably lighter in file size too.
Beats me. Well, unless it's for a platform that doesn't support SVG of course, but what doesn't support SVG these days?
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
The "burn it with fire" option for gradient logos and bathroom selfies makes this chart much less useful.
Yes. The much more environment friendly option would be to recycle the image. But I guess nobody cares about that anymore!
burn the chart with fire
Not a bad chart.
I can imagine it a bit more useful and less cluttered by removing bathroom selfies. Yet I understand the viral element: Burn it with fire!
how is it not bad ? it is absolutely not useful and the advices are misguided.
I know, also png can be transparent. However, most of the things are useful for newbies.
Is it a photo?
Yes: JPG
No: SVG
If you're uploading bitmap diagrams logos etc. they should be vector.
So which tool should I use to convert my screenshot to SVG?
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.
This one? http://johanneskopf.de/publications/pixelart/index.html
It might be apropriate in some cases at least.
Impressive, but it would at the minimum need some tweaking for it to work well with screenshots I think.
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.
is it a website? GIF -> https://gif.com.ai
It's 2019. Frontend developers who aren't using picture tags with WebP and a fallback alternative need to update their HTML knowledge.
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.
There is literally no downside to using it.
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?
https://www.macobserver.com/news/webp-comes-ios-10-macos-sie...
You don’t need to wait for Apple, you can use the <picture> element to show webP images and fallback to PNGs for browsers that don’t 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.
Can we please start a tag for medium articles posted to HN saying that they are member only articles? It is getting quite frustrating...
How to annoy me
Step 1: Suggest GIF as an option.
Why in the hell would you want vector graphics in GIF ever?
Is it a photograph? No
Is it vector? Yes
For a Website? No
Does it have a gradient? No
Gif
Wat? Once you get to "Is it vector?" it should just point to SVG