How deep are you in the ESP32 dev? I've found image rendering (the display is LCD, not eInk) to be less straightforward than anticipated.

In my case, massaging images into a specific size and format prior to sending them into the ESP32/Display is easier and more reliable than trying to have the ESP libraries display any arbitrary image.

I haven’t actually started coding yet with the ESP chip. In my case the aim is to pick up a preformatted image from an URL, avoiding all of the finicky formatting you describe. I like the idea of the screen controller as a single function machine just for display, with the backend being a simple GitHub repo connected to Cloud Run via CI/CD.

What hardware are you using? I recently finished a project myself and I'd like to do more with e-ink but the hardware "driver" that plugs into the pi costs as much as the e-ink display.

Yes, it can get pricey. I'm using a Raspberry Pi Zero W with a Waveshare 7.5 e-ink panel, which came with its own raspberry Pi driver. I also added a PiSugar2 battery. Waveshare seemed to be the most affordable option out there.

I find the costs to be reasonable, but I just bought a Waveshare e-ink ESP32 controller to try boosting battery life, since I don't need a fully fledged OS. All I'm doing on the frame is pulling an image from an URL or displaying a local image if the connection fails.

This sounds like it could port well to an RP2040-based display. Though I am forever battling against its very constrained RAM for network stuff (not helped by MicroPython needing a chunk for buffers, an GC bitmap for mark/sweep and some other network mystery meat). That said our (Pimoroni) larger Pico W-based Inky has an 8Mbit PSRAM to act as a back buffer for the display. It’s “slow” but when updates take 30s+ anyway that’s kind of redundant. Very little of that 8Mbit is actually used, so with a little tinkering it might be able to cache multiple images for sequential display without having to faff about with SD cards.

Currently I transmute some images (XKCD and NASA APOD) via a scheduled GitHub action into something fit for the various display sizes. An even more extreme approach would be to convert into the packed (4bpp for 7-colour E-ink) framebuffer format server-side. Less network efficient, but more predictable memory usage.

We’ve had JPEG support for a while, but I brought up a PNG decoder (Larry Bank’s PNGdec) recently(ish) and it’s a much better fit than JPEG for palette-based images. It uses a 32K sliding window, however, which can get spicy if you’re not careful.

Thanks for the detailed reply, I'll look into all of this! Very interesting.

LilyGo T5 is a very cheap e-paper and also based on ESP32.