Contributing upstream: greyscale (mono) screen support + per-unit calibration — would you welcome PRs?

[polygonfuture]

Hi @defl thanks for hokku_epaper; i love it! I've been running a fork on it happily (still using V3 as my fork base).

What I've built on a fork

Support for a monochrome (greyscale) e-ink screen — the Seeed reTerminal E1003
(16-level greyscale, IT8951 controller, ESP32-S3), the mono sibling of the E1004 you
already support. It's working end-to-end:

• A mono render pipeline (greyscale-first, linear-light Floyd–Steinberg over the 16
  levels) alongside the Spectra-6 colour path.
• Per-unit panel tone calibration — a measured step-wedge ramp so the render targets
  the panel's actual reflectance curve rather than assuming uniform steps.
• ESP-IDF firmware for the E1003 board (mono sibling of the E1004 baseboard).
• A modern, mobile-friendly web UI for the photo-to-frame workflow — library browsing,
  per-image editing with a true on-panel preview, and per-frame "now / up next" control —
  focused on quality-of-life and flow.

It's on a local branch I haven't pushed to the public fork yet — I'd rather get it fully
bug-fixed first so nobody pulls a half-finished build.

Homework done

I've read AGENTS.md, python/AGENTS.md, and docs/dithering.md, and I'll follow the
conventions there: brand_model naming (seeedstudio_e1003), the screen-package layout
with the hardware_facts.md / hardware_guesses.md split, keeping dithering.md + its
benchmark table in sync, the firmware STOP/dual-slot rules and PROTOCOL.CONFIG.N
versioning, the dev-version formula, and passing CI. I'll also target the 4.0 stable tag
rather than the betas.

Questions for you

1. Appetite — would you want a mono/greyscale screen in-tree at all? E1004 is colour
   and there's no mono screen yet, so this is new territory.
2. Structure — my plan is a seeedstudio_e1003 screen package (server + firmware,
   modelled on seeedstudio_e1004), with any small shared-core enabling changes as separate,
   focused PRs. Does that granularity match how you'd like it?
3. Shared-core touch points — the mono screen needs a couple of small generalisations in
   shared code: not assuming palette index 1 == white (padding / BW-LUT), and wiring the DRC
   lightness anchors to the target Display rather than the reference palette. Are those the
   kind of changes you'd take upstream, or would you rather they stay fork-side?
4. Timing — does targeting 4.0 stable line up with your release plans?

Happy to share more info such as the plan, more documentation on the shape of the e1003 pipeline etc. Whatever you need. Thanks for your time defl! Loving this project you built.

[defl]

HI Jonathan, Sorry for the long silence from my side, saw your emails come in but got buried in a pile of other stuff! - Would love to take on your seeed e1003 in a little bit, great to have more screens and choice. - Also saw your offer for the new UI, sounds interesting. Once 4.0 wraps up let's chat about that. - I've been building the shared core and it's expanding so it's going in that direction So planning wise, I'm going to only do a calibration improvement to the existing displays supported right now (all the same 6 color screen) as I've just done a huge run with a photo colometer and have built some tooling around this for 4.0. Let's pick up all the goodness you bring in the round after that :) Kind regards, Dennis Fleurbaaij

…

On Sat, Aug 8, 2026 at 2:44 PM Jonathan Moore ***@***.***> wrote: *polygonfuture* created an issue (defl/hokku_epaper#36) <#36> Hi @defl <https://github.com/defl> thanks for hokku_epaper; i love it! I've been running a fork on it happily (still using V3 as my fork base). What I've built on a fork Support for a *monochrome (greyscale) e-ink screen* — the Seeed reTerminal *E1003* (16-level greyscale, IT8951 controller, ESP32-S3), the mono sibling of the E1004 you already support. It's working end-to-end: - A *mono render pipeline* (greyscale-first, linear-light Floyd–Steinberg over the 16 levels) alongside the Spectra-6 colour path. - *Per-unit panel tone calibration* — a measured step-wedge ramp so the render targets the panel's actual reflectance curve rather than assuming uniform steps. - ESP-IDF firmware for the E1003 board (mono sibling of the E1004 baseboard). - A modern, mobile-friendly web UI for the photo-to-frame workflow — library browsing, per-image editing with a true on-panel preview, and per-frame "now / up next" control — focused on quality-of-life and flow. It's on a local branch I haven't pushed to the public fork yet — I'd rather get it fully bug-fixed first so nobody pulls a half-finished build. Homework done I've read AGENTS.md, python/AGENTS.md, and docs/dithering.md, and I'll follow the conventions there: brand_model naming (seeedstudio_e1003), the screen-package layout with the hardware_facts.md / hardware_guesses.md split, keeping dithering.md + its benchmark table in sync, the firmware STOP/dual-slot rules and PROTOCOL.CONFIG.N versioning, the dev-version formula, and passing CI. I'll also target the *4.0 stable tag* rather than the betas. Where I'd value your read (things the docs don't cover) 1. *Appetite* — would you want a *mono/greyscale screen in-tree* at all? E1004 is colour and there's no mono screen yet, so this is new territory. (Totally fine if not — I'll keep it on the fork.) 2. *Structure* — my plan is a seeedstudio_e1003 screen package (server + firmware, modelled on seeedstudio_e1004), with any small shared-core enabling changes as separate, focused PRs. Does that granularity match how you'd like it? 3. *Shared-core touch points* — the mono screen needs a couple of small generalisations in shared code: not assuming palette index 1 == white (padding / BW-LUT), and wiring the DRC lightness anchors to the target Display rather than the reference palette. Are those the kind of changes you'd take upstream, or would you rather they stay fork-side? 4. *Timing* — does targeting 4.0 stable line up with your release plans? Happy to share more info such as the plan, more documentation on the shape of the e1003 pipeline etc. Whatever you need. Thanks for your time defl! Loving this project you built. — Reply to this email directly, view it on GitHub <#36?email_source=notifications&email_token=ABDHX43RDIIWPZXOPSRUCU35I57IPA5CNFSL4Z3JMQ5C6L3HNF2C22DVMIXUS43TOVSS6NJQHE4TCNJSGYYTDJTSMVQXG33OU5WWK3TUNFXW5JLFOZSW45FMMZXW65DFOJPWG3DJMNVQ>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABDHX4Z63B7UDT3MPDQCEK35I57IPAVCNFSNUABGKJSXA33TNF2G64TZHMYTCOBTHA4TAMJYGE5US43TOVSTWNJQHE4TCNJSGYYTDILWAI> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[polygonfuture]

Sounds good.

Im still in the process of testing, bug fixes, and overall user flow refinment on the gallery / ui / editing features.

Curious about your colormeter work. The E1003 screen ive tuned something to generally get a decent output; however i didnt use any special tools for matching just going by eye and getting claude to do some analysis on a scan of the screen brightness / contrast range.