Dithering is something of a lost art now that our displays can handle millions of colors in high definition, but it can be a striking artistic effect.<p>If anyone thinks their websites are too colorful, I made a pure JavaScript web component to dither images on client in real time, taking into account the real pixel size of the current display.<p><a href="https://sheep.horse/2023/1/improved_web_component_for_pixel-accurate_atkinson.html" rel="nofollow">https://sheep.horse/2023/1/improved_web_component_for_pixel-...</a>
They may not want to imply that didder's linearized rabbit is wrong, but I'm comfortable saying so. It's not just a little dark, it's way dark, to the point of hiding detail.<p>The linearized RGB palette is similarly awful. It clobbers a whole swath of colors, rendering them as nearly black. Purples are particularly brutalized. Yellows disappeared and became white.<p>On my phone, the middle palette doesn't appear too bright to my eyes, either.<p>Even the linearized gradient looks worse, .<p>Maybe linear is not best for perceptual accuracy.
It might be worth using a lightness estimate like OKLab, OKLrab[1], or CIE Lab instead of the RGB luminance weighting, as it should produce a more perceptually accurate result.<p>The other issue with your code right now, is that it is using euclidean distance in RGB space to choose the nearest color, but it would be probably also more accurate to use a perceptual color difference metric, a very simple choice is euclidean distance on OKLab colors.<p>I think dithering is a pretty interesting area of exploration, especially as a lot of the popular dithering algorithms are quite old and optimized for ancient compute requirements. It would be nice to see some dithering that isn't using 8-bits for errors, is based on perceptual accuracy, and perhaps uses something like a neural net to diffuse things in the best way possible.<p>[1] <a href="https://bottosson.github.io/posts/colorpicker/" rel="nofollow">https://bottosson.github.io/posts/colorpicker/</a>
Did the author forget to finish the blog post?<p>They show a single example of incorrect dithering, explain it's wrong, and then don't show a corrected version. There isn't a <i>single</i> example of proper color dithering.<p>And they talk about the distance to the nearest color (RGB) but don't explain how to account for black or white -- how to trade off between accuracy of hue, brightness, and saturation, for example.<p>This post doesn't explain at all how to actually dither in color. I don't understand why this is on the front page with over 50 votes.
> If the linearised version looks wrong to you, try opening it on a larger monitor in it’s original size and check your gamma settings.<p>It looks far too dark, and I’m viewing it on an iPad with a high DPI screen. I also strongly suspect I can’t change the gamma on this device, nor have I ever knowingly done so. Anyone know why it looks bad?
I've done this in the early '90s, when I implemented all published algorithms back then into a Turbo Pascal program, which was allowing me to see full-color images on poor post-Soviet color displays - it wasn't just doing dithering, but also allowing you to pan and zoom, while switching algorithms. Give the limitations of the hardware, I had to implement the algorithms with a running buffer, optimized for panning, i.e. incrementally dithering the image. As some could guess, not a small part of these images was erotic. The program also was able to print on a matrix printer and I was improving it and had some test printouts in my bag. As I was in high school back. At one point some kids put a classroom on fire and they were doing an investigation, so, at one point they asked me to open my school bag and show them the contents. And, yes, I got into a big, big trouble. It was really tough to provide a meaningful explanation that I had only limited set of true-color images and, of course, the most popular were erotic given the post-Soviet interest in erotica and pornography. So, every time when I read something about dithering here on HN, it brings back my memory of being taken to the police station by two cops in front of the entire school for "distributing pornographic materials".
When I saw this, I immediately had flashbacks to a little project I did for my CS course when I was an undergrad! We were all assigned a computer graphics algorithm and were tasked to build an animation explaining how it works.<p>This was nearly eight years ago, but I managed to find it this morning and uploaded it to YouTube.<p>Here was the resulting animation: <a href="https://youtu.be/FHrIQOWeerg" rel="nofollow">https://youtu.be/FHrIQOWeerg</a><p>I remember I used Processing to build it, and it took so long to animate as I had to export it frame-by-frame. Fun days!
> Dithering a black-to-white gradient will be wrong without linearising first.<p>TBH both look wrong to me. If I squint, neither dithering patterns match the original gradient... but the non-linearized one looks the most similar.<p>What could be causing this?
Didn't try error diffusion, but I had good results with Bayer for the ZX Spectrum Raytracer [0]. Bayer only ever looks at the pixel it's considering, doesn't do math beyond comparing a value to its threshold, it was surprisingly easy to implement, and looks nice. A great choice for ridiculously underpowered devices :)<p><a href="https://gabrielgambetta.com/zx-raytracer.html#fourth-iteration-light-just-the-one" rel="nofollow">https://gabrielgambetta.com/zx-raytracer.html#fourth-iterati...</a>
I've always been curious to what degree, if any, color constancy[1] affects color dithering.<p>Seems that at some level it should, though perhaps not directly at the pixel level due to the high frequency of the per-pixel differences, but maybe at the more coarse "averaged" level?<p>One of those things I've wanted to explore but remains on my to-do list...<p>[1]: <a href="https://en.wikipedia.org/wiki/Color_constancy" rel="nofollow">https://en.wikipedia.org/wiki/Color_constancy</a>
Error diffusion dithering is kind of old fashioned. It is a great algorithm where you only need to go though the image once, pixel by pixel. But it doesn't work well with todays hardware, especially GPUs. Would be fun to come up with new algorithms that are better parallelizable.
The dithering work Mark Ferrari did by hand on some of the old LucasFilm games was really impressive.<p><a href="https://www.superrune.com/tutorials/loom_ega.php" rel="nofollow">https://www.superrune.com/tutorials/loom_ega.php</a>
Might be relevant to your interests:<p><a href="https://nigeltao.github.io/blog/2022/gamma-aware-ordered-dithering.html" rel="nofollow">https://nigeltao.github.io/blog/2022/gamma-aware-ordered-dit...</a>
See also: "Joel Yliluoma's arbitrary-palette positional dithering algorithm"<p><a href="https://bisqwit.iki.fi/story/howto/dither/jy/" rel="nofollow">https://bisqwit.iki.fi/story/howto/dither/jy/</a><p>This page focuses on ordered dithering, which tend to work better for animations compared to error diffusion based dithering schemes (like the linked article).
I wonder what would happen if you 3D printed a dithering pattern, of either a picture or just some perlin noise, as a fuzzy skin.<p>It seems like it could have a really nice effect.
A fun website to try out different Dithering algorithms and settings.<p><a href="https://doodad.dev/dither-me-this/" rel="nofollow">https://doodad.dev/dither-me-this/</a>
See also FadeCandy by Micah:<p><a href="https://scanlime.org/2013/11/fadecandy-easier-tastier-and-more-creative-led-art/" rel="nofollow">https://scanlime.org/2013/11/fadecandy-easier-tastier-and-mo...</a><p>> Firmware that uses unique dithering and color correction algorithms to raise the bar for quality while getting out of the way of your creativity.