Hacker News Reader

Comment by drdexebtjl | Hacker News Reader

To me the killer feature of Adobe’s offerings in this space is backwards compatibility. You can open a very old Lightroom library and the reprocessed photos look exactly the same.

The way they do it, unfortunately, is by maintaining every previous version of the processing pipeline.

How do the FOSS alternatives handle this?

If I was designing a raw engine I would try to store the high-level code for the processing pipeline in the metadata for each file such that it could be reproduced reliably across software versions and even forks. Like a sequence of shaders.

View on HN

Killer feature is intuitive UX. Using DarkTable was an exercise in frustration for me.

In darkroom mode you can’t navigate to other photos with cursor keys. Since the cursor keys do nothing else I have no idea why the aren’t bound to the nav. You have to double click on a photo to select it, one click does nothing so again I have no idea why not just bind single click to select. Then it recenters the entire row on what you selected, which I find disorientating but I suppose because you can’t navigate with cursor keys this recentering is necessary.

If you are willing to read the manuals and relearn everything it can do what it’s supposed to but the UX of LR is worth it to me.

Have you looked at the documentation? In Darktable you can click the questionmark, then click on any feature, and very extensive, well written documentation walks you through how, when and when not to use each module and feature.

Intuitive UX teaches you without asking you to read the documentation.

That said I don’t think the UX of LR and Photoshop is particularly good, especially in recent years. People just expect their skills to transfer over, but I don’t think FOSS should be doomed to clone the UX of proprietary software it seeks to replace.

The ansel fork seeks to remedy a lot of the bad design and workflow choices.

https://youtu.be/1R7gdfJVH9Q?si=a4WgcPt8q-aNSS2o

“Intuitive” implies “don’t need to read documentation”. That’s the entire point of my comment. There’s intuitive software and unintuitive software. This is unintuitive software. It’s not bad software, just unintuitive. I place value on intuitive software.

That's a legitimate complaint as a newcomer, but the darkroom navigation hotkeys are backspace and space.

Is delete key used for zooming

> The way they do it, unfortunately, is by maintaining every previous version of the processing pipeline.

A LOT of professional software does this. It’s one of the biggest moats they have to customers switching.

I’d pay to see what software like Parasolid does to manage fourty years of backwards compatibility (CAD models made 30+ years ago have to come out exactly the same).

Darktable editing workflow is centered around modules. Exposure, denoise, various color adjustments, etc are all separate modules. Dynamic range compression (and other common operations) has several implementations: base curve, filmic, sigmoid, and AgX. They all essentially do the same thing but have effectively superseded each other as they were added to newer releases.

Darktable keeps the old modules around but hides them, opening a file processed years ago will still go through the pipeline with the base curve module and come out the same. As a bonus, it is possible to use "obsolete" modules that may handle certain images better, achieving a particular look, or you are comfortable with the older module and prefer not to use the new replacement.

>How do the FOSS alternatives handle this?

In the same way, because there's no other way. Darktable in particular contains previous versions of the color pipeline. Every RAW software does that.

I just suggested a different way. Embed the pipeline’s actual code in the metadata.

This presumably doesn’t work for proprietary software because the pipeline’s code is a trade secret.

Proprietary software doesn't have any problem with embedded code, for example TTF does exactly that with fonts and they're still being licensed.

Code embedding has been considered many times but the rabbit hole is way too deep. You are embedding unverified executable code, to begin with. Then there's diversity problem: too much code, too many implementation specifics with every quirk being able to mess up the result. All of that spanning multiple generations of color science pipelines, experts, hardware, and third-party software to interact with. Since the advent of ML (for denoising and segmentation in particular) you have to also embed the weights as well, making it outright impossible.

All this leads to RAW processing code going the way of scientific and financial code: once written, it's frozen and the substrate is emulated if necessary. Even the bugs are preserved.

I don’t think TTF is a good example. You’re usually not allowed to embed and redistribute TTF code with your projects, only the resulting geometry, which is not subject to copyright in the US.

If you embed the image pipeline’s code in the user’s raw metadata, you essentially need to give them a perpetual license to that code, which isn’t a problem for FOSS.

Foss alternatives generally handle this by either not changing the format too much or by making old versions available to download in perpetuity and then you can manually upgrade your decades old library at your leisure. I'm really glad they don't spend their already limited resources on trying to handle every possible old library file under the sun, as long as you've got incremental upgrades working you've got a path. And if you are not using it on timescales that would allow for incremental upgrades you are not the ICP anyway so they've made a good engineering decision.

Right, but do these incremental upgrades preserve the look of the image? Or do they just keep the library accessible?

For example, increasing exposure in poorly lit adds noise, so you might counteract with a noise removal filter. Later on, the developers come up with a better exposure boosting algorithms that takes more sensor characteristics into account, and produces less noise.

Ideally, you’ll get this new algorithm on all new photos, but not the old ones. It’s unreasonable to expect you to go through all images you already processed and decrease the effects of the noise removal filters.

Or maybe you liked the noise on those pictures, and now it’s gone, and you need to add it back.

It’s a very reasonable to expect your photos to look the same long term.

Reply on news.ycombinator.com