Making a user interface for a DIY camera

8 min readMar 23, 2024

Disclaimer: This is specifically for Raspberry Pi related hardware, the Python programming language and SPI-based displays. This is a brain dump, just random topics/thoughts about this project.

Introduction

Lately I have been obsessed with “making” my own cameras. While I am not at a point where I am satisfied with the current user interfaces that I have made, I have at least figured out some things and can share them for inspiration.

These were built in order from left to right. Pi Zero HQ Cam and Modular Pi Cam (v1 orange, v2). These all use Pi Zero 2 W.

Close up of the buttons/home UI screen.

The right camera is using the same menu system as the first one (left), although it was designed for 128x128 vs. 240x320 have to update it/make responsive

Main functionalities:

live camera preview/pass through
crop-zoom pan
take photo
video record
misc (eg. telemetry via IMU)
file view (poorly implemented)

Background on these cameras

The first one has the most features eg. it has a 10-axis (barometer) IMU inside it. Of course I only accessed 6 values (accel, gryo). It uses an OLED display. The orange camera I wanted to try a round display with the 5D joystick rocker and to try the v3 camera modules. Then with regard to modularity the camera initially was intended to be modular by the face plates. The camera was built like a sandwich and so is the modular pi cam v2.

These front plates had different camera modules in them. The bottom one had a v2 module (8MP) in it.

The modular pi cam v2 version has swappable cameras and the largest display.

Disclaimer! Uses Type A cables (silver tabs on same side, 15 pin cable)

Start up

In this case I am using a systemd service and threading for running things in parallel. A main.py script runs everything eg. starts a thread to listen for button pushes, starts a picamera2 thread, etc…

Menu Navigation

Real quick, above you may notice that the orange one does not have a back button (top right, not part of d-pad). The orange one uses a 5D navigation joystick rocker (which my center click was faulty). I later realized this was a mistake hence the 3rd camera has a dedicated back button. This is particularly important in a situation like crop-zoom panning where you have to back out of a nested UI state.

The orange camera’s software I did not spend too much time on it. I just wanted it to work so its menu system is basic, it just goes left/right infinitely cycling the icons and the only one that works is the camera.

The Pi Zero HQ cam though has a lot going on like a battery profiler (just on/off elapsed time tracking into sqlite). Pi Zero HQ cam and modular pi cam v2 use an 18650 cell so they get about 6–7 hours of run time where as the modular pi cam v1 (orange) uses a 700mAh single cell lipo and lasts just above 2 hours.

Main thing I want to mention about the menu is I want to make it composable. The current way menu state is managed is really nasty and adding more pages… it sucks. I started to see a pattern.

You could use a JSON object/dict to define what is on the page and what it does. This is not done yet. I am working on a combined software that mixes these camera features and detects the camera to change the UI.

Coordinate system

Here you can see how a page is navigated (up, down, left, right) via -1, 0, 1…

Live passthrough

Live passthrough is just a loop that’s taking a small photo and showing it on the screen.

Layering menus

I’m using PIL to take a sprite eg. the gear icon and pasting it onto of a base image via Image Draw. Similarly for the overlay on live camera preview it’s just adding text on top of a photo.

Tangent: the portrait display of the v2 camera caused me some annoyance, I had to figure out how to rotate the camera output and menu… that took a bit.

Crop-zoom panning

I’m kind of all over the place here and my bad for that. I don’t have too much time to write this down right now. I have documented most of the work on Hackaday for these projects.

I wanted to talk about this because it’s a cool feature. These tiny displays means you have to scale down your image from the camera. The live preview does not use a buffer stream, my approach is just literally taking a photo, it’s stored in a variable and shown on the screen. The main limiting factor is the speed of the SPI… which is determined by the device eg. Pi Zero 2 is better/faster than Pi Zero 1 and the LCD itself (how fast it can write data). This translates to a visible display update eg. a line/slow frames. That’s why these all use Pi Zero 2’s because of the size and fastest. You can still tell the slow FPS rate/visible updating.

So in my code I can change the settings of the camera eg. how big of a picture it takes. So for live preview it takes a small photo.

The OLED display for the Pi Zero HQ cam for example is 128x128 pixels. The sensor of the HQ camera produces 4056x3040 pixels. Above you can see on the left what might be visible on the live display, then when you’re ready to take a photo, the camera mode/setting is changed momentarily and a photo is saved to file.

The crop-zoom pan is showing a crop of a larger image. I only had it go to 4x but I will have it go to 16x. This is useful for checking focus.

Electronic aperture

This is a really cool feature of the v3 camera modules. You can via code change their depth of field. It uses this diopter metric eg. 1/1 is 1–3 meters is in focus and you go up it gets narrower eg. 1/10 (max) is 10 centimeters in focus (macro).

narrow depth of field sample v3 standard

On the orange camera, I had set an overlay to show what value is being used like this:

I would push up/down on the right stick to change the depth of field. The orange camera was nice, it was like a point and shoot. You can also do auto focus and infinite focus (0).

File view

I actually built this, but it does not do a background job of making thumbnails so it takes a while to load. I just wanted to show the idea though.

Remote control

Initially I tried to make this thing with bluetooth (a react native app) however the BL/BLE thing was hard for me to figure out. So I went with an access point approach instead (RPi is a WiFi you connect to and it hosts a web app). This way works and the Bookworm OS (Debian) uses network manager by default and it’s easy to open a hotspot granted when you turn it on you lose SSH access (so far) so your software needs a way to turn that off. It also boots faster. But it can stream the camera view and you can focus/do stuff with that. The modular pi cam v2 has a tripod screw hole (1–4/20) so it can avoid bumps since the spring-push down shutter does induce a rotation on the camera when you take a photo.

Timelapse

This is a cliche feature but I had it on the Pi Zero HQ cam. Since time lapses take a while, I didn’t really use it much. A sunset would be cool to do.

Here you can briefly see a lake but I was only there for a few minutes.

Sonew 5mm Pi Zero HQ cam

Negatives

Max resolution of 12MP although that’s pretty good if you pair it with a good lens eg. via a Canon FD mount for example.

The LCDs are hard to see in bright conditions outside, the LCD is a little better and if you use a light-mode menu.

Sensor pixel size/lens quality… this will not compare to a Sony Alpha or something like that. Larger things/closer look better than far away tiny things eg. the branches of trees.

Sample photos

I have been having fun with these cameras. I am not a professional photographer, I can do the basics/currently use auto settings till I dive into that ex. there’s no ISO but a gain equivalent with picamera2.