Lumina Studio, colour FDM printing decided by a measured calibration print

The colour comes from light passing through layers

Lumina is described in the repository as a physics based multi material FDM colour system that converts images into full colour 3D prints through calibrated light transmission mixing. The mechanism is worth stating plainly, because it explains everything else about the project. The output is not a painted model and not a colour mapped single material print, it is a stack of filament layers, each a different colour, and the colour you see is the result of light travelling down through those layers. At a fixed layer height, the layers combine into the colour seen in the finished print, which is why the geometry of the model and the palette of the filament are decided together. The 1.x line mainly covers two, four, six and eight colour workflows, and the project description adds that it exports a 3MF that BambuStudio and OrcaSlicer can slice. The 2.0 beta is exploring custom colour counts, custom layer counts and custom layer heights, which is the direction the whole idea points towards.

Calibration is a printed board, not a settings file

The README's section on why calibration matters contains the core idea of the project, and it is a good one. The colour printed by a filament is not fully described by its label, because light passes through several material layers and the result changes with layer order, layer height, print settings, filament batch, and photography. The last of those is a giveaway that this is a measured workflow rather than a computed one, since the camera used to capture the calibration samples is part of the measurement. The procedure is that Lumina records a real calibration print first, and then searches those measured results for layer combinations that match the image. The 1.x approach is described as a fixed colour board with photographed samples, with a physical fixed calibration board shown in the documentation. The consequence for a user is that the software is only half of the system, and the other half is a print, a camera and the willingness to redo it when the filament batch changes.

Four steps from an image to a print

The shortest workflow the README gives is four steps, and it is short enough to hold in your head.

# 1. Import an image.
# 2. Choose or import a preset that matches the materials.
# 3. Generate and open the 3MF.
# 4. Confirm the material order in the slicer, then print.

The interesting step is the second one, because the preset is the bridge between your filament and the model. A preset matches the materials you actually have, and choosing or importing one is what tells the tool which layer combinations are even possible. The third step produces a 3MF, which is the file the slicer consumes, and the fourth step is where the human check happens, since the material order in the slicer has to be confirmed before the print means anything. Around that core the project distributes its documentation in several places, with stable packages on the GitHub Releases page, the latest automatic builds on GitHub Actions, a complete 1.x guide in the project wiki, and a separate multi-brand slicer guide for the slicer setup. The Chinese README and the Chinese wiki paths show where the project's centre of gravity is, which is also where the community links in the header point.

The output is not limited to flat artwork

The showcase in the README makes a point that the description alone would not. Flat artwork, standing cut outs, pixel characters, folding fans, puzzles, perforated boards, glow in the dark phone cases and large tiled prints all grow from the same workflow, and the gallery images are labelled with the colour counts their makers used, from eight up to eighteen. The README is explicit that every image shown is a physical print rather than a software preview, and that community photographs are shown with permission. The 2.0 line is what makes the higher counts reachable, since the 1.x line is limited to two, four, six and eight, and the 2.0 rewrite is exploring arbitrary colour counts, layer counts and layer heights. The note at the top of the README records that 2.0 remains in private beta and is planned to become open source in October 2026, and it warns that the gallery mixes prints from both versions, so a viewer should consult the version notes for which features exist in which release.

A Gradio front end over a FastAPI backend and a vector engine

The requirements file shows the shape of the application. The interface layer is Gradio, at version 6.0.0 or later, and the backend is FastAPI with uvicorn and httpx, and the repository layout matches that split, with an api/ directory and api_server.py on the server side, ui/ for the interface, core/ for the logic, utils/ for helpers, and main.py as the entry point. The image processing is Pillow with pillow-heif for HEIF input, opencv-python, numpy, scipy and numba, and the geometry is trimesh, which is the mesh library, with shapely, svgelements and mapbox-earcut described in the file as the native vector engine dependencies. A folder named lut-npy预设 holds presets, and bambu_config_template.json is a template for the printer configuration, while benchmark.py and config.py sit at the top level. The remaining dependencies are the supporting cast, lxml, svglib, reportlab for document handling, colormath for colour conversion, networkx for graph work, pystray and pytz for the system tray and time zones, and lumina_studio.spec is a PyInstaller spec file for packaging the desktop application.

The container runs the Gradio app on port 7860

The Dockerfile is a straightforward Python application image. It starts from python:3.13-slim, sets the working directory to /app, and installs the system packages the two native dependencies need, with a comment in the file that explains each group, libcairo2-dev and pkg-config for pycairo and libgl1 and libglib2.0-0 for opencv-python. The requirements file is copied in and installed with pip using the no cache option, then the rest of the application is copied over. The container exposes port 7860, which is the port the Gradio interface runs on, sets PYTHONUNBUFFERED so that output is flushed rather than buffered, and sets LUMINA_HOST to 0.0.0.0 so the interface is reachable from outside the container rather than only on loopback. The command is python main.py. There is no database service, no message queue and no separate worker in the image, which is a good sign for a desktop tool that happens to be containerisable.

Licence, releases and an open source 2.0 still to come

The project is licensed under GPL-3.0, and the release history shows a steady 1.x line with v1.4.1 in January 2026 marked as a beta high fidelity update, v1.4.2 a few days later, and v1.6.3 in March 2026 described as bug fixes and stability improvements. The repository is not archived and the last push was on 2026-09-05, so work continues on the public branch, and the changelog exists in two languages, CHANGELOG.md and CHANGELOG_CN.md. The limitation that matters most is not the licence but the workflow, since the output colours are only as good as the calibration print and the photographs taken of it, and a batch of filament from a different supplier invalidates them. The second limitation is the slicer. The project description names BambuStudio and OrcaSlicer, the documentation offers a multi-brand slicer guide, and the 2.0 line is not open source yet, so a user who wants the flexible colour counts and layer counts has to wait or stay on the older line. The community links in the header, a Discord, a QQ group, Bilibili, YouTube and the various social accounts, are a sign of an active project rather than a hobby, and the Patreon and Afdian buttons show that development is funded by individuals rather than by a company.

Editorial conclusion

Lumina Studio fits a 3D printing hobbyist or a small studio that wants colour prints from artwork and photographs and is willing to spend filament on a calibration board and photograph it, because the measured results are what make the output colours land near the source. It does not fit someone who expects a software preview to be the finished colour, and it does not fit a workflow built around a slicer other than the ones the project documents. Verify three things before you buy filament: that your printer and filament combination is the one your calibration preset covers, since the colour result depends on layer order, layer height, print settings and filament batch, that the slicer you use is covered by the multi-brand slicer guide, and whether you want the 1.x line, which is what this repository holds, rather than the 2.0 rewrite that is still in private beta.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. lumina-layer-studio/Lumina-Layers on GitHub
4. README
5. Releases