AutoShade: an AI RAW developer that produces a recipe instead of pixels

The generated picture is a target, never the delivery

AutoShade's subtitle is Describe the picture. Keep the RAW, and the line under it is the whole thesis: AI decides what to change, a deterministic Rust engine does it, and the result is an editable, Lightroom-ready recipe instead of AI pixels.

The README states the rule in a highlighted tip, and it is worth quoting because it defines what the tool is: the generated picture is a target, never the delivery. An image model paints the look you describe, and AutoShade fits an editable develop recipe to it and renders that recipe on the full-resolution RAW. The recipe carries the look, the sensor carries the detail, and in the recipe path the AI never touches a pixel.

That constraint is unusual and it is the reason to care about the project. A generative fill or an AI denoise that rewrites the image gives you a picture you can like but cannot edit, and you have lost the original data. AutoShade instead treats the model's output as a specification, and the specification is a set of Lightroom develop settings, which means the result is non-destructive by construction rather than by promise.

The example images make the workflow concrete. The first shows a straight conversion, a generated target, the recovered recipe rendered on the 61 megapixel RAW, and the same recipe on the AI-denoised RAW, with a 1:1 detail row. The second shows one RAW developed four ways, where the only difference between the three AI develops is the direction text. A prompt like a clearer afternoon, a little more contrast, a slightly deeper blue sky produces a recipe that the engine renders on the 9504 by 6336 original.

The primary language is Rust, with the edition at 2024 and a pinned toolchain of Rust 1.94 in rust-toolchain.toml. The licence is MIT, the homepage is autoshade.dev, and the release history is fast: v1.9.0 on 2026-10-14, v1.8.1 and v1.8.0 the day before. The repository is not archived and the last push was on 2026-10-14.

Reverse-fit: recovering a recipe from a finished look

The mechanism is described as reimagine and match. The reimagine command generates a picture from your frame, and the match command recovers a recipe from it, or from any finished rendition of the same shot. The README quotes a look error of 0.161 going to 0.023, which is the fit quality before and after.

The phrase any finished rendition of the same shot is the part that widens the scope. The target does not have to come from this tool's generator. If you have a JPEG you like, of the same frame, the tool can fit a recipe to it, and the recipe then gets rendered on your RAW. That is the same operation as the generator case with a different source, and it is the more useful one for most photographers, because the looks people want usually come from other people's finished photos.

The second technique is described as an evidence-gated local fit, and the mechanism is a divergence score, D, that picks between a full solve and a bounded mode, with every local move having to earn its place. This is the part of the design that shows real engineering rather than a thin wrapper around a model. A reverse fit is an optimisation problem with a lot of degrees of freedom, and a naive optimiser will happily apply a large global curve to fix a small local discrepancy, producing a recipe that matches the target on average and looks wrong in places. A divergence score that measures how far the rendered recipe is from the target, used to decide whether to keep searching or to stop and bound the damage, is a mechanism for deciding when to give up.

The third technique is style by retrieval. Instead of a preset, the style reference is a retrieval over your whole catalogue. Point it at finished photos you love, and each develop sees the three closest as a reference, with SigLIP 2 search over your own finished photos. The embeddings run locally, which matters both for privacy and for the fact that a catalogue of your own work encodes a style that no preset captures.

The fourth is measured Lightroom parity, which is the claim a photographer would actually test. Tone, Texture, Sharpening, masks and lens geometry are fitted to Lightroom exports, with texture 45 out of 45 anchors within plus or minus 0.02 and radial masks 41 out of 41 within one pixel, and every residual published. The phrase every residual is published is the interesting part, because it is a commitment to showing the cases where the fit did not match, not only the average.

And the round trip is the test of the whole design: the sidecar XMP is merged byte for byte, and the full develop survives a Lightroom rewrite and reopens exactly. If the recipe is the deliverable, then it has to survive the round trip into the tool the photographer already uses.

One engine, three front ends, and six local sidecars

The architecture section explains the shape of the system, and it comes down to a single engine with several ways in.

One engine, three front ends: the desktop app, the CLI and the loopback web UI share one Rust library and one per-user develop store. The Cargo.toml shows the split in build terms, with a shared engine library linked by both front ends, a CLI front-end at src/main.rs, and a native desktop GUI built on egui and eframe at src/bin/gui/main.rs. The GUI binary is behind a gui feature, with the stated reason that a plain cargo build or cargo test should not pull in eframe, winit and the GL stack. The build is therefore `cargo run --features gui --bin autoshade-gui`, and the feature itself brings in eframe, egui, rfd, ab_glyph and eframe's persistence support, so the window geometry and the app's own preferences survive a restart.

The second bullet is local first: six Python sidecars, covering masks, two denoisers, correspondence, descriptions and embeddings, run on your machine, and pixels leave it only for an AI operation you ask for. The sixth feature is local AI masks with no API key, using subject, sky and point-prompted object segmentation with BiRefNet, OneFormer and SAM 2.1, plus HDR, focus and noise stacking.

The third bullet is the non-destructive guarantee: your photo library stays read-only, and generated pixels always land on their own labelled card. So a generated frame cannot quietly overwrite an original.

The repository layout matches. There is src/ for the Rust code, python/ for the sidecars, site/ for the web front end, installer/ for packaging, assets/, docs/, scripts/, build.rs, a rust-toolchain.toml, and an AutoShade-UI.bat, which is presumably how the sidecars are launched on Windows. The docs/ directory is where the substance lives, with a user manual, a showcase, an in-depth document and an architecture.json that the README says the diagram is generated from, so the picture and the design document cannot drift apart.

The sidecar approach is worth a note as a design decision. Six Python models running locally as separate processes, rather than one Python process with a model server, means each model can be loaded once and reused, and the Rust side talks to them over a protocol rather than through a Python runtime embedded in the binary. It also means the sidecars are individually replaceable and individually heavy, which is the cost.

The denoiser, and the pass marks written before the run

The RAW denoiser is described as trained here, and its evaluation method is the part worth reading.

The claim in the highlights is that the denoiser cleans the sensor mosaic before demosaic, and that it keeps 98.70 percent of 17,817 faint stars against Lightroom Denoise's 98.80 percent. The example image shows an ISO 2500 star field at 1:1 in four ways, with Lightroom's develop with Denoise off and at 50, and AutoShade's neutral develop with no denoise and with its own denoiser at the 71 percent default.

Two things are being demonstrated there. The first is the denoise-versus-no-denoise comparison, which is the classic argument: denoising removes noise and it also removes faint detail, and a star field is the pathological case where the faint things are all small and dim. The second is the 71 percent default, which is a different claim from the 50 percent used for Lightroom in the same image. It says the denoiser is applied at a strength where the stars survive, and that the strength is a default you can move.

The technical write-up describes the technique as a denoiser with pre-written pass marks, trained on this project's data, judged by pass marks written before the run. And it adds the sentence that makes the process credible: two later runs failed their marks and were refused.

That is a testing practice, not a feature, and it is a rare thing to see stated plainly. Writing the pass criteria before the run means you cannot retroactively move the goalposts to make a failed model pass, and refusing two runs means the criteria were actually binding. For a model that is trained on data the project generated, that is the difference between a benchmark and a measurement.

The sixth technique in the list is the camera's own look, a per-photo base curve read from the embedded preview, like with like. The rationale is that the RAW file carries a preview rendering made by the camera, and that rendering already encodes the camera's colour response. Reading the base curve from it means the develop starts from what the camera thought the picture looked like, rather than from a generic assumption, and it is per photo because the curve depends on the shot.

Building it, and the one decision that dominates the build time

The Cargo.toml carries a comment about the test configuration that is the most useful thing in the file for anyone building the project.

Tests compile optimised. The library battery is image arithmetic on real 2048-pixel frames, and unoptimised it spent 4014 seconds, on 2026-09-11 with 16 threads, with the three zoned-orchestration tests alone at 172.5 seconds. At opt-level 2 the same battery runs in 325 seconds and those three in 10.9 seconds, for a one-time 3 minute optimised compile. The debug-assertions and overflow-checks are inherited from the dev profile.

That is a 12x difference in test time, and the reason is a plain one: a development build of image arithmetic over megapixel frames is unusably slow, so the project enables optimisation for the test profile deliberately. The comments also record the specific cost, which is a three minute compile. For a project whose library is image processing, that is a reasonable trade and a useful thing to know before you first run the suite.

The build targets are declared explicitly rather than auto-discovered, with a comment explaining why: the GUI is a module tree rooted at src/bin/gui/main.rs after a round-12 split of the old single-file gui.rs, and its sibling module files, i18n.rs and model.rs among them, must never be picked up as separate binary targets since they have no main and autobins would fail. So autobins is false and both binaries are declared by hand.

The build and run commands are therefore:

cargo run --features gui --bin autoshade-gui

for the desktop application, and the CLI front end is the plain binary at src/main.rs. The toolchain is pinned in rust-toolchain.toml at Rust 1.94, and the package edition is 2024. The Cargo.lock is committed, so a build is reproducible.

For the Python side, the repository has a python/ directory and an AutoShade-UI.bat, and the README does not give a separate Python setup command in the visible text, so the sidecar launch procedure is in the documentation rather than the README. The build.rs file at the root suggests something is generated at build time, most likely for the sidecar sidecars or for embedded assets.

Where AutoShade is the wrong tool

There are three limits, and the first one is a deliberate non-feature rather than a gap.

The first is that AutoShade will not give you an AI-painted picture. That is the point of the design, and it is stated in capitals in the tip, but it means the tool is not for anyone who wants that outcome. If your goal is to produce an image that does not exist in the camera, a generative model used directly is the right tool and this one is the wrong one.

The second is the measurement dependency. The headline claims are parity numbers against Lightroom: texture anchors within plus or minus 0.02, radial masks within one pixel, and a look error of 0.023. Those are measurements against a specific version of Lightroom, exported from specific files, on a specific set of images. The README's insistence that every residual is published is the right instinct and also the scope limit, because a residual published for the authors' test set is not a guarantee for your camera, your lenses and your RAW files.

The third is the resource profile. Six Python sidecars running locally, two of which are denoisers, plus optional external AI services, plus a Rust engine that has to be fast enough to be pleasant while fitting a recipe. The demo works on 61 megapixel files, and the test battery takes 325 seconds optimised on 16 threads. A machine that runs the tool has to be a workstation rather than a laptop, and the first-run experience involves model downloads the README does not enumerate.

There is a fourth point about the AI boundary. The local first claim says pixels leave the machine only for an AI operation you ask for, and the feature list includes local AI masks with no API key, which is the good case. But the design also has opt-in external AI services, and the distinction between which operations stay local and which do not is the kind of thing a user needs to know precisely, especially for a photo editor handling unedited originals. The README states the boundary; the manual is where the detail would be.

AutoShade against doing it by hand in Lightroom

The alternative is not another program, it is the workflow you already have.

Doing it by hand in Lightroom means you look at a raw file, decide what is wrong with it, and adjust the sliders. Exposure, contrast, colour temperature, the curve, the local masks, the sharpening amount. It is slow, and the judgements are not always good, but the result is exactly a Lightroom develop, and nothing is fitted to anything.

The difference in approach is that AutoShade inverts the order. You describe the look in words, or you point at a finished picture, and the tool works out the recipe that produces it on your file. That is a different kind of interaction: you are specifying a target rather than adjusting a parameter. The one RAW, four looks case, where only the direction text changes between moody, golden and vivid, is the clearest statement of the idea, because in a manual workflow each of those is a separate set of slider decisions.

The second alternative is a preset, which is the same idea with the fitting replaced by lookup. Presets are fast and free, and they are wrong for your photograph, because a preset encodes one developer's decisions for a different scene. The style by retrieval feature is AutoShade's answer to that, using the three closest images from your own catalogue as the reference instead of a fixed set of adjustments.

The third is a general-purpose AI photo editor, and this is the comparison the project is arguing against rather than with. The argument is that those tools produce a picture rather than a develop, so you cannot refine the result, the result is not tied to your original, and the moment you want a different crop or a print of the same frame you are back to the beginning. AutoShade's answer is that the recipe is the artefact and the RAW is the source.

So the deciding question is about the relationship you want with the file. If you want to keep control of the develop and only need help deciding what to change, AutoShade is a different tool for the same job. If you want the picture to change beyond what the original contains, this is the wrong tool and a generative one is right. The recipe output is the part that decides it, and it is the part that is different from everything else in the category.

Editorial conclusion

Adopt AutoShade if you shoot RAW, you want to try a look before committing to it, and you want the result as an editable recipe in Lightroom rather than as an AI-generated picture. Do not adopt it if you want a photo that is not derived from your original file, because the design deliberately prevents that. Verify first that the Lightroom version you use matches the one the parity work was measured against, that the 24 RAW formats include your camera, and whether the AI features you need can run on the local sidecars or require an external service.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. skymanbp/autoshade on GitHub