My project turning an Adafruit Memento camera into a thermal camera was fun, but it didn't utilize any of Memento's programmable photography features. This is fine because I felt the advantage of Adafruit hardware is the ability to mix in more hardware for fun as I did. Besides, if a project's goal lies strictly within within the realm of photography, they might be better served by using a commercial camera product running an unofficial firmware project.

Modern digital cameras run on microcontrollers and motivated enthusiasts have found ways into those systems. I have historically purchased Canon cameras, so unofficial firmware projects most relevant to me are CHDK for Canon PowerShot point-and-shoot cameras and Magic Lantern for Canon's EOS interchangeable lens cameras. I read through FAQ for both and learned that's not exactly correct. Each project is actually specific to the operating system Canon runs on their cameras, and occasionally Canon would release an interchangeable lens camera running their point-and-shoot operating system (or is that vice versa?) for reasons known only to Canon.

Magic Lantern builds on the work pioneered by CHDK and Magic Latern's author fully credits the CHDK team for paving the way. Apparently CHDK bootstrapped starting from obtaining control over a camera status LED and using it to blink out data that told the team where to go from there. That's an amazing tale of hardware hacking. This relationship also means both projects use the same software architecture. Canon's camera firmware is not overwritten by these projects, the downloaded file lives on the memory card. And that CHDK/ML download has to match a specific version of Canon camera firmware.

These facts tell me CHDK/ML found a way to run their code on the memory card. And once they obtained execution control, they call routines in Canon's firmware to perform actual tasks. The upside of this approach means actual hardware interfacing is handled by Canon driver code, reducing the chance of a bug causing irreversible damage. And this approach is also how CHDK/ML can expose features not present in original Canon firmware, by calling Canon routines with parameters that the factory firmware chose not to utilize. The downside of this approach is that CHDK/ML is limited to features that can be composed from existing building blocks. A hypothetical example: I can snap a picture and save it with custom JPEG compression parameters, but I can't save to an entirely different image format Canon doesn't support. Like WEBP, not that I'd want WEBP anyway.

And to bring the discussion full circle: both CHDK and ML offer scripting engines so we can write and run small programs. CHDK supports uBASIC and LUA, while ML seems to have just Lua. Skimming through the documentation, the scripting API is focused on photo and video and little else. It's no CircuitPython, but that's expected and perfectly fine for projects in that domain. This all looks interesting enough for me to see if I have a CHDK/ML-compatible camera.