Dithered images and websites (2020)
endtimes.dev
endtimes.dev
In fact, even in the 80's, dithered images were often larger than their un-dithered counterpart, sometimes by a lot. But it was worth the trade-off when the alternative was an image with so much banding that it could be confused for a European flag.
Unless you're trying to display your image on a retro console (or have aesthetic reasons for wanting to achieve that effect), you should not use dithering. Essentially all modern devices have a sufficiently enormous color palette, and modern compression algorithms use other techniques to achieve their efficiency.
In fact, modern compression will do a much better job giving you a smaller file size if you don't use dithering.
Edit:
Don't get me wrong, dithering is a super interesting topic, and designing a good dither can be surprisingly hard, it's just not going to help you if your goal is to shrink the images on your website the way the article claims.
If you haven't seen the trailer for "Return of the Obra Dinn" you owe it to yourself to take a look:
Super cool aesthetic, and writing that shader must have been all sorts of difficult/fun. But you don't do this sort of thing for compression efficiency.
The header image for this page was a doozy: https://uplift.games/about/
Originally, the image came from art with the glow around the planet being dithered. The resulting PNG was over 2 MB, resisted crushing, and didn't downscale well. Trying to use AVIF and WebP with aggressive compression made the image look awful.
We asked if they could remove the dithering and suddenly we got super great compression with some tweaking: 50 kB as AVIF, 68 kB as WebP, 797 kB as PNG (oof!)
This is a large banner image. Smaller images can get _much_ smaller with AVIF and WebP with no sacrifice of quality. It takes some tweaking and the tools were pretty bad in my experience. We wrote a couple utilities to do this and fiddled with knobs for awhile and it turned out great.
EDIT: Looking at this page again closely, I can see interesting artifacts because of AVIF. Look at the robo-dog's left ear! You could probably use slightly higher settings than we did.
Old trick to squeeze a few kb out of a png: Use Posterize filter from Photoshop, with very light settings. Basically it will just flatten the number of colors.
Now you can mess around with the number of colors in the color table, customise the color palette selection algorithm, dithering algorithm and dither amount.
Not sure how you created those AVIFs. The reference AVIF encoder[0] wants to use 4:4:4 chroma, but it looks like that hero image is 4:2:0. There is a small size hit for 4:4:4, but edges around saturated colors is much better.
AVIF can look fine in full color at 0.5 bits per pixel. That's equivalent of a black and white dithered bitmap with 2:1 compression ratio.
Low-color dithering can be a nice artistic filter, but it's not useful in image compression in general.
When this streamer on Twitch tried to play it [1], the quality of his composited webcam would immediately drop as the compression algorithm focused on rendering the high-frequency dithering sections of the screen. As soon as he would aim the camera away from the fancy rendering (to the sky for instance, or the menu), the video quality would immediately improve. Really a fascinating clip.
[1]: https://imgur.com/S191sI0
Here's a thread of someone complaining about it on Reddit:
https://www.reddit.com/r/Twitch/comments/ls06j5/the_unstream...
If your compression algorithm isn't aware of the exact dither you're using, the decompressor can't reproduce the dither on the other end using only rules and image data. The compressor needs to encode every single dither pixel as an expensive "Hey decompressor, you're never going to be able to guess this pixel value, so here's the whole thing" residual value.
This is also why old image compression algorithms that were aware of simple dithers (i.e. a handful of fixed grid patterns) could produce small-ish images that looked slightly better than un-dithered, but still kind of bad. But then as soon as you customized the dither to use a more random looking pixel arrangement that looked significantly better, the filesize would explode -- because the compressor was blissfully unaware of the more complicated dither and had no choice but to encode all of the seemingly random pixels directly.
[1] https://forums.tigsource.com/index.php?action=profile;u=3073...
Not necessarily. The idea of dithering is to use a representation with a smaller color space, meaning fewer bits per pixel, possibly palettized.
The idea is to control where the lossiness "damage" happens. You deliberately discard information in the area of color depth, rather than whatever the modern compression might choose to discard. It's possible you could get results that to an observer appear subjectively better per file size.
Imagine a photo of masonry brickwork. What's important is the edges between the brick and mortar, while you don't really care about the grain within a brick. General-purpose image compression tends to smear sharp edges like that. It's possible you could do subjectively better by reducing the color depth, to intentionally discard more of the data that you don't need with dithering to keep a little of it, while keeping more of the information you do want in the sharp edges.
I'm not claiming any of this would pan out for real-world use, but there are certainly hypothetically feasible cases for dithering.
The algorithm is already looking for patches of image that have moved by possibly hundreds of pixels (to sub pixel accuracy) both within a single frame, and across multiple frames.
Basically, it'll find a patch of image that, when shifted horizontally and vertically by a certain amount, looks pretty close to the patch of image that it's trying to encode. The compressor will then say "just copy that region that you decompressed half a frame ago to here first, and now the residual values I give you are differences between the first patch and the second."
Even if the brick / mortar phase is slightly off (e.g. from perspective or lens effects), this will give you about an order of magnitude more compression efficiency (and perceptual quality) than anything that tries to use color depth to preserve edges.
It's possible to do optimal-ish highly compressible dither (it's been done for LZW), but the results are still pretty disappointing compared to even old JPEG.
https://imgur.com/a/eBxFlL5 has 4 images next to each other - the original scaled down image, the 14 KB dithered image, a 14 KB JPEG, and a 8 KB webp (both the JPEG and WEBP were at the full 500x500 resolution, downscaled afterwards, since in my experience that often yields better results).
Yes, dithering will increase the file size of a losslessly compressed image. That's because it contains more information. If you're sufficiently bothered by file size to degrade color accuracy, why are you using lossless compression to begin with?
Dithering is an essential component of any digital signal processing pipeline, not some weird retro artifact.
Dithered 8-bit/256-color images will look 'better' than non-dithered 8-bit/265-color images, but it will almost always be worse that a 24-bit JPEG (no alpha) or 32-bit webP (includes alpha) and have a much larger file size.
I did some quick tests with https://squoosh.app. The 8-bit dithered PNG is >4x the size of the JPEG. It also shows some terrible banding on any kind of gradient in the image. The PNG is 5x larger than a better looking webP version of the same image.
I tested a lot of images (photos, drawings, digital artwork, etc) and some of the images were 10x larger as dithered PNGs vs webP/JPEG. Only one was smaller as a dithered PNG.
B. If the comparisons keep the pixel size constant, they're not relying on the cool thing about dithering, which is that you can dither down to a small color count and quite small pixel size then display larger with image-rendering: crisp-edges; and it'll still look #aesthetic. From my experiments with the tool you linked, the scaled-up equivalently-sized webPs look potato. This is most relevant for big hero images.
I'm thinking specifically of non-HDR displays displaying HDR content (where HDR10 includes 10-bit-per-channel color.) Presumably the compsitor, if it knew you were watching an HDR video on a non-HDR display, would do better by dithering the HDR content down to 24-bit non-HDR content for display, rather than allowing it to be naively rendered with 24-bit banding?
https://doodad.dev/dither-me-this/
It completely depends on what kind of dithering you do — ordered dithering with a small color palette will give you a much smaller file size than a full color jpeg.
WebP and AVIF also support lossless compression and can be used for even smaller file sizes using dithering.
I suppose you can argue whether the JPEG artifacts look better or worse than the dithering, but WebP definitely looks better.
If you just want small images, a lossily compressed image will probably look better than a lossless dithered image
I would say at that point it's arguable which artifacts are preferable (compression or dithering), not compression being a clear winner.
Original 123k picture on top, 28k picture on bottom:
Maybe I'm just nit-picky, but I do quite clearly see greenish squares, especially on the forehead and nose area.
Probably not enough to catch my eye, but strong enough that looking at the picture for 5 seconds I would say "boy this was compressed way too much".
Modern compression algorithms with native lazy loading will probably offer the best of both worlds.
I happen to like the dithered look, but arguably it might not be the best way to save on bandwidth.
I really, really, dislike the modern flat colour designs of today. They make it much harder for me to separate out what I care about, like context and information, because my eyesight isn't perfect.
Gradients made it so much easier for me to see the difference between a tab and the bar it's sitting in. A little strip of colour or some shadowing, to denote the active tab just disappears for me.
(I'm sure there are even better examples of this "no gradients, but strong color contrast" effect among the various Linux Desktop Environment themes, but I'm not too familiar with them. Paging anyone from /r/unixporn.)
Give me contrast by using a mix of gradients and flat, any day.
I would note that Windows XP also had a high-contrast theme; and that, when enabled, inactive tabs actually lose the distinction in background color from active tabs. But they keep the highlight stripe.
To try and put it another way, imagine, for a moment, that you are incapable of perceiving edges. Every single one of your flat tabs now looks like the same part of the same blob.
Now, realise that for a pretty high number of low-vision people, that is reality. The slight blur we experience makes most edges disappear.
(WinXP's high contrast overcame this by tripling the size of all edges).
Switching tab is easy enough, by clicking the centre of its label. When you wish to switch tab, you generally are going to read the label.
But when working out where you are, that can be total guesswork.
A lot of UI design on computers of the era was flat colors, maybe with a mild gradient. Go look up screenshots from Windows 3.1. Everything is flat grey or white. Windows 9x wasn't really much better, except it had that ugly solid teal background.
Also, dithering on a CRT produced a very different effect from dithering on a high-res LCD.
And the "modern flat solid color designs" still use stuff like subtle shadows and transparencies that would have been either impossible or wouldn't have looked nice in the nineties...
I would be all for this, but I frequently find myself pinch-zooming into images on my phone to more closely examine the details in them. If the site assumed that I would only see what's visible in the image at the initially-rendered aspect ratio, then zooming would reveal nothing (e.g. text that's small and blurry, would just become large and blurry, rather than crisp.)
Ideally, a browser would be able to notice when you've zoomed into an image element past its Nyquist frequency, and async-load a higher-quality version of the image, swapping it out once the loading's complete. Do any browsers do this yet?
If you are coming up with a look for a site, dithering all the hero images, or running them through a cell-animation filter, or mosaicing them, or halftoning them, all are stylistic choices that might help your design stand out, and help reduce file size.
But… no, you probably shouldn’t just diffusion dither everything down to black and white.
First of all, no discussion of minimizing PNG sizes is complete without `pngcrush` which applies all kinds of optimizations to the PNG file (losslessly). In fact pngcrush reduces the author's 48kb dithered file down to 28kb.
And secondly, modern compression formats like webp and avif will blow PNG out of the water when compressing any kind of photographic image. Heck, just turn down your JPG quality, and your image will be much smaller, and still perfectly recognizable.
Know when to use the right tool for the job:
PNG -> diagrams, charts, anything with perfectly uniform areas of color and sharp transitions.
JPG/AVIF -> photos, anything with smooth variations in color.
Once computers got to the point where you could use any colour for any pixel it rightly died off, and its only use today is for things like e-ink displays or monochrome printing.
I couldn't tell that. I still can't tell that.
> dithering was a sub optimal solution to simulate more colours on old computers with limited colour palettes.
What is more optimal solution than dithering in that context?
Having hardware that lets you use whatever colour you want for any pixel.
"dithering was a sub optimal solution to simulate more colours on old computers with limited colour palettes."
perhaps what you actually meant is:
"dithering IS an optimal solution to simulate more colours on old computers with limited colour palettes."
Dithering isn't usually worth the reduction in quality. And ironically it can make things worse if you're not careful - dithering the image and saving it as JPEG actually INCREASED the size to 39K!
and on the command line, good ol' imagemagick comes through with something like
convert picture_with_cool_colors_you_like.png -colors 10 -unique-colors sourcecolormap.png
convert source.jpg -resize 500x500\> -ordered-dither o4x4 -remap sourcecolormap.png output.png
mutatis mutandis. :)
Given all the trade, commerce, learning, community, education, entertainment, and countless other benefits and multipliers the internet brings, I can't help but feel it's a fantastic return on its energy investment.
Here's the app: https://oaksnow.com/retrodither/
And here's my blog post talking about how I wrote it: https://www.observationalhazard.com/2021/09/building-retro-d...
Dithering is still commonplace, but mostly invisible, for high-end color. Photoshop quietly dithers by default when converting from 16 bits per channel to 8 bits, for example. This is important when sending 8 bits/channel images out for large-format printing because the invisible differences on screen can become clearly visible on paper - the monitor’s gamut and the printer’s gamut are surprisingly dissimilar. Dither is needed to keep smooth gradients from banding badly, and it sucks when you’re spending $100 per print or more to have nasty bands or even compression artifacts appear.
If you really want to save bandwidth, you’d be better off looking at better formats like AVIF, and WebP.
Those will shave off a lot of extra bits, especially AVIF, although that is not universally supported yet.
Combine that with making a the images a little smaller would save you a lot of bandwidth, without making your pictures look like they are 20 years old.
Use AVIF instead. An image in AVIF is half the size of an equivalent JPEG. Chrome already has it, and full Firefox support is imminent.
Also, better to compile from source. There are os packages, but they tend to be older versions of pngquant that have various issues.
this is an often-missed detail, unfortunately.
This means that the main meaningful way users will see the image is resized as a thumbnail, so before you start dithering, you should really test to see how the resized dithered image looks. Odds are good it will not look good.
1-bit DACs in CD players are the same idea: Trading higher sampling frequency for lower sample resolution to convey the same information.
Bresenham's algorithm is yet another expression of the same idea but there the samples in question represent the slopes of straight lines represented by pixels.
For example, my-dog-dithered.png which uses only black and white is stored as 4x8 bpp instead of 1bpp. Running it through optipng halves the size.
And probably 3 MB of JavaScript...
If you don't, but you want your webpages to load fast, look into WebP and AVIF images. Load them opportunistically using the html5 PICTURE tag - no JS required and no worry about old browsers not supporting new formats. Even plain lossless encoding of legacy formats goes a long way. Test your own site for ideas:
LOL What. Make it 10mb.
https://en.wikipedia.org/wiki/William_Howard_Taft#/media/Fil...
This is a fun stat, I wonder how much physical infrastructure is actually behind serving all the images vs videos / adtech.
I think we can pretty conclusively say that dithered PNG does not make sense from bandwidth point of view.
Depends on a lot of factors. You can keep turning the quality down on avif and get it lower than a dithered image. At some point I'd prefer the crispness of a dithered image over a blurry full color image.
Also, avif seems to do a really good job of lossy compression on dithered images.
This GDC presentation, featuring Mark Ferrari, shows how it's done: https://www.youtube.com/watch?v=ri4_3P2Oh14
This is literally moving backwards.
Here's his dog picture encoded to webp using default settings (11KB): https://image.non.io/dog.webp
This is smaller than all but his two color and his four color examples, at a tremendously higher fidelity. Just for comparison:
webp vs original @ 11KB: 2.1% difference from source image.
gameboy vs original @ 8KB: 18.2% difference from source image.
4 color vs original @ 9KB: 15.2% difference from source image.
Even if you compress the webp down to 8KB, you only encounter a 3.3% difference from the original.
TL;DR - use modern image formats. Don't use dithering for compression.