# RAWmakase: a non-destructive RAW developer in Rust with Lightroom catalogue import > RAWmakase is a Rust photo developer for Linux, macOS and Windows that opens RAW files through LibRaw, edits them with a Lightroom-style control set and exports JPEG or 16-bit TIFF, and it can import a Lightroom Classic catalogue without ever writing to it. It suits a photographer leaving Adobe's ecosystem, and the project warns plainly that the rendering engine can change between versions. **pch/rawmakase** — 📸 Free, fast, Lightroom-compatible RAW photo editor for Linux, macOS, and Windows. - Repository: https://github.com/pch/rawmakase - Website: https://rawmakase.com - Stars: 1,260 · Forks: 47 - Language: Rust - License: MIT - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/pch-rawmakase ## What it opens, what it edits, what it exports RAWmakase is a fast, non-destructive RAW photo developer for Linux, macOS and Windows, written in Rust. It opens RAW files from the cameras LibRaw supports, develops them with a Lightroom-style set of controls, and exports JPEG or 16-bit TIFF. JPEG, PNG and TIFF files can be edited too. So it is a developer, not a converter. The pipeline is read, develop, export, and the development controls are the point. The control list in the features section is long enough to be worth reading as a checklist against what a photographer actually does. Develop covers white balance and a picker, one-click Auto tone and Auto white balance, exposure and tone, Shadows and Highlights, Clarity, Dehaze, point curves and levels, the HSL color mixer, three-way color grading, detail for denoise and sharpening, crop, straighten and Transform, lens corrections, effects and calibration. Then there is a separate category for the newer work, spot removal and masks, marked experimental and early. It covers Heal and Clone spots and brushed areas with automatic sources, and brush, gradient and range masks with local adjustments, also imported from Lightroom. The parenthetical is blunt: not yet measured against Lightroom. That distinction between the two categories is the most useful thing in the feature list. The core develop controls are the ones with years of Lightroom behaviour behind them, and the masking and healing are the ones where the project is telling you not to trust a comparison yet. The library side is a SQLite catalogue with folders, ratings, flags, color labels and filtering, plus non-destructive Lightroom `.lrcat` import with folder relinking. And there is a built-in and a user-importable profile story: 26 built-in presets and your Lightroom XMP presets, RAWmakase's own Standard and Color profiles for every camera with a usable color matrix, plus DCP and XMP camera profiles you import yourself. The rendering parity claim is stated with precision. Rendering aims for close, not exact, Lightroom parity, and the project publishes a parity gaps document. The non-destructive guarantee is absolute, though: originals are never modified, edits live in the catalogue, and all writes are atomic. ## Previews on the GPU, with a CPU fallback The performance claim in the features list is specific about where the work happens. Every change renders at viewport size, with the color and tone stage on the GPU, using Metal on macOS, Vulkan on Linux, and DirectX 12 or Vulkan on Windows, and a CPU fallback. The structure of that sentence is the interesting part. It is the color and tone stage that is on the GPU, not the whole pipeline, which is a sensible engineering decision. The demosaic and the raw decode are the expensive, hard-to-parallelise parts and they stay on the CPU, while the adjustments are arithmetic on pixel values and they are the part that benefits from a shader. Putting a stage on the GPU means a second representation of the data, so the more stages you move, the more copying you do, and the colour and tone stage is where the interactive benefit is highest. The three graphics APIs are the three that matter for the three platforms, and the fallback is the part that makes the application usable everywhere, including on a machine with no working driver. The installation notes make the driver a requirement in practice, saying a working graphics driver is required and telling you to install your desktop's `xdg-desktop-portal` backend for native file dialogs. The render benchmark scripts in the repository show where the effort went. The `examples/` directory holds `preview_benchmark.rs`, `slider_benchmark.rs`, `stand_in_benchmark.rs` and `upright_lines.rs`. Two of those names are about the interaction rather than the image, a preview benchmark and a slider benchmark, which suggests the hot path is not the render itself but keeping up with a drag of an exposure slider while a preview updates. The `Makefile` gives the check target, and it is a strict one. It runs a Python dependency check with `python3 scripts/deps.py check`, a unittest discovery over `scripts/corpus`, a shell script called `scripts/crate-closures.sh`, then `cargo fmt --check`, two clippy runs with `-D warnings` including one with `--no-default-features`, and a set of `cargo test` invocations per crate. The crate split in the Cargo manifest is worth noting too. The workspace has nine members besides the root: rawmakase-catalog, rawmakase-engine, rawmakase-export, rawmakase-inference, rawmakase-interop, rawmakase-model, rawmakase-native, rawmakase-protocol and rawmakase-remote, plus a tools/rawmakase-ctl binary. The comment on the workspace says the control protocol and its command line client build on their own, without the app's GUI, GPU or native libraries, which is a deliberate separation so the automation surface does not drag in the rendering stack. ## The command line and the MCP server The automation story is the most unusual part of this project and it goes further than a CLI. The command line can inspect, render, export thumbnails, import catalogs and profiles, and benchmark, all without the GUI. And the `rawmakase-ctl` tool in `tools/` is a separate binary, which the manifest comment explains, since the control protocol and its command line client build on their own, without the app's GUI, GPU or native libraries. Then there is external control in three forms. MIDI controllers, scripts, and a built-in MCP server for agents to adjust the running editor, inspect previews, save and export. The MCP server is what makes this project different from every other RAW editor, and it is worth being precise about what it does. An agent can drive the actual application. It can adjust a running editor, look at the preview, save and export. That is not a scripting API over a headless renderer, it is control of the editor you are looking at. The manifest comment on the MCP dependency is careful about the boundary. The local MCP adapter uses `rmcp` with the server, macros and transport-io features and no HTTP server or remote authorization stack. So the protocol is local, which means the agent has to be on the same machine, and there is no exposed network surface to secure. That is a deliberate design choice and it is the right one for a tool that holds your photographs. The `rawmakase-remote` member is described separately, as the optional remote selection worker's client and the worker binary itself, and there is a dependency comment about verifying a downloaded or imported selection model against its pinned digest. So the selection work, whatever it is, is the part that can be remote and the part that needs integrity checking. The other external control paths are more conventional. MIDI controllers is a documented feature with its own documentation page, and scripts have a separate automation page. Both are ways to adjust parameters without the mouse, and both matter for a photo workflow where you might be comparing against a reference on a second screen. The repository also carries an `AGENTS.md` at the top level and a `deny.toml` for cargo-deny, which is the dependency licence and advisory checker, plus a `licenses/` directory with the text of every third party licence the binary ships. That last one is the practice that a project distributing a native imaging stack should follow, since LibRaw, Little CMS, Adobe DNG SDK and the font and icon licences all travel inside the package. ## Installing on each platform, and the Linux package matrix The download matrix is wide, and the per-platform instructions are specific about what you get. For macOS 15 or newer there is a Homebrew cask, `brew install --cask pch/tap/rawmakase`, updated with `brew upgrade --cask rawmakase`. Or you take the DMG directly, choosing `rawmakase-v-macos-arm64.dmg` for Apple Silicon or `rawmakase-v-macos-x86_64.dmg` for Intel, open it and drag RAWmakase into Applications. The release DMGs are signed and notarized and include their imaging libraries, so Homebrew is not required. For Linux on x86_64 and aarch64 there are three package formats and a table mapping them to distributions: ``` sudo apt install ./rawmakase__amd64.deb sudo dnf install ./rawmakase--1.x86_64.rpm sudo pacman -U ./rawmakase--1-x86_64.pkg.tar.zst ``` The baselines are Ubuntu 24.04 and later or Debian 13 and later for the deb, and Fedora 43 and later for the rpm. DEB and RPM packages include LibRaw and Little CMS, while Arch packages use system dependencies. There are also two tarball flavours. The `rawmakase---linux.tar.gz` download contains the same bundled imaging libraries as the deb and rpm packages, and you extract it and run `./usr/bin/rawmakase` from the extracted folder, keeping the whole directory together. It requires the same OS and runtime baseline and is explicitly not a fully static build. The AppImage is the same build as a single file, made executable with `chmod +x`, needing glibc 2.39 or newer, and on systems without FUSE 2 you run it with `APPIMAGE_EXTRACT_AND_RUN=1`. AUR publication is paused, and the workaround is given. On Arch Linux ARM you download and extract `rawmakase--arch-recipe.tar.gz` into an empty folder and build as a normal user with `makepkg -si`, and the development recipe is in `packaging/arch/rawmakase-git`. For Windows 10 or newer on x86_64 and 11 on ARM64, you run the installer executable, and it installs for your user account only, without administrator rights, and adds RAWmakase to the Start menu. There is also an Omarchy route, `omarchy pkg add rawmakase-bin`, which updates with the rest of the system, and an unusual one: a prompt you can hand to a coding agent to install the release for you, which asks it to pick the right package for the OS and CPU architecture, verify it against the release's checksums, install it, and report how to launch it. ## The warning about version 1.0, and what is not supported yet The project states its own status plainly, and it is worth reading the warning before installing anything. RAWmakase is early software in active development. The rendering engine may change from one version to the next, so photos you have already edited can look different after an upgrade. Until 1.0, backwards compatibility is limited and not guaranteed. Your originals are never modified, but keep exports of finished work. That is a real constraint and it is the kind that decides whether the software is usable for paid work. A photo editor whose rendering can shift between releases is fine for a hobbyist experimenting and unfit for a studio with a retouching SLA, because the deliverable is not reproducible unless you also keep the version it was rendered with. The camera coverage is stated with exceptions. It develops photos from almost every current camera, and the exceptions are Sigma's Foveon cameras, monochrome cameras such as the Leica Monochrom, and DNGs that are already demosaiced, which means linear DNGs such as merged HDR or panorama files. Each of those exceptions is a different kind of limitation. Foveon is a sensor architecture with an unusual colour filter array that most raw pipelines do not implement. A monochrome camera has no colour filter array to demosaic, so there is no colour to develop, and the colour and tone pipeline has nothing to work on. An already demosaiced DNG has been through the raw stage already, so running it through again is meaningless. The coming-soon list is short and reads like a roadmap of what a version 1.0 might include. LUT support, AI object removal, and agentic features such as culling assistance. That last one is worth a note, because the MCP server already exists and the culling assistance is described as agentic. So the direction is that the agent does not just adjust sliders on request but participates in the decisions, which is a different relationship with the tool from the one the rest of the feature list describes. Updates work in a specific way. The app checks GitHub for new releases, and the Apple Silicon and Windows installer builds update themselves, while other installs are pointed at the release page. The version history is fast. Version 0.3.0 was released on 2026-10-13, 0.3.1 on 2026-10-14 and 0.3.2 on 2026-10-15, which is a release every day for three days, consistent with the active development the warning describes. ## Conclusion RAWmakase fits a photographer who wants Lightroom-style RAW development and a Lightroom Classic catalogue on a machine that is not a Mac with Adobe, because the catalogue import brings ratings, flags, labels, keywords and compatible develop settings with it, and because the edits are non-destructive with atomic writes. Skip it if you need exact Adobe parity, since the project states that rendering aims for close and not exact Lightroom parity and publishes a parity gaps document, and skip it if you cannot accept that a rendering change in a new version alters photos you already edited. Before you install, check your camera against the supported list, because Sigma Foveon bodies, monochrome cameras such as the Leica Monochrom and already demosaiced DNGs are exceptions. The last push was on 2026-10-15 and the current release is 0.3.2. ## FAQ ### What is RAWmakase? It is a fast, non-destructive RAW photo developer for Linux, macOS and Windows written in Rust, which opens RAW files from the cameras LibRaw supports, develops them with a Lightroom-style control set, and exports JPEG or 16-bit TIFF, and it can also edit JPEG, PNG and TIFF files. ### Does RAWmakase import a Lightroom Classic catalogue? Yes. It can import a Lightroom Classic catalogue with its ratings, flags, labels, keywords and compatible develop settings, without ever writing to the original catalogue or your photos, and it also imports your Lightroom XMP presets and DCP and XMP camera profiles. ### Which cameras does RAWmakase not support? The exceptions are Sigma's Foveon cameras, monochrome cameras such as the Leica Monochrom, and DNGs that are already demosaiced, which includes linear DNGs such as merged HDR or panorama files. ### How does RAWmakase stay fast when editing? Every change renders at viewport size, with the color and tone stage on the GPU using Metal on macOS, Vulkan on Linux and DirectX 12 or Vulkan on Windows, with a CPU fallback. ### Can RAWmakase be controlled by an AI agent? There is a built-in MCP server that lets agents adjust the running editor, inspect previews, save and export, alongside MIDI controller support and scripting, and the command line can inspect, render, export thumbnails and import catalogs without the GUI. ## Sources - [License: MIT](https://github.com/pch/rawmakase/blob/main/LICENSE) - [pch/rawmakase on GitHub](https://github.com/pch/rawmakase) - [Project website](https://rawmakase.com) - [README](https://github.com/pch/rawmakase/blob/main/README.md) - [Releases](https://github.com/pch/rawmakase/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/pch-rawmakase