darktable: a non-destructive raw workflow for photographers who want to keep their files

The problem darktable solves, and who it is actually for

Raw files are large, camera-specific, and easy to lose track of. A photographer needs three things at once: a catalogue that knows where every negative is, an editor that never overwrites the original, and an export path to whatever the next step is. darktable is built around that loop. The README describes it as "a virtual lighttable and darkroom for photographers" that "manages your digital negatives in a database, lets you view them through a zoomable lighttable and enables you to develop raw images, enhance them and export them to local or remote storage."

That description sets the audience. This is software for someone with a folder of raw files and a colour-managed display, not for someone who wants to retouch a single JPEG for social media. The workflow is catalogue-first: images are imported, tracked, and edited through a pipeline of modules. If you shoot a few hundred frames a month and want a repeatable develop step, the design fits. If you edit one image a year, the import step alone will feel like overhead.

One line in the README is worth reading twice: darktable is "not a free Adobe Lightroom® replacement." That is the project's own framing, and it is honest. The two tools overlap in shape, not in menu names or in the assumptions they make about how you edit.

Non-destructive editing as a module pipeline, not a stack of presets

The architecture visible in the repository is a C application with a database at the centre and a processing pipeline in src/. Edits are parameters, not pixels. When you change exposure or apply a mask, the original raw file is untouched; the change lives in the database and, depending on configuration, in sidecar files next to the image.

The README's FAQ entries hint at where this shows up in practice. One asks why lighttable thumbnails look different from the darkroom preview. Another asks why a lens is not detected or corrected in the darkroom.

A GPU is optional but the README is direct about the cost of skipping it. Without one, "expect modules like denoise, local contrast, contrast equalizer, retouch or liquify to be slow beyond usable." Nvidia is the recommended vendor, with the note that "some AMD drivers behave unreliably with some modules (e.g. local contrast)." That is a real constraint on hardware choice, not a footnote.

AI features are a separate, opt-in layer. Object masks, denoise and upscale require building with -DUSE_AI=ON or --enable-ai via build.sh, and they are disabled in preferences by default. CPU inference is bundled, as are CoreML acceleration on Apple Silicon macOS and DirectML on Windows; other GPU inference needs a separately installed GPU-enabled ONNX Runtime, with CUDA 12 or 13 and cuDNN 9.x on NVIDIA, ROCm 6+ and MIGraphX on AMD, or OpenVINO on Intel. If GPU inference fails, the README states darktable retries on CPU and continues.

Installing darktable and making a first edit

The README splits installation into a latest release and a development snapshot, and points at the project site for both. On Linux, the distribution package is the shortest path and matches the platform the project develops on. The README does not list a single universal package command, so the exact package name depends on your distribution.

# Debian and Ubuntu families, package name as shipped by the distribution
sudo apt install darktable

On macOS the README supports Apple Silicon Macs running macOS 15 and later; there is no Intel Mac support listed. Windows 10 and later is supported, with the caveat that printing is not implemented there.

If you need the newest modules, the README documents building from source. The sequence is: install dependencies, get the source, get submodules, then compile. The submodule step matters because the repository carries a .gitmodules file, so a plain clone without submodules will not build.

git clone https://github.com/darktable-org/darktable.git
cd darktable
git submodule update --init --recursive

The repository also ships build.sh as a convenience wrapper. The AI build flag appears in the README in two forms, and they are not interchangeable: -DUSE_AI=ON is the CMake option, while --enable-ai is the build.sh flag.

./build.sh --enable-ai

For a first real use, import a folder of raw files into the lighttable, open one in the darkroom, and make a change that has an obvious visual result, such as exposure. Then export. The point of the first session is to confirm three things: that your camera's raw format opens, that the preview you see in the darkroom matches what you export, and that the export lands where you expect. The README's FAQ about thumbnails differing from the darkroom preview is exactly the discrepancy to check before you trust a large batch.

Where darktable is the wrong tool

The clearest boundary is in the README itself: this is not a Lightroom replacement. If your work depends on a specific Lightroom feature, a plugin, or a catalogue you already share with collaborators, darktable will not slot in without changing that workflow. The import and catalogue model is its own thing.

Platform gaps are concrete. Big-endian platforms are not supported. 32-bit platforms are not officially supported and "might or might not work." Windows printing is not implemented. macOS support is limited to Apple Silicon on macOS 15 and later, so older Intel Macs are out of scope.

The README also warns that both darktable and its libraries are developed on Linux, so other platforms "MAY have additional bugs that are not present in the Linux version," and recommends Linux if you have a choice. If you are on Windows or macOS and hitting a bug, that sentence tells you where the maintainers' test coverage lives.

Hardware is the other hard edge. The workable minimum is 4 GB of RAM and no GPU, but the README is explicit that denoise, local contrast, contrast equalizer, retouch and liquify become "slow beyond usable" on lightweight configurations. A Raspberry Pi will run it; it will not run those modules in a way you would want to use daily. The recommended minimum is 8 GB of RAM, an Intel Core i5 at 4×2.4 GHz, and an Nvidia GPU with 1024 CUDA cores, 4 GB and OpenCL 1.2.

darktable against RawTherapee: catalogue versus converter

The obvious open source comparison is RawTherapee, and the difference is architectural rather than cosmetic. RawTherapee is built as a raw converter: you point it at files, develop them, and send the result onward. darktable is built as a catalogue plus a developer. The README's first sentence puts the database first, and that ordering is the product. Import, track, edit, export.

That choice has consequences. A catalogue gives you a place to search, tag and revisit images months later, and it gives you a single place where edit parameters live. It also means the database is now something you have to keep. Move a library without understanding where the database and sidecars sit and you can lose the association between an image and its edits, even though the raw file is fine.

A converter-first tool does not impose that. It also does not give you the lighttable. Which is better depends on whether your problem is "develop this file well" or "keep track of ten thousand files and develop them consistently." darktable is aimed at the second problem. If your problem is the first, the import step is friction you are paying for a feature you are not using.

The AI layer adds a third axis. darktable's AI features are opt-in at build time and off in preferences, with CPU inference bundled, CoreML and DirectML acceleration bundled on macOS and Windows, and other GPU inference requiring a separate ONNX Runtime install. That is a deliberate default: the application does not assume you have a model runtime, and it does not download models without you enabling them from the AI tab in preferences.

Maintenance, licence and what an upgrade actually costs

The repository is not archived, and the last push was on 2026-11-01. Recent releases are release 5.6.1 on 2026-08-27, release 5.6.2 on 2026-10-04, and a nightly build dated 2026-11-03. The presence of a nightly channel alongside tagged releases means there are two upgrade tracks: stable tags, and a development snapshot the README lists as a separate install option.

The README has a section titled "Updating from older versions," which is the place to look before jumping a release. If you are upgrading a working installation, the safe move is to confirm you can reinstall the previous tagged version before you migrate.

Licence is GPL-3.0. For most photographers that changes nothing: you can use it, and there is no fee. The practical implication is for anyone embedding darktable in a product or shipping a modified build, because GPL-3.0 carries source-distribution obligations. That is a question for a lawyer, not for a review.

Upgrade cost is mostly about the AI path. If you built with -DUSE_AI=ON, your build depends on an ONNX Runtime version that you installed separately, and the README ties GPU acceleration to specific versions: CUDA Toolkit 12 or 13 with cuDNN 9.x on NVIDIA, ROCm 6+ with MIGraphX on AMD. Those are moving targets outside darktable's release cycle, so a working AI setup is a combination of two upgrade schedules, not one.

Editorial conclusion

Adopt darktable if you shoot raw, want your edits stored as parameters rather than baked pixels, and are willing to learn a module pipeline; the README recommends Linux if you have a platform choice, and notes that printing is not implemented on Windows. Do not adopt it expecting a Lightroom clone: the project says it is not one, and the interface rewards patience. Before committing a library, verify that your camera's raw files open, that your GPU is either absent or working with the modules you rely on, and that you understand where the database and sidecar files live, because those two things decide whether a catalogue survives a move.

Frequently asked questions

Official sources

1. darktable-org/darktable on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases