Websites should not use dithered images(simplethread.com) |
Websites should not use dithered images(simplethread.com) |
I recall dithering being heavily used in the days of very finite color palettes - BMP, GIF16 etc..
To make the argument that WebP is better than dithering, the author should compare the 30 kB dithered image to a 30 kB WebP. Or even compare to a smaller WebP that lacks obvious compression artifacts.
In the comparison as given, I would not say that the WebP is a better image.
Dithering has it's own aesthetic, and if that's what you want, then by all means, dither away.
But to say that dithered image is a better representation of the original than that webp seems way, way off base to me.
rgb: 75kb
indexed: 35kb
So indexing does look like it could save a lot. I do wonder if it can still beat out say jpeg or webp though.
In the case of images, it makes color-reduced versions not look terrible.
Adding noise is almost always a bad thing for compression. The undithered images would compress much better.
I honestly doubt that a lot of people who go to lengths to unearth Atkinson dithering these days don't aim for that, though.
Most likely, you shouldn't use images in the first place.
Think of it this way. You start out with a series of numbers between 0 and 100. Your job is to represent this series as best as possible within a range of just 0 to 10. Without dither, you would just round each original number to its closest multiple of 10; all your 31's become 3 and all your 34's become 3. With dither, nearly all of your 31's become 3 and many of your 34's become 3 but nearly half of them become 4.
Without dither: 31, 31, 34, 34 becomes 3 3 3 3.
With dither: 31, 31, 34, 34 might become 3 3 3 4 on a typical run.
You absolutely cannot calculate 3 3 3 4 based on 3 3 3 3. You need the original full set of information in order to calculate 3 3 3 4.
Now add on the fact that it's not just random noise that makes this work. Neighboring pixels influence whether to round up or round down. You want that influence to come from original high-depth data, not already-rounded data.
Dithering is a technique which allows you to represent a color image with a very limited palette, in particular a two bit palette. The result is not much like a normal photo, but much better than nothing if you have a machine that can only output a few colors. (You could think of that as a sort of compression where the goal is not to reduce file size, but to reduce the number of colors needed to comprehend the image.)
JPG, WebP etc. are compression techniques designed to reduce the size of a full color images, especially photos. Because they’re specifically designed for photos, they don’t work as well on things that aren’t “photo like.”
Dithered images are very much not like real photos, so it’s not surprising that compression techniques designed for photos don’t work well on dithered images.
(I’m not an expert on image compression, but as an example, I believe JPEG and similar algorithms expect to find large blocks of basically the same color in photos - such as a blue sky - and save space by simplifying that to a few big regions of all one color. The “speckled” appearance caused by dithering actively defeats that particular optimization.)
To be way more pedantic, dithering is a technique to reduce the quantization error (what happens when you map values from a big, possibly infinite set to a smaller, finite set). This is done whenever a system or algorithm converts data from higher dynamic range representation (more bits per quantum of signal, like a pixel or audio sample) to a lower dynamic range representation, it's called a bit-depth reduction.
And like you alluded to, every compression algorithm that might find it worth it to do this will do it internally. However the benefits are great, since lowering the bit depth has pretty awful results on quality.
Bit-depth reduction is used in practice in a few places, I'm not well versed in image compression but you do see it in telephony.
You are mixing two things here? Bit depth reduction is a specific term, it refers to the reduction in the amount of information you want to _convey_.
Compression is be reducing the number of bits/pixel averaged across the whole image. Good compression algorithms will not be spatially uniform, it's entirely possible that pixels in some parts of the image are compressed with more bits/pixel than pixels in other parts.
As I understand it, JPEG compression does not play nice with dithering as it is based on a matrix of discrete cosine transformations. Smooth transitions from one color to the next are much easier to compress this way than highly detailed features (i.e. a series of small dots due to dithering). For example, if you blur out parts of a photo, you will likely get a smaller image at the same compression level as the original. In other words, dithering basically creates a much harder image for the JPEG algorithm to compress.
JPEG, WebP, and AVIF use various frequency-domain transforms. These work best for smooth color transitions, like in photos. They're generally terrible for sharp edges (as found on screenshots), and especially so when many neighboring pixels have drastically different colors.
Even then that's a bit more complicated because both formats will apply LZ compression (respectively LZW and LZ77 because DEFLATE), so depending on the original source the dithering can work against the compression.
In a purely mathematical sense, though, quantization is very much a form of compression. It's a way of reducing the amount of information in the image. https://twitter.com/gabrielpeyre/status/1326776195107713026?...
Audio CD players use Sigma-Delta modulation (also called "1-bit D/A converters") which is essentially just dithering in one dimension. But CDs don't contain fewer bits because of this.
[0]https://bartwronski.com/2016/10/30/dithering-part-three-real...
[1] https://www.iryoku.com/next-generation-post-processing-in-ca...
Ordered dithering with a compression algorithm that can compress "words" (repeated patterns) (like the LZW in GIF) will perform better if the image has large areas of flat colour (not photos).
Literal X, literal Y, literal Z, copy distance=3 length=N
If it's okay with you I'll update the original with a link to this at the top. It's sort of hilarious that I made an whole app based on a premise that is basically just wrong.
I wish I could say I've learned my lesson, but I'll probably continue to make enjoyable mistakes like this for the rest of my life.
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
I don't know what's going on with their dithered image sample:
https://3otebq2knmnf3smsj0374a9u-wpengine.netdna-ssl.com/wp-...
This is the same dithered image with a sane 16 color palette:
https://www.marginalia.nu/color-simple_500-better-palette.pn...
Further, human eyes are kind of bad at blue colors, so whatever compression artifacts you get with JPEG or WebP is going to be really hard to detect. (The blue channel is typically compressed much harder by many algorithms because of this).
That said just pulling out a good lossy encoder makes a lot more sense most of the time. It is easier and it will look better. Dithering is lossy anyway.
It's like confounding stenography with cryptography. In a way, both are used to "hide" a message, but they are completely different beasts.
For instance somebody might have a HiDPI or Retina screen or they might be zoomed in or out on a particular web page. Or for that matter maybe you want to scale the size of the image so it fills the screen horizontally or vertically.
The scaling algorithm might maintain the the dither or it might smooth and blend it. Maybe it looks OK in the end but I wouldn't take for granted what happens.
When I zoom in and out on that page some of the images like the greek guy do OK consistently, but the dither takes on an unpleasant structure at certain sizes of the ocean image.
For some game series (say Hyperdimension Neptunia) fan art captures the essence of art in the game but for the big Nintendo games on the 3DS (say Fire Emblem Fates) fan art doesn't look like the game art at all because the game art is calibrated to the characteristics of the display in every way.
I will admit I'm surprised by the results. I assume there's not really a rendering perf hit from WebP vs jpg?
Also, the preposition that lowering the file-size, and therefore transfer time, is the most important factor in environmental impact is, I think, a little under-supported.
That being said, the original Low Tech Magazine article's perf claim is back up from the data, but they also use very low resolution images.
I'd be curious if dithering could be optimized to a particular algorithm. For example, jpeg's quantization is based on the assumption that images are mostly made of low frequency data and higher frequency can be removed without changing the quality of the over all image too much. With dithering, this is almost the exact opposite and all low frequency information is replaced with high frequency information, meaning it won't be nearly as effective.
"""Compressed through this dithering plugin, images featured in the articles add much less load to the content: compared to the old website, the images are roughly ten times less resource-intensive."""
There's an assertion which implies data, but no data.
But accepting that there was SOME comparison to specifically their "old" image method, the takeaway could be "re-evaluate your optimizations"
Another take with low-tech mag is an aim of describing and utilizing old techniques that did the job just fine (a sentiment I take from a lot of their articles). So, using the latest compression algorithm literally doesn't tick as many of their boxes as dithering.
before: https://krisdedecker.typepad.com/.a/6a00e0099229e88833022ad3...
after: https://krisdedecker.typepad.com/.a/6a00e0099229e88833022ad3...
First, it’s a response to two other articles and does not refer to the images in those articles or the processing techniques used on them, instead grabbing four other images and transforming them, perhaps in the same way as the original article, perhaps not. From this it draws broad conclusions. As the joke goes, at least one side of the sheep appears black from here.
The second is that there is a source of truth for these claims, and it’s in the algorithms and file formats in question. A JPEG image is generated and compressed a certain way, a PNG is encoded in a certain way. There is an actual answer to the question of whether or not dithering saves space and under what circumstances, and it has to do with how the images are encoded and compressed. If one does not want to bother learning enough about the algorithms in question, at the least one could approximate that knowledge by processing a statistically significant number of images and evaluating the results to get some kind of actual data on when and where the technique generates larger or smaller file sizes.
Instead, we’ve now got three articles, two of which say “this works” and one of which says “no it doesn’t” with all the rigor of 18th century naturalists puzzling over the behavior of birds.
1) author starts with lossy format at the beginning of the comparison
2) author uses squoosh app for some of his conversions, but not others, even though it supports dithering too - instead uses a random web tool which doesn't care about file size at all
3) not even a mention about image formats supporting limited color palettes
4) no mention of disadvantages of webp and avif (anyone still supports IE 11?)
5) more things like dithered "lossless" webp made from lossy jpg, from the same image you can see that author used much bigger color palette than the one used in Low-tech Magazine images
Funny thing is that aside of browser support modern formats would probably still win even without manipulating the numbers (they are made for this), but I guess the author wanted really convincing victory.
You missed that this is a rebuttal to an article that suggests using dithering and to use that specific tool. Hardly "random".
> anyone still supports IE 11?
Fair enough for now, but MS itself is in the process of dropping support for IE 11, so I don't expect others to carry on without them very widely. It will be all retro sites and corporate sites soon (LOL, for completely different reasons -- one wants to visit the past from time-to-time, and the other doesn't know how to escape it)
Usage of IE 11 and other browsers which do not support even webp (old safaris) is higher than usage of screen readers.
Personally I doubt we'll ever experience widespread usage of avif, considering how long it took Apple with webp, we'll probably sooner have jpeg xl.
If you're dithering, you want a lossless format that can used indexed colors. Webp also does better in this if you keep it in lossless mode. My last 16-color simple example goes down to 128K when converted to a lossless indexed webp.
I don't think this article does all the sufficient legwork to come to the conclusion it does. I agree that dithering isn't a be-all or end-all compression technique, but it's not as useless as the article makes it seem.
This feels like a bit of a strawman argument.
Some people here weren't web developers in the 90s and it shows :)
I don't even remember the last time I saw a dithered image anywhere on the internet.... it's been quite some time.
Dithering was used to make GIFs smaller, since the reduced palette could fit into a smaller bit depth per pixel. So in that sense it is a type of compression. This was useful and used even when 24-bit colour displays became common.
The issue of 256 colour palette display modes is separate and caused other problems - i.e. you might specify one palette of 16 colours in your GIF, but they might not exactly match the colours provided by the operating system.
That is where the (I imagine now long forgotten...) notion of a "web safe" colour palette came from - these were the 216 colours you could expect any 256 colour OS to provide (produced by dividing up the colour space evenly using only combinations of 00 33 66 99 CC FF values for R, G, B)
You could use colours outside the safe palette in your GIF but the OS would use the nearest available colour from its own palette to display them, and often it did a bad/unpredictable job of choosing a substitute. So it was common to deliberately adjust colours in your image to align with the "web safe" palette, so as not to risk garish substitutions when displayed on a 256 colour display.
It was image compression. You "reduce" the file size of the images by using an algorithmic approach to reduce the color palette, while achieving as much as the OG image quality as possible.
OK, not traumatizing, but I don't think they look good, particularly when the rationale for using them is bandwidth reduction.
So 8-bit palettized PNG sprite sheets are the most convenient way to do it in the browser, where it's not efficient to manually unpack some custom format.
I highly recommend pngquant tool with its adaptive dithering algorithm for compressing sprite sheets. One of main features is it uses partial transparency colors in a palette, while few other tools I tried just support on/off transparency, which is far from great. Especially for antialiased semitransparent edges. pngquant works beautifully with these cases.
Dithered images and websites (2020) - https://news.ycombinator.com/item?id=28696014 - Sept 2021 (121 comments)
my 2p
> reducing file sizes in a stylized way.
I don't think we ever stop and actually consider what creative avenues are open to us in that regard.
It's sort of like how there are technically better methods of printing than risograph, but sometimes that's what you really want and it's still fun to mess with.
However I would have shown how you could significantly reduce file size simply using optimized JPEG settings, as JPEGs are most widely supported and can achieve good compression rates too.
You're already a SSG PWA with modular js and a stylesheet devoid of unused selectors.
You've got almost all the unlocks. How much longer do you really want to be playing this game?
Images on a webpage will be scaled to devicePixelRatio. Common devices have non integer devicePixelRatios so dithered images are going to fail
Why would anyone even consider color dithering these days when it comes to the Web? It feels counterproductive even intuitively.
“The best thing for being sad," replied Merlin, beginning to puff and blow, "is to learn something. That's the only thing that never fails. You may grow old and trembling in your anatomies, you may lie awake at night listening to the disorder of your veins, you may miss your only love, you may see the world about you devastated by evil lunatics, or know your honour trampled in the sewers of baser minds. There is only one thing for it then — to learn. Learn why the world wags and what wags it. That is the only thing which the mind can never exhaust, never alienate, never be tortured by, never fear or distrust, and never dream of regretting. Learning is the only thing for you. Look what a lot of things there are to learn.”
T.H. White, The Once and Future King via MerlinDithering allows you to display images with a limited color palette, thus reducing the file size.
However the image formats chosen here don't really benefit from that.
Dithering is particularly effective in bitmap formats that use a palette (GIF, for instance). Just make sure your gif is actually saved with less bits-per-pixel than your original image.
It's however true that these formats that benefit aren't exactly modern, and there would be better ways of saving the same image.
At the end of the day, dithering can still be aesthetically pleasing. There might yet be a use for your app.
I think that sentence is misleading and is what caused the initial misconception.
Reducing the color palette is a technique for reducing file size. For example, say you have a grayscale image using 8 bits per pixel (256 colors). Ignoring other compression techniques, you can cut the size of the image in half by reducing it 4 bits per pixel (16 colors).
The naïve way to reduce bit depth is by discarding the low order bits, since they carry the least information. However, when you do that, the result is banding [1]. Banding is an unsightly artifact.
Dithering exists essentially to deal with banding. It works by (sort of) adding a slight amount of noise to the pixel values to diffuse the transitions between diffferent thresholds.
But anyone with an ounce of information theory will tell you that noise by definition is literally the hardest thing to compress. So when you dither an image, you are throwing away almost all of the gains you got by reducing the bit depth in the first place.
There's really no better way to learn, in my experience.
(Interesting choice of username!)
I think the real value is that it presents a novel idea of considering image compression creatively.
That is the reason why Web Development keep reinventing the flat tire.
You load them conditionally based on browser capability or user-agent
It was BMP that used RLE wasn't it?
https://www.lowtechmagazine.com/2018/09/how-to-build-a-lowte...
They do use dithering with JPGs and PNGs on their "solar-powered website" variant, which I won't link-to so as not to contribute to draining the battery with an HN effect.
The first image I found to compare from the two versions of their own website... the dithered version is 65K and the original is an incredible 6.2MB... but that's at least in part because the original is 5053x3581 pixels and the dithered is 1213x600! First picture at https://www.lowtechmagazine.com/2021/11/fascine-mattresses-b... is the "non-dithered" variant. There may be other compression mis-choices on the original JPEG as well. To suggest this size difference is due to dithering would be misleading!
Size and compress your images properly (including JPG lossy compression) to save energy resources is good advice; I think the OP is probably right that dithering is not a very useful tool in that toolkit.
It makes me lose some respect for lowtechmagazine, when they go for more style over substance in this particular case, it makes me wonder in others.
In other words, they get to 1% of the filesize by reducing the number of pixels to 2.5% of the original count. Once you've done that, you can get a better looking image by using Squoosh than by dithering.
https://imgur.com/a/9bGGA4j shows a comparison of the original, my squooshed version resized to the same dimensions they used (at only 41 thousand bytes), and their 65 thousand byte dithered and resized version.
Their version, 160% the filesize of mine, is much worse, obliterating detail of the clouds, for example, and also being ugly. Unless deliberate dithered ugliness is your stylistic choice, you should not be dithering unpaletted filetypes like jpegs. I'm not saying my version is perfect; I would never compress a jpeg so heavily that the block pattern shows (as it does in the upper left clouds), but where that is apparent my competition had simply deleted that information completely.
> There may be other compression mis-choices on the original JPEG as well.
You bet. I also include a highly compressed version of the original image, which comes in at only 394 thousand bytes, not 6176 thousand like their totally unoptimized one, which is a 94% savings all in itself. I chose to compress to the point that the detail of the men on the large barge mass was without apparently loss of quality. Again, this results in visible compression artifacts in low-contrast areas of the image, like the water surface and clouds. From my experimenting, settling for a 1500 thousand byte image results in a dssim score of very nearly zero and would be what I would consider properly optimized, at a 75% savings.
Mpqzcp nzxxpyetyr htes pxzetzylwwj-nslcrpo nzxxpyed, dpp tq jzfc nzxxpye xlvpd dpydp ty esp nzyepie zq esp lcetnwp lyo yze ufde esp etewp. Nzxxpyetyr hteszfe vyzhtyr esp nzyepie xlvpd jzf wzzv (opdpcgtyrwj) defato.
... Wait, this is what JPEG is, isn’t it? Why aren’t there dithering decoders for it, in this case? Is the block too small?
[EDIT] To clarify, this is relevant to cutting bytes because encoding graphics with SVG or drawing them with CSS can mean shipping fewer bytes than JPGs or whatever.
(so this a bit of a rant I have about people calling deflate a compression algorithm, its an algorithm composed of two other fundamental ones).
The optimal parse here isn't always to pick the greediest match from the LZ77 perspective and then "run it through Huffman", you have to know the Huffman cost model when picking your LZ77 matches.
edit: Just as a note, actually doing it as two distinct passes rather than at the same time would be silly since its going to significantly slow it down. So just because its doing the entire thing as a single "pass" doesn't count IMHO.
<picture>
<source srcset="image.webp" type="image/webp" />
<img src="image.jpg">
</picture>
Unless rescaling an image itself is already too much work, in which case this has nothing to do with image formats or plain HTML sites in the first place.
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.