We've had a couple of other recent discussions on dithering: https://news.ycombinator.com/item?id=45750954 https://news.ycombinator.com/item?id=45750954 and htt

We've had a couple of other recent discussions on dithering: https://news.ycombinator.com/item?id=45750954 https://news.ycombinator.com/item?id=45750954 and https://news.ycombinator.com/item?id=45698323 https://news.ycombinator.com/item?id=45698323. I commented specifically about the history of blue-noise dithering at https://news.ycombinator.com/item?id=45728231 https://news.ycombinator.com/item?id=45728231. The article points out that, historically, RAM limitations were a major incentive for dithering on computer hardware. (It's the reason Heckbert discussed in his dissertation, too.) Palettizing your framebuffer is clearly one solution to this problem, but I wonder if chroma subsampling hardware might have been a better idea? The ZX Spectrum did something vaguely like this: the screen was 256×192 pixels, and you could set the pixels independently to foreground and background colors, but the colors were provided by "attribute bytes" which each provided the color pairs for an 8×8 region http://www.breakintoprogram.co.uk/hardware/computers/zx-spectrum/screen-memory-layout http://www.breakintoprogram.co.uk/hardware/computers/zx-spec.... This gave you a pretty decent simulation of a 16-color gaming experience while using only 1.125 bits per pixel instead of the 4 you would need on an EGA. So you got a near-EGA-color experience on half the RAM budget of a CGA, and you could move things around the screen much faster than on even the CGA. (The EGA, however, had a customizable palette, so the ZX Spectrum game colors tend to be a lot more garish. The EGA also had 4.6× as many pixels.) Occasionally in ZX Spectrum game videos like https://www.youtube.com/watch?v=Nx_RJLpWu98 https://www.youtube.com/watch?v=Nx_RJLpWu98 you will see color-bleeding artifacts where two sprites overlap or a sprite crosses a boundary between two background colors. For applications like CAD the problem would have been significantly worse, and for reproducing photos it would have been awful. The Nintendo did something similar, but I think had four colors per tile instead of two. So, suppose it was 01987 and your hardware budget permitted 8 bits per pixel. The common approach at the time was to set a palette and dither to it. But suppose that, instead, you statically allocated five of those bits to brightness (a Y channel providing 32 levels of grayscale before dithering) and the other three to a 4:2:0 subsampled chroma (https://www.rtings.com/tv/learn/chroma-subsampling https://www.rtings.com/tv/learn/chroma-subsampling has nice illustrations). Each 2×2 4-pixel block on the display would have one sample of chroma, which could be a 12-bit sample: 6 bits of U and 6 bits of V. Moreover, you can interpolate the U and V values from one 2×2 block to the next. As long as you're careful to avoid drawing text on backgrounds that differ only in chroma (as in the examples in that web page) you'd get full resolution for antialiased text and near-photo-quality images. That wouldn't liberate you completely from the need for dithering, but I think you could have produced much higher quality images that way than we in fact did with MCGA and VGA GIFs.