# vkdt puts the whole raw photo pipeline on the GPU as a node graph

> vkdt is a raw photography and video workflow toolbox where every processing step is a node in a directed acyclic graph executed as Vulkan shaders. It is fast because the graph never leaves the GPU, and demanding because that also means writing your own GLSL modules for anything it does not ship.

**hanatos/vkdt** — raw photography workflow that sucks less

- Repository: https://github.com/hanatos/vkdt
- Website: https://jo.dreggn.org/vkdt
- Stars: 619 · Forks: 54
- Language: C
- License: BSD-2-Clause
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/hanatos-vkdt

## A processing graph where every node is a shader

vkdt is described as a workflow toolbox for raw stills and video, and the architecture is the interesting part of it. The processing pipeline is a generic node graph, a DAG, that supports multiple inputs and multiple outputs, and all processing is done in GLSL shaders on Vulkan.

The stated argument for the design is a loop: faster processing allows more complex operations, so the tool can afford things like image alignment and better highlight inpainting that would be too slow otherwise.

The GUI benefits from the same property rather than from any special UI work. The documentation notes the gui profits from this scheme as well and can display textures while they are still on the GPU, which means an intermediate result can be previewed without a round trip through system memory.

A DAG with feedback connectors is what makes animation work. The features list describes a general DAG of processing operations with multiple inputs and outputs and feedback connectors for animation and iteration, and the pipe module documentation is where that is spelled out. Real time magic lantern raw video processing and a GPU decoder for MotionCam raw video both sit on top of that, along with 10-bit display output.

The audience is people who already think in nodes. This is a tool for someone who wants to write a custom module, not for someone who wants a Lightroom replacement with a different price tag.

## Automatic parameter fitting, denoising and noise profiling

Three features stand out from a general image editor, and they are the ones worth reading the linked documentation for.

Automatic parameter optimisation lives in the fit module, and the documentation gives vignetting fitting as the example. The idea is that instead of you adjusting a parameter until a result looks right, the tool searches for the value that best matches an observed result. For vignetting that means finding the falloff that the lens produces rather than hand drawing a correction.

Denoising is u-net based, implemented in the oidn module and using fast schedules. The ecosystem section points to a separate neural network training infrastructure repository and a neural network weights repository, which tells you the models are trained outside this repository and pulled in as weights. A denox onnx to spir-v compiler is listed too, along with a vkdt specific codegen fork of it, which is how an ONNX trained network becomes something the graph can execute as a shader.

Noise profiling has its own how-to. Combined with the optional exiv2 dependency for raw metadata loading, that is how a camera and ISO combination gets associated with a noise profile automatically rather than by hand.

Together these are the features that make this more than a viewer. They are also the features where the output depends on models and fitting results you did not produce, so they are the parts to sanity check against known ground truth before trusting.

## Colour management and a display pipeline that only sees one screen

The colour handling is described as full window colour management, with a dedicated how-to for the colour display. There is a tool for reading ICC profiles, vkdt-read-icc, and a LUT utility, vkdt-mkclut, plus a lut target in the Makefile and a vkdt-lutinfo inspection binary in the install list.

The FAQ is candid about the weak point. On Wayland the documentation says vkdt officially runs natively and better than on X11 with glfw 3.4 or newer, and that details vary a lot by compositor, with hyprland called out as excellent. The stated caveat and pain point is colour management: the built-in mechanism in vkdt works, but only on a single screen, and creating the display profile depends on argyll or displaycal, and that still requires X11.

So the honest summary is that the pipeline is colour managed, and the display of that colour to your monitor is where the tooling thins out. A dual screen setup is a case the built-in path does not cover.

This is a real limitation for anyone doing serious colour work, and it is the kind of thing to discover during setup rather than after a day of grading. If accurate display is the reason you are here, the display profile step is the part to solve first.

## Installing from a nightly package, Nix, or the AUR

There are three documented ways in, and the first one is the easiest.

The project publishes nightly packages built by the GitHub CI, and the release list shows a nightly build tagged 20261017 alongside the version 1.0.0 release from 2025-12-13 and 0.9.1 from 2024-10-28. The nightly tag is the one the documentation points at for trying the tool.

For Nix there is a package in the unstable channel, and the documentation suggests using it to run the tool on any Linux distribution:

```
  nix-shell -p vkdt
```

vkdt also comes with a nix flake for an up to date package, so you can check out the repository and run it directly:

```
  nix run .
```

Arch users have a vkdt-git package in the AUR:

```
  yay vkdt-git
```

The FAQ describes platform support as native for NixOS, Arch Linux through the AUR, and builds and runs on macOS on both Intel and Apple Silicon, where you use brew to build and the LunarG Vulkan SDK to run. There is an unfinished Android port with a pull request on GitHub.

Building from source is the fourth option. The binaries land in the bin/ directory, and the build is a make invocation from there:

```
  cd bin/
  make -j20
```

Debug builds enable the Vulkan validation layers, so those need to be installed. There is a separate make debug target, which the documentation warns includes extra memory overhead and expensive checks and can therefore be much slower, and a make sanitize target that switches on the address sanitizer. Compile time configuration and the compiler toolchain are set in bin/config.mk, and if you do not have that file yet you can copy it from bin/config.mk.defaults.

## Running a graph, and how raw files get a default pipeline

The run command takes a configuration file, and the documentation uses an example from the bin/examples/ directory:

```
  cd bin/
  ./vkdt -d all examples/logo.cfg
```

The -d all flag is a debug or display selection, and the qvk variant appears elsewhere in the FAQ, so the -d option takes a module or verbosity selector. The documentation notes that the example config files need editing, because you have to change the filename in the example cfg to point to a file that actually exists on your system. That is a small thing that will otherwise look like a broken installation.

The default behaviour is documented: raw files will be assigned the bin/default-darkroom.i-raw processing graph. So the graph you get out of the box is the darkroom pipeline, and a config file is how you override it.

The command line interface has one important difference. The documentation states that if you run the command line interface vkdt-cli, it replaces all display nodes by export nodes. In other words the same graph is used, with the preview stages swapped for writes to disk. That is a clean design, because it means the thing you tuned interactively is the thing that renders in batch.

The Makefile install target shows the full set of binaries that get installed: vkdt and vkdt-cli, exiftool, vkdt-mkssf, vkdt-mkclut, vkdt-fit, vkdt-eval-profile, vkdt-lutinfo, vkdt-noise-profile, vkdt-gallery, vkdt-read-icc, plus darkroom.ui and style.txt. A vkdt.desktop file and an icon are also installed on Linux, so the GUI gets a launcher entry.

## Picking a GPU, and the timeout that forces you to the command line

Two FAQ answers describe the failure modes you are most likely to hit.

The first is the wrong GPU being selected. The documented fix is to make sure the GPU you want has the HDMI or DisplayPort cable attached, otherwise you can only run vkdt-cli, then run the qvk debug selector and find a line in the output like this:

```
[qvk] dev 0: NVIDIA GeForce RTX 2070
```

and place that printed name exactly as written into the configuration file at ~/.config/vkdt/config.rc, on a line such as:

```
strqvk/device
```

The second is the long running job. The FAQ asks whether you can run a very long running kernel without a timeout, and the answer is that if you are using your only GPU in the system you need to run without Xorg, straight from a tty console, which means the command line interface vkdt-cli only, and that a timeout is forced anyway, at something like 16 minutes. The documentation invites feedback if you hit that.

That 16 minute ceiling is a genuine constraint on the heavy work the tool is built for. Image alignment and highlight inpainting are exactly the kind of operation that can exceed it, and a forced timeout mid pipeline means you need to plan your runs around it.

## A BSD codebase with GPL and LGPL parts inside it

The licensing is layered, and the documentation is upfront about it. The project states its own code is licensed under the 2-clause BSD licence, unless clearly marked otherwise in the respective source files, which contain a bit of viral GPLv3, so handle with care if you are afraid of the GPL. The repository root confirms the split with two licence files, LICENCE.bsd2 and LICENCE.gpl3.

Third party components carry their own terms. The list gives rawspeed as LGPLv2, ffmpeg as LGPLv2 and nuklear as public domain, and notes the project may link to some others too. This is not legal advice, but the practical point is that a binary you build here is not a pure BSD artefact, and if you are shipping it inside a product the LGPL components and the GPL-marked files need their own review.

The build dependencies reinforce the point. Vulkan and glslangValidator are required, along with glfw, libjpeg, and for raw input either rawspeed, which depends on pugixml, zlib, libomp and cmake, or rawler, which pulls in a Rust toolchain that manages its own dependencies. You can also build without rawspeed or rawler if that is useful to you, which is the escape hatch when the raw decoding dependency is the problem.

The optional pieces are configured in bin/config.mk: exiv2 for raw metadata loading to assign noise profiles, asound for audio support in video and quake, ffmpeg for the video io modules i-vid and o-vid, and libjxl.

## Conclusion

vkdt suits a photographer or film colourist who already works in the command line, wants raw processing that stays on the GPU, and is prepared to read the module documentation before using a new operation. It is the wrong choice if you want a conventional darkroom with a familiar interface, and the wrong choice for image work that a single command line tool handles today, because building a graph and authoring shaders is a different commitment from running a converter. Before installing, run the example configuration in bin/examples against a file that exists on your system, since the documentation notes you have to edit the filename inside the example config, and decide whether you need rawspeed or rawler, because that choice brings its own build dependency.

## FAQ

### What is vkdt and what is its processing model?

vkdt is a workflow toolbox for raw stills and video whose pipeline is a generic node graph, a DAG with multiple inputs and outputs, where all processing is done in GLSL shaders on Vulkan. The GUI can display textures while they are still on the GPU.

### How do I install and run vkdt on Linux?

Nightly packages are built by the GitHub CI, a Nix package exists in the unstable channel and can be run with nix-shell -p vkdt, and Arch users have a vkdt-git package in the AUR. From source you run make from the bin/ directory, then run the binary with a config file, for example ./vkdt -d all examples/logo.cfg.

### Does vkdt work on Wayland and with multiple screens?

It runs natively on Wayland and the documentation says it does so better than on X11, using glfw 3.4 or newer. The stated caveat is colour management, where the built-in mechanism works but only on a single screen, and creating the display profile with argyll or displaycal still requires X11.

## Sources

- [hanatos/vkdt on GitHub](https://github.com/hanatos/vkdt)
- [License: BSD-2-Clause](https://github.com/hanatos/vkdt/blob/master/LICENSE)
- [Project website](https://jo.dreggn.org/vkdt)
- [README](https://github.com/hanatos/vkdt/blob/master/README.md)
- [Releases](https://github.com/hanatos/vkdt/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/hanatos-vkdt