Comment by anentropic
5 years ago
Wow I feel old, everyone seems to have forgotten why and how to use these techniques :(
No one was dithering large photos back in the day - that's what JPEG are for.
The point of dithering was to take advantage of the reduced bit depth of indexed-colour GIFs (and later PNGs).
The Dither-Me-This tool does a lovely job of rendering different dither styles but then misses the point completely by exporting 32-bit RGB+alpha PNGs. 24 bits of RGB plus a 8-bit alpha channel? such decadence! A 16 colour dithered image only needs a 4 bit palette.
The type of images where this was useful in web design have mostly been made obsolete by the increased capabilities of CSS, and ability to render SVGs etc. e.g. graphical elements like borders and stripes of colour, or company logos. Or text in a specific font! (we didn't have web fonts in those days)
Why not use JPEGs for everything?
Two reasons: One is that heavily compressed JPEGs can make crisp straight edges blurry or fuzzy, and colours can get a bit desaturated. Bad for logos.
The other is that GIF had a Run Length Encoding compression which meant that large blocks of flat colour would compress very efficiently.
It's worth noting that RLE does not compress dithering efficiently at all... back in the day we would spend a bunch of manual effort to avoid unnecessary dithering (i.e. make sure blocks of flat colour are really all a single colour). But some dithering was unavoidable and sometimes, for specific types of images, it was possible to make a GIF that was smaller and looked cleaner than a comparable JPEG.
Also... WebP and AVIF compression rate looks great, but can it be used for websites today if not supported by Safari? https://caniuse.com/webp https://caniuse.com/avif
>Wow I feel old, everyone seems to have forgotten why and how to use these techniques :(
That is the reason why Web Development keep reinventing the flat tire.
> Also... WebP and AVIF compression rate looks great, but can it be used for websites today if not supported by Safari? https://caniuse.com/webp https://caniuse.com/avif
You load them conditionally based on browser capability or user-agent
Doing this makes a lot of sense for any web setup where you already have something you're calling an "asset pipeline", but can seem pretty nuts where you're writing simple no-JS HTML.
It's really not bad:
and you only need to bother with this on images it might matter (e.g. key large multi MB photos in a blog post or something not all of the 20x20 logo icons that would be less than 2kb even if uncompressed).
2 replies →
nothing about web for the last decade has been about no-JS HTML
its an option but doesn't leave you anything to contribute. the web is fragmented most of the toolchain is for simplifying deployment into that fragmented place without caring that it is fragmented. so not really nuts when everything already takes care of it for you. you can stick with no-JS HTML cached on an edge node just as well, or not cached if you expect low traffic, its whatever.
1 reply →
GIF uses LZW compression, not RLE, but your point stands that it more efficiently compresses long runs of the same color.
Ah you're right... I saw another comment mention RLE which jogged my memory, as you say it was the same point though, to have large areas of flat colour
It was BMP that used RLE wasn't it?
Everyone talking about compression is missing the original point. When GIF format came along, most people still had 8-bit displays. Photos look terrible if you reduce them to 256 colors naively. Dithering helped fill the gap in the early days of the web until 16-bit and higher displays became more common.
The point of dithering was simply that old graphics cards (e.g. VGA) only supported 16 or 256 colors.
Use of indexed-colour GIFs persisted long after better displays became commonplace, as an optimisation technique for reducing the file size of graphics for web pages