MattzDev
Online
•
Upload & Sell: Off
|
 p.1 #3 · Browser-based RAW editing — how important is the editing experience vs. the RAW engine? | |
Hi ruthenium,
Thank you — this is the most useful feedback i've had. You've found something real, and you've diagnosed it correctly, so let me answer precisely rather than reassuringly.
Tone selectivity — you're right, and here is exactly why
Blacks and Whites in Rawnd are not selective at all today. They're a levels-style remap: Blacks subtracts a black point in linear light, Whites divides by a white point, and the whole scale is renormalised between the two. No tonal mask is involved, so by construction the adjustment rescales the entire tonal range. That is precisely the global contrast shift you saw. In Capture One, Black is a narrow, feathered adjustment that tapers to nothing before it reaches the Shadows. Ours has no taper at all.
Highlights and Shadows do have masks, but they're far too wide: each ramps from middle grey out to its own end of the scale. Shadows covers everything below middle grey, Highlights everything above — half the picture each, meeting in the middle. Hence "crude". C1's are much tighter.
The specific thing you noticed — not being able to lift the blacks — has a second cause stacked on top. Rawnd applies a base curve measured from the camera's own rendering, and that curve has a toe that darkens the bottom fifth of the range. So you lift the black point in linear light, and then the toe puts most of it back. The control is fighting the curve underneath it.
What we're changing: give Blacks and Whites their own narrow, tapered masks confined to the ends of the scale, so Blacks stops before the Shadows and Whites before the Highlights; and narrow the Highlights/Shadows ramps so they fall to zero before reaching the midtones. Being able to grade exposure without reaching for a mask is the entire point of those controls, and today ours don't earn it. This is at the top of the list.
Double-clicking a slider to reset
Fair. Double-click already resets — but only on the slider's label, which isn't discoverable. (The label is also a scrub handle, by the way: drag it left/right for much finer control than the track gives you, Shift for 5× finer.) Extending double-click to the track and the handle is a small change and we'll do it.
Is the Curve RGB or Luma?
RGB. One composite curve, applied to R, G and B through the same lookup table, in display-referred space after the base curve and contrast. So it behaves like Photoshop's composite RGB curve: an S-curve raises saturation along with contrast. There's no Luma mode and no per-channel R/G/B curves yet. Both are planned — Luma especially, since it's the one you want when shaping contrast without touching colour.
EXIF and colour space
Both correct, and both worth being blunt about.
EXIF: Rawnd reads it — camera, lens, shutter, aperture, ISO, focal length, exposure compensation, capture date, orientation; it's in the info bar. But the export path encodes through the browser's canvas encoder, which writes pixels and nothing else. The metadata is in hand, we simply don't write it back into the file. That's a bug, not a decision, and a fixable one.
Colour space: exported JPEGs are sRGB — the pipeline converts camera-native to linear sRGB through the camera matrix and encodes sRGB at the end. Slightly worse than you assumed, though: the file is untagged sRGB, with no ICC profile embedded, so a colour-managed application has to guess. Embedding the sRGB profile is the immediate fix. Offering Display P3 and Adobe RGB is the real one, and it requires carrying a working space through to the encoder instead of hardcoding sRGB.
Why a browser rather than an app?
The honest answer is that we built the app first. Rawnd started as a Rust desktop application (Tauri). When we looked at what the native shell was actually contributing, the answer was: a window. The RAW decoder, the render engine, the shaders, the whole UI already ran inside a webview. Fifty-nine of sixty-two source files moved to the browser build unchanged. We weren't trading native performance for convenience — the "native" app was a web app in a costume.
What that buys:
Nothing is uploaded, ever. The decoder is a WebAssembly module running inside your page; your edits live in local browser storage. There is no server that sees your files. People assume the opposite, so it's worth saying plainly.
No installer, no update cycle, no per-platform builds. You open a URL and you're editing.
It still installs as an app if you want one. Rawnd is a PWA: install it and it runs fully offline, registers itself for fifteen RAW extensions, and double-clicking a .NEF opens it. Same icon in your dock, no app store.
What we give up, and I'd rather tell you than let you find it: we reach the GPU through WebGL2 rather than Metal or CUDA; a browser tab has a memory ceiling a native process doesn't; and we have no access to your display profile — which is the same limitation sitting behind the sRGB-only export. For very large batches, a native app still wins.
For the work Rawnd is actually for — getting through a shoot, culling, grading — the browser costs nothing that matters and removes a lot of friction. And if we ever hit a wall where it does matter, the engine is portable. It ran in a native shell once already.
Thank you again, genuinely. Comparing two JPEGs and locating the difference in where the adjustments act is a far more useful report than "it looks worse". If you're willing, I'd like to send you a build once the tone controls are reworked, and hear whether it holds up against C1 on your own files.
Best,
Matthieu
|
