pibooth: a photo booth application for the Raspberry Pi

A photo booth that runs as an application, not a project

The pibooth project provides a photobooth application out-of-the-box in pure Python for Raspberry Pi, and it also supports OpenCV compatible devices.

The phrase out-of-the-box is the whole pitch, and it is a meaningful one for this category of project. A photo booth is a small piece of embedded software with a surprising number of parts: a capture pipeline, a countdown, an idle screen, a way to trigger it without a mouse, a way to assemble the results, a way to print them, and a way to get them off the device. Every one of those is a decision, and every one is a weekend if you build it yourself.

pibooth is a Python package published on PyPI, installable with pip in the usual way, and it is packaged for a Raspberry Pi first, with the Pi camera, the Pi GPIO and Pi startup behaviour as first class concerns rather than adaptations.

The scale of the project is visible in the release list. Version 2.0.8 is dated 2023-07-20, then version 2.1.0 on 2026-09-11 and version 2.1.1 on 2026-09-25, with the last push to the repository on 2026-09-27. So there was a long quiet period and then a burst of recent work, which reads as a maintenance release after a gap rather than continuous development.

The project is MIT licensed, the primary language is Python, and the package metadata declares Development Status 5, Production and Stable, with classifiers for Python 3.10 through 3.13 on POSIX Linux.

One to four captures, concatenated into a single picture

The capture model is the heart of it, and it is described precisely.

You can capture from 1 to 4 photos and concatenate them in a final picture. That is the classic photo booth strip, in a single frame, and the number is a configuration choice rather than a fixed behaviour.

Around that core sit the presentation options. Custom texts can be added on the final picture, with customisable fonts, colours and alignments, and custom backgrounds and overlays can be added on the final picture as well. A background is the scene behind the subjects, and an overlay sits on top of the finished image, which together are how a plain capture becomes something that looks like an event.

The individual captures are kept as well as the final picture. The feature list says the project stores final pictures and the individual captures, which matters for two reasons: a guest can be handed the strip while the individual shots remain available for a gallery or a social media post, and you have the raw shots to change the layout later without asking anyone to be photographed again.

There is also an idle behaviour. The application animates captures from the last sequence during idle time, so instead of a static screen the booth shows a moving montage of what it has just taken. For a unattended kiosk at a party that is the difference between a device that looks switched off and one that looks alive.

Cameras come in through gPhoto2, OpenCV or the Pi camera path

The camera support is described as covering all cameras compatible with gPhoto2, OpenCV and Raspberry Pi.

Read that as three separate routes into the same capture pipeline. gPhoto2 is the libgphoto2 compatible interface that talks to a wide range of USB cameras, and it is the route that covers most webcams and USB cameras that behave like a camera rather than a webcam. OpenCV compatible devices are the second route. The Raspberry Pi camera is the third, and the topics attached to the repository include gphoto2, opencv, pillow, pygame, python3, raspberry-pi, raspberry-pi-camera and raspberrypi, which is a good indication of the stack underneath.

The practical consequence for a builder is that the camera you already own is probably supported. That matters more than it sounds, because a USB camera that gPhoto2 does not recognise is the single most common reason a photo booth project does not get started.

The image work is done with Pillow, and the interface is built with pygame, which is why the package is described as a desktop style application rather than a web page. There is no browser and no server, the application owns the screen, and the interaction is with the screen or with hardware.

The topics list also includes pygame, so if you are choosing between a browser based booth and this one, the difference in behaviour at the kiosk is substantial. A native surface redraws a full screen animation without a compositor in the middle, and a booth that has to start in under a second after a button press is sensitive to that.

Buttons on GPIO, lamps on GPIO, and a kiosk that starts itself

The hardware story is what separates a photo booth from a camera script, and the feature list covers it in three items.

There is support for hardware buttons and lamps on Raspberry Pi GPIO. There is fully driven from hardware buttons, keyboard, mouse or touchscreen. And there is auto-start at the Raspberry Pi startup.

Together those three make the difference between a program you launch and a booth that works when someone walks up to it. A guest should not have to start anything, and the person who set the booth up should not have to leave a terminal open.

The auto-start behaviour is worth reading about rather than assuming, because on a Raspberry Pi there is more than one way to do it and the choice has consequences for how the application reacts to a crash or to a power cut. The README points at the documentation site for the details.

The lamps are the part people underestimate. A lamp that lights when the camera is ready and goes out during the countdown is the primary feedback channel, and for a booth where the screen may be small, angled away, or on a different shelf, a physical indicator is more reliable than an on-screen prompt. The extra-lights plugin in the official plugin list exists for exactly this kind of extension.

The multi-input support matters for a different reason. A booth that only accepts a button is a booth you must build hardware for. One that also takes a keyboard, a mouse or a touchscreen can be set up with nothing more than a USB keyboard while you decide what the final rig should look like.

Printing through CUPS, with a queue you can watch

Printing final pictures using a CUPS server is the feature, and the parenthetical detail is printing queue indication.

CUPS is the printing system on Linux and on the Raspberry Pi OS, so this route means a booth can drive an ordinary network or USB printer with no proprietary driver and no printing service of its own. The application talks to the local print queue.

The queue indication is the part that matters operationally. A booth that prints silently will eventually jam, run out of paper or run out of ink, and the first sign of it is usually a pile of missing photos at the end of the evening. Being able to see that the print queue has stopped draining is how a venue owner or a helper notices before the event is over.

The picture workflow has two halves that are worth separating. The captures are stored on the device, and the final pictures are printed. The plugin list shows that the same design extends to distribution: there is a Dropbox plugin and an S3 upload plugin, plus a QR code plugin and a Telegram upload plugin in the third party list. So the natural progression for a builder is print on the spot, and offer the digital copy through a code or an upload.

The order of operations is the part to get right. If the upload is meant to be a backup for a printed photo, the upload should happen first, and if the QR code is the only copy, the printing should be treated as optional. The plugin architecture lets you decide that, and deciding it before the event is much easier than deciding it in front of a queue of guests.

The plugin system is the extension point, and PyPI is the marketplace

The last feature line says it all: highly customizable thanks to its plugin system, you can install plugins developed by the community from PyPI or develop your own plugin.

The plugin architecture is the answer to the question every embedded application eventually faces, which is how a feature request that only one user wants is accommodated without bloating the core. For pibooth the candidate features are obvious from the list of plugins that already exist.

The organisation's own plugins are pibooth-picture-template for print layout templates, pibooth-google-photo for Google Photos, pibooth-sound-effects for audio during the sequence, pibooth_dropbox for upload, pibooth-qrcode for QR codes, and pibooth-extra-lights for additional lighting.

The third party list shows the range beyond the official set. There is an LCD display plugin and an OLED display plugin, which suggests a booth with a small status screen next to the camera rather than relying on the main display. There is a neopixel plugin for a Neopixel SPI LED strip, which is the cheapest way to build an animated indicator. And there are the telegram-upload and s3-upload plugins for delivery.

The pattern is worth noticing. The display and the lighting plugins are the ones that turn a camera program into a booth, and the upload plugins are the ones that turn a booth into something that works unattended. The core application deliberately does not do any of that, which keeps the core small and the package installable on a Pi without pulling in a dozen dependencies.

Configuration in a file, and a GUI for the common options

All settings are available in a configuration file, with the most common options also in a graphical interface.

That split is a sensible one. A configuration file is what you put in version control, copy between booths, or generate for a fleet of devices, and it is what you edit for the settings nobody touches during an event. A graphical interface is what the person standing at the booth uses, which is why the common options are in the GUI and the rest are not.

For a deployment with several units at different venues, that distinction is the difference between reconfiguring a booth by editing a file over SSH and reconfiguring it by walking over with a keyboard.

The interface itself is available in Danish, Dutch, English, French, German, Hungarian, Norwegian, Portuguese for both Portugal and Brazil, Spanish and Swedish, and it is customisable. The package classifiers list those languages plus Italian, which is a small difference from the README list and worth checking if Italian matters to you.

The documentation lives at pibooth.readthedocs.io, and the repository also has a wiki where users are invited to share photos of their own builds. That wiki is a genuinely useful resource for this project, because the ways people turn a Pi into a booth involve hardware choices, mounting, lighting and enclosures, and none of that is in the documentation.

The repository itself is compact, with a pibooth package directory, a tests directory, a docs directory, a setup.py, a MANIFEST.in, a LICENSE file, and the .flake8 and .pylintrc configuration files, and the CI workflow is visible in the README badge, so the test suite is part of the project rather than an afterthought.

Editorial conclusion

pibooth suits a maker who wants a working photo booth on a Raspberry Pi this weekend rather than a camera application to build from scratch, because the capture flow, the assembly of the final picture, the hardware button handling, the printing queue and the plugin system are all in the box and the documentation is on Read the Docs. It does not suit a project that needs continuous video, motion detection or remote control, and it does not suit a team that cannot accept a Python 3.10 and Raspberry Pi specific dependency set. Before you build a booth on it, check that your camera is one of the supported kinds, since the support list is defined through gPhoto2, OpenCV and the Raspberry Pi camera path, read the notes on auto-start and on the printing queue rather than assuming the daemon behaviour, and note the last push to the repository was on 2026-09-27 with version 2.1.1 published on 2026-09-25.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. pibooth/pibooth on GitHub
4. README
5. Releases