filmulator-gui trades raw editing flexibility for a film simulator with a fixed pipeline

A film emulator, and an interface that admits its trade-off

Filmulator accepts raw files from cameras and simulates the development of film as if the film had been exposed to the same light as the camera's sensor. filmulator-gui is the Qt Quick graphical front end to that engine, and the README describes it as a film emulator with all of the positives and none of the negatives.

The design ideology is stated without hedging. The program's design ideology is to have the best tool for any job, and only that one tool. The tradeoff is a slight decrease in flexibility, and the compensation is a greatly simplified user interface.

That is a rare kind of README paragraph, and it is the most useful thing in the document. A raw editor normally gives you a large set of controls and lets you find your own order. Filmulator gives you one order and one set of controls, and the documentation tells you up front that you are trading the other thing away.

The audience is therefore a photographer who wants a specific look from raw files and does not want to make every decision. It is a narrower product than a general raw converter, and the narrower scope is the point rather than a limitation the project is apologising for.

What the film simulation does to your highlights

The README lists the benefits that follow from simulating film development rather than applying a preset. They are tonal effects, not stylistic ones, and they are worth reading closely because they explain what the algorithm is doing.

Large bright regions become darker, which compresses the output dynamic range. Small bright regions make their surroundings darker, which enhances local contrast. In bright regions, saturation is enhanced, which helps retain colour in blue skies, brighter skin tones and sunsets. In extremely saturated regions the brightness is attenuated, which helps retain detail, for example in flowers.

Each of those is the kind of behaviour that comes from a real film response curve, where the emulsion reacts to the amount of light it receives rather than to the value of a single pixel. That is why the tool can produce a result that a conventional tone curve struggles to match, and why the settings sliders in the interface are described as controlling the simulation rather than as generic exposure and contrast controls.

The by-product is that the output is not simply a different curve applied to the whole frame. A small bright highlight darkens what surrounds it, so the result is spatially dependent in a way that a global adjustment is not.

Building with vcpkg is the documented path now

The README now leads with vcpkg as the recommended way to build Filmulator, and the reason given is that it automatically manages all dependencies across Windows, macOS and Linux.

The setup has three parts. First, install vcpkg itself:

git clone https://github.com/microsoft/vcpkg.git
cd vcpkg && ./bootstrap-vcpkg.sh  # or bootstrap-vcpkg.bat on Windows

Second, install the system packages that vcpkg needs to build some of its own ports, which differ per platform:

brew install pkg-config ninja libomp autoconf autoconf-archive automake libtool

on macOS, and on Linux:

sudo apt install pkg-config ninja-build

Third, point the build at that vcpkg installation through the VCPKG_ROOT environment variable:

export VCPKG_ROOT=/path/to/vcpkg  # Add to your shell profile

Then the build itself is a preset and a compile:

cd filmulator-gui/filmulator-gui
cmake --preset relwithdebinfo
cmake --build build/relwithdebinfo -j$(nproc)

The README warns that the first build takes time because vcpkg downloads and compiles dependencies, and that later builds reuse cached packages. The available presets are debug, release and relwithdebinfo, with relwithdebinfo recommended for development. The repository root also carries vcpkg.json, vcpkg-configuration.json and a vcpkg-overlay directory, which is how the project pins its own dependency versions.

The manual dependency list for anyone not using vcpkg

The legacy build path is documented in full, which is useful because it also tells you what the project depends on. If you are not using vcpkg you need these libraries installed:

libtiff, libgomp, libexiv2, libjpeg, libraw, librtprocess, liblensfun, libcurl, libarchive

and Qt 5.15 or newer. The README also strongly encourages you to compile libraw yourself to ensure support for recent cameras, which is the kind of advice that matters in raw processing, where camera support is a moving target.

The Linux route is straightforward: create a build directory, run cmake with a build type and an install prefix, then make and make install as root. The macOS route is the hard one, and the README is candid that you need to locate several real dynamic libraries rather than the symbolic links that point at them, including libomp.dylib, libarchive.dylib, librtprocess and the Qt installation. The command line it gives for macOS passes those paths in one long cmake invocation with a Unix Makefiles generator.

The odd thing about that legacy section is that it is still in the README while vcpkg is recommended, so the documentation describes two quite different build experiences. If you are starting fresh, the vcpkg path is the shorter one.

Import, organize, then filmulate: a three tab workflow

The application workflow is a fixed sequence of tabs, and the README walks through it in order.

Importing comes first. You select directories or individual files, and you choose whether the photos stay where they are or get copied into a directory structure based on the date captured, with both a destination directory and a backup directory. Two offset settings drive that structure, the Camera UTC Offset for the timezone you set the camera's clock in, and the Local UTC Offset for the timezone where the photo was captured. Photos are pulled into the database and the source directory is written out.

The Organize tab comes next, where you select photos to enqueue. A calendar and a date histogram let you pick a day, and a timezone slider adjusts how the day is sliced, always displaying from midnight to midnight. You enqueue by double-clicking photos in the grid view, remove them from the queue by right-clicking the queue entry and choosing Remove from queue, and you can rate images from zero through five and filter the tab to show only photos above a given rating.

Then the Filmulate tab, where you double-click a photo in the queue to run it through the simulation and adjust the sliders.

The organizing step is skippable if you enqueue before importing, and the README says as much, but then advises looking at the tab anyway.

The tools are ordered, so work top-down

The interface is a pipeline, and the README is explicit about how to use it. The tools are arranged in pipeline order, meaning the processing they control occurs from top to bottom, and the advice is to work mostly top-down through the tools.

That is the practical expression of the fixed-tool philosophy. In a general raw editor you can revisit any adjustment at any time, because the operations are independent and order does not matter much. Here, the order is meaningful, so a later control acts on the result of an earlier one. Sliders further down the stack see an image that has already been changed by the sliders above them.

The one feature described in detail is the in-pipeline mini histograms, which display the distribution of pixel brightnesses right before and right after the filmulation algorithm. The README tells you to use the first one to adjust exposure compensation and highlight recovery, and begins to describe the second one as the control for the output. Two small histograms either side of the simulation turn an abstract slider into something you can reason about, which is the kind of feedback that makes a fixed pipeline usable.

The alternative to this design is a general raw editor with a node graph or a stack of adjustable filters, where you keep every control and choose the order yourself. Filmulator gives you one order and the histograms that make it legible, and the README's own framing of the tradeoff is the fairest summary of what you give up.

A custom licence and a release line with a five year gap

Two things about the project's status deserve attention before you build on it.

The first is the licence. The project is listed under a licence that GitHub cannot classify, a custom one, and the root of the repository contains both a LICENSE and a LICENSE.txt file. Nothing here is legal advice, but the practical point is that you need to read those files yourself. A custom licence may impose conditions that an MIT or Apache licence does not, and it may place restrictions on redistribution of builds or on commercial use of the output.

The second is the release history. The tags show v0.12.0 on 2026-04-04, and then a long gap back to v0.11.1 on 2021-03-06 and v0.11.0 on 2021-01-23. The last push to the repository was on 2026-07-05, so work continued after the 0.12.0 release without producing a newer tag.

For a user this means the packaged builds and the source tree may not match, and it means the 0.x version line still carries the usual signal that interfaces can change. The repository root also contains release_instructions.md, ARCHITECTURE.md, an Inno Setup script named filmulator_build.iss for Windows packaging, a PKGBUILD directory, patches/ and a cmake/ directory, which together describe a project that does its own packaging rather than relying on distribution packages.

Editorial conclusion

filmulator-gui fits a photographer who wants the look of film from raw files and who prefers a fixed, opinionated set of controls over a general raw editor with a hundred sliders, and it fits anyone willing to read a custom licence before shipping a product built on it. It is the wrong tool for a workflow that needs selective edits, masks or a non-linear pipeline, since the tool order is fixed by design, and it is the wrong tool if you want a plug-in free of the compile step, because the documented path is building the application from source. Verify first which release you are running, since v0.12.0 from 2026-04-04 sits five years after v0.11.1 from 2021, then read the LICENSE file at the repository root yourself, because the project ships both a LICENSE and a LICENSE.txt and the terms are not a standard open source licence.

Frequently asked questions

Official sources

1. CarVac/filmulator-gui on GitHub
2. Issues
3. Project website
4. README
5. Releases