Grayscale on 1-bit LCDs (2022)

I think this is one of the better, well my dad can beat up your dad type of stories. I know you absolutely didn't mean it that way, but there's a part of me that read it that on the second reading of it.

Oh yeah, well my dad...! kind of thing =)

Your father invented the Bayer filter. HN never ceases to amaze me :)

Kudos to your dad! Every time I explain how a digital camera works to people, invariably it's the concept and application of the Bayer filter that causes their jaw to drop.

Most people think 50 megapixels = 50 red, 50 blue, and 50 green megapixels, so it's quite eye-opening. That our eyes work similarly with cones tuned to specific frequencies is just icing on the cake after that.

To add to the above, an alternative dithering approach is error diffusion, e.g.:

https://en.wikipedia.org/wiki/Floyd–Steinberg_dithering

The article mentions also doing this in the temporal domain.

Wow! I worked on digital camera chips and had coworkers writing demosaic algorithms. We wouldn't have even had those jobs if it wasn't for your father.

Must be such a good feeling to have this legacy. Your father did great!

This reminds of this great article about creating a modern ordered dithering algorithm, and its effect on animations: https://bisqwit.iki.fi/story/howto/dither/jy/

I really hope your childhood home had a stained glass window with a Bayer pattern!

Wow, I deeply remember seeing these patterns in my relatively early computing days. I think it primarily was in Windows 3.x, back when graphics modes with 16 colors were still normal.

It definitely was not Floyd-Steinberg or anything else using error diffusion (which however I also remember seeing in those days, from some Windows applications' splash dialog for example), because there were these very characteristic stable patterns.

During countless hours staring at the dithered blue gradient of InstallShield, for example.

I recall graphics programming books in the mid/late 90's about dithering techniques.

There's also some fun related work on ASCII art rendering.

This sort of thing is/will still be useful for low-cost displays. I'm sure we'll have Wifi-enabled e-ink displays on cereal boxes soon.

Seeing that brings back a lot of nostalgia for the old PC Paintbrush that was once ubiquitous on DOS machines. The images it turned out were really great for the time, and I sometimes miss the aesthetic of those dithering patterns.

Ordered dithering is great. I use it in my video player, it looks good and is a fast alternative to error diffusion which requires more hardware resources.

Haha, thanks for dredging this up, I made that :) It seems quite related to the OP article. It's a library for making grayscale games on the TI83 graphical calculator, which has a monochrome display. The main challenge was optimizing the interrupt routine, the z80 assembly code that performed the flickering/dithering that achieves the grayscale effect, to fit within the tiny amount of clock cycles available on the Zilog Z80 6 MHz processor. Even after optimization, it took up ~50%-75% of all available cycles. Some people managed to make some pretty fun grayscale games with it (e.g. https://www.ticalc.org/archives/files/fileinfo/331/33153.htm...). This was obviously in the pre-smartphone era, so the ti83 was quite popular for playing games in class, and hand written assembly code was the only way to make it fast.

Not that anyone hadn't thought of it before, but I believe that I may hold the first claim of a grayscale TI calculator demo. I released a four-frame, 4-bit grayscale animation of beavis & butthead headbanging for the newly minted Zshell on TI-85 in 1992. I posted it to one of the listserves or usenet groups, but I have never been able to find a copy in anyone's archives. I'd love to see it again. It was not a fancy program. The frames were stored as 4 x 4 x 64x128 bitmaps = 16KB so it consumed like 2/3 of the calculator's memory. Fun times.

If anyone is a usenet archive ninja, my program was called 'BBANIM' and there was a TI-basic POC and zshell asm version released.

I recall that the first game using PoV grayscale was "Plain Jump" (sic) shortly afterwards which apparently continues to be a popular project to clone.

FWIW, as someone who doesn’t really know anything about LCDs but has messed around with circuits and LEDs, the digression into PWM bridged the gap nicely for me at least. It probably wasn’t necessary from a technical point of view but it helped tell the story.

PWM still has its place - it's not uncommon for high-end sigma deltas to have a multi-bit rather than one-bit output, which feeds into a PWM final output stage. It helps with numerical stability. I've used a similar technique to improve the audio output in FPGA projects where a simple 1st order SD feeds a 5-bit PWM. On the boards in question the output drivers seem to be somewhat asymmetric, making an SD quite noisy at higher clock frequencies. With the PWM final output stage the same effect manifests as a DC offset instead, since (when not saturated) the PWM has a fixed number of rising and falling edges in a given time period.

He's also the guy who pushed an eink display to 5bpp: https://news.ycombinator.com/item?id=16140284

> LED where controlling current is not feasible

Voltage-controlled current source is a pretty basic OpAmp circuit actually. There's also some tricks to turn some common voltage regulators into current controls. If your "information" is already encoded as current, you can somewhat current-mirror with a very basic BJT circuit (its not the best circuit, but if you don't care about accuracy its fine).

I'd say that current control is _more expensive_ than PWM though. PWM is just software or a 555 timer if you're oldschool, both are cheaper than OpAmps / Voltage Regulators.

Or maybe you mean, "not feasible for the costs people expect", which is probably true. PWM is just so much cheaper in practice.

The last time I coded something along these lines was way back in the day for pulsing the Amiga's power/disk drive LEDs in time to music and sound effects, instead of their usual on/off/half brightness states. Not quite so useful, but I remember having fun coding it :D I was surprised at just how effective it was, without any noticeable flicker.

Even modern color LCD's on laptops and stuff implement many of these tricks.

Yep! I remember doing this on the HP 48G's in the mid-90's: https://www.hpcalc.org/hp48/graphics/grayscale/

The computational and engineering effort for these hacks to get to those results in production would have made those price sensitive consumer gadgets far more expensive. It just wasn't economically feasible.

Also, if I'm not mistaken, those hacks look good on static images but could produce nasty artifacts on moving images.

TI-83+ calculators were doing grayscale like this 20 years ago, so a lot of people did have this as kids. It was a bit flickery but worked well.

They actually gave an example that was, the Gameboy. I think in that case the big issue for going beyond just 4 gray levels is RAM and ROM space, and also potentially the speed of the PPU and display driver in dealing with the extra data.

We were! When I was a kid 28 years ago I had an HP48 calculator that people used the same techniques with for some games and such.

There's a ton of monochrome screens available to EEs under $20, even under $10.

This is still quite relevant.

I thank the reader mode of my browser in case like this.

It makes more sense in video: https://www.youtube.com/watch?v=n7uxEaGB9t0

I can't swear that nobody ever tried it, but such a demo would have been very impressive, and I can't imagine how it could have been done. Those original black-and-white Macintoshes had an 8 MHz processor, and the screen was 512x342 pixels; just performing a single cycle's worth of computation per pixel would limit you to 45 Hz. Even if you could somehow miraculously perform dithering in a single instruction per pixel, you'd have no CPU left to run the animation or do anything else.

Would it have provided any benefit? CRTs have continuously variable brightness. The bottleneck was having large enough video RAM to even store the higher pixel depth, the processing power to draw it, and the bandwidth to do the output.

Circuitry to convert a multi-bit value to a voltage doesn't seem to have been cost prohibitive. Even cheap devices (the predate the Mac) like the Atari 2600 could do that.

I'm actually not sure why they went 1-bit with the Mac. Maybe they felt having more pixels was so important that going monochrome was a reasonable trade-off.

The original NeXT had 2-bit greyscale (black, white, 2 shades of gray), and that looked pretty nice. It also had lots of pixels and was way more expensive.