Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Websites should not use dithered images

simplethread.com

Post reply on HN
Print view View original

81–90 of 133 posts

Re: Websites should not use dithered images

#81

Post by StillBored »

Jasper_ wrote: post #64
StillBored wrote: post #57

Earlier quoted context omitted.

Was going to say, this but tiny correction, its the LZ variant that does this, as will most of them. Deflate is just two pass compression of LZSS followed by Huffman. The LZ variant will pick out repeat patterns, while the second will compress the byte representation of the resulting stream if a particular set of values is over represented. AKA its all variations of X, Y, Z in different orders those might get assigne…

What a weird take. Have you written a deflate/inflate implementation? Deflate really isn't just LZSS (I assume you mean something like Haruhiko Okumura's LZSS?), followed by Huffman, it's a very intertwined and sophisticated combination of LZ77 and Huffman. How the two work together is integral to why Deflate works as well as it does. The optimal parse here isn't always to pick the greediest match from the LZ77 persp…

I wrote a zip decompressor many years ago, the compression side wasn't really much of a target, because the focus was on compressing with a more speed focused algorithm. At the time it was a pretty distinct portion of my decompression pass. I didn't know they were picking matches based on the compressed size vs just longest match, but I guess it makes sense, but I don't see why that "intertwines" it anymore than any other adjustment one makes to how one finds matches (which is AFAIK generally the largest change in all the LZ variations).

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.

Re: Websites should not use dithered images

#83

Post by asxd »

jschwartzi wrote: post #15
burlesona wrote: post #12

The idea that dithering should be used to reduce your image size is a misunderstanding of image compression. 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…

you might get better results with a run-length encoding on a dithered image. I’m not aware of any modern image formats that use RLE though.

Maybe just encode it as a bitmap, and then use other types of compression like RLE. Dithering reduces the color palette, so in combination with a bitmap it would reduce the memory footprint of each pixel.

Re: Websites should not use dithered images

#84

Post by gfxgirl »

Based on the comments and not reading the article everyone seems to have missed the more important point.

Images on a webpage will be scaled to devicePixelRatio. Common devices have non integer devicePixelRatios so dithered images are going to fail

Re: Websites should not use dithered images

#85

Post by perth »

Sometimes dithering is the right option depending on your use case. If it’s purely getting the smallest size, for example, go into Adobe Photoshop “save for web” and mess around with the various algorithms, formats, and dithering settings. Photoshop has a live preview with live updating file size. I’ve always found limited palette pngs and gifs with dithering tended to be the smallest. It also depends on the contents of your image and all of that. And there are many cases for complex images where a jpeg will be able to represent the image at a smaller size with greater clarity.

Re: Websites should not use dithered images

#86

Post by coding123 »

jschwartzi wrote: post #15
burlesona wrote: post #12

The idea that dithering should be used to reduce your image size is a misunderstanding of image compression. 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…

you might get better results with a run-length encoding on a dithered image. I’m not aware of any modern image formats that use RLE though.

PCX was RLE. I remember playing with PCX files in C++ back in the day.

Re: Websites should not use dithered images

#87

Post by Igelau »

I felt like the real point of Nathaniel's dithering article was pointed out early:

> 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.

Re: Websites should not use dithered images

#88

Post by hunter2_ »

rjmunro wrote: post #28
magicalhippo wrote: post #13

Earlier quoted context omitted.

Dithering isn't a compression algorithm[1]. It's an algorithm that adds noise to effectively increase bitdepth when downsampling. 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. [1]: https://en.wikipedia.org/wiki/Dither

If added noise is the aesthetic effect you are going for, it's probably better to ship a low quality (<50) JPEG of the original image and add the "dithering" in the client by overlaying noise there.

You can't add the noise after quantization, it needs to be done at the same time as quantization, because otherwise you are losing the information needed to intelligently feather the edges.

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.

Re: Websites should not use dithered images

#89

Post by dinkelberg »

Thank you, I was thinking of doing a write up on this topic as well after reading the article "How to build a low tech website" which recently floated on HN.

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.

Re: Websites should not use dithered images

#90

Post by tofof »

jrochkind1 wrote: post #31
tomlin wrote: post #25

I don't get this article. Dithering is generally for limited palettes. JPG, PNG do not have limited palettes. This feels like a strawman.

As the OP says, but maybe not clearly enough, it's a response made to these claims/suggestions by lowtechmagazine.com: 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…

I find the original 5053x3581 image to be 5.88 MbB (6176 thousand bytes). The dithered 63.3 KB (65 thousand bytes) image is actually natively only 800x567 pixels.

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.

Post reply on HN