This is the work of a former "darktable" developer (Aurélien Pierre) who decided to fork the codebase and go it alone. He has strong opinions about the correct way to do things. I like some of the cleanup on the UI that he has done. For now, Ansel and darktable are compatible in terms of the underlying database. So you can easily switch back and forth between them. If the fork diverges significantly, it would be more difficult to maintain the compatibility.
darktable has seen some major changes in the past few years, moving away from a "display-referred" to a "scene-referred" workflow. Aurélien contributed a lot of code to make that work, most significantly, the Filmic module. darktable is not as user friendly and as polished as other commercial tools (Lightroom, Affinity, Capture One) but it is capable if you take the time to learn it.
Aurelian's youtube channel is pretty insightful. He explains a lot of what is behind the scene referred modules. And as you say, he has been driving a lot of that work. I've been using Darktable for many years for all my photo editing and it has improved massively in the last few years. He does a great job explaining how raw file processing works (in any raw photo processing tool) and how Darktable does it.
Having come across his rants on Darktable last year, I think he does have a point on the UX front. A lot of the filtering in the light table (where you organize your photos) is a bit of a mess of confusing buttons, options, and weird convoluted abstractions. I never liked that part of the software. I can work with it but years in, it remains counter intuitive how you get your files in there and manage them. It's just convoluted and weird all over. A lot of bad ideas layered on top of each other. Aurelian kind of freaked out when last year some pretty major changes were just pushed through without much debate. And I agree with him, it didn't really improve much things.
Anyway the magic is in the darkroom part, which is the part where you edit photos. There is a wide variety of modules aimed at different expertise levels. Scene referred mode is basically a big upgrade over what a lot of other packages do, which is to blindly apply pre-defined curves for cameras without much regard for the actual pixels in the raw image. Filmic and other modules do this a bit more intelligently by actually looking at the pixels, using some heuristics and working from the lowest levels of the pipeline all the way up to do the right things. It adds up to a lot less work when editing photos for me compared to earlier versions. Mostly photos come out pretty OK without much tweaking. I might tweak perceptive saturation a bit, add some contrast in filmic, etc.
Basically, the workflow is roughly: 1) tweak the exposure as needed for the gray point. Filmic adapts with sane settings for black and white points and you typically don't have to tweak that. 2) add some contrast in filmic 3) maybe add some local contrast 4) in the color balance module fiddle with perceptive saturation. Done. There are a few more things I do for sharpening, profiled denoise (as needed), etc. But that's pretty much it. One nice thing is being able to apply defaults based on rules to photos.
I might play with Ansel a bit if I can find some time over Christmas. Kind of curious to see what he's done to lighttable and the rest.
I'm not familiar with the software, but generally, I get why he left to go do his own thing. I've made a few forks of a few projects over the years considering it.
I'm perpetually in the process of beating this dead horse, but FOSS would have so so many banging gold-standard user-facing apps if they enlisted the help of experienced UI or maybe UX designers and really worked to make them part of the community. To do their job right, they need to talk to the community to figure out what their needs are, and if maintainers shrug their shoulders while the few people who speak up are skeptically bikeshedding everything they say into oblivion, then we're also going to shrug our shoulders and walk away. That's what happened to me the several times I tried to contribute to various FOSS projects as a(n experienced, professional) designer rather than a(n experienced, professional, former) developer. Often, the response you get for merely intimating that something could work better if it was set up differently is like calling someone's kid ugly.
It would be like a team of civil engineers working on a restaurant design scoffing at an architect that specializes in restaurants offering to help make an effective kitchen layout. From the civil engineers' perspective, the architect's input is superfluous and would probably slow down progress. Meanwhile, everyone else that has to interact with that kitchen suffers.
On the flip side, coming from Darktable and trying out Lightroom felt like trying to do good old darkroom work with my hands tied behind my back.
Darktable offers a few really powerful, generic tools that you can use in different ways to get different effects – things like equaliser, parametric masks, LAB curves, etc. It makes little sense to use it without reading up on some of those more advanced tools first.
Lightroom, in contrast, focuses more on offering a small selection of pre-defined tools for specific purposes. But once you want to do something outside of that (parametric masking is one of those things I really missed) you're shit out of luck.
But as a Darktable user, I found the implementations of strong opinions frustrating because I value actual workflow above potential technical superiority.
Display referred worked fine for me because the important work happens before the shutter is clicked. The skill I want to develop is fixing things in the lens not fixing them in post.
Breaking changes suck.
But again open source developers don’t owe me anything.
I don't disagree, I spend a lot of effort thinking about things at exposure-time. I think the thing that sold me on scene-referred is that I started conciously thinking about the kind of data I was capturing. It's often the case that the display medium, or its artistic representation, has a much lower dynamic range than the sensor in the camera, and so there are a number of things you can do to get the most data possible when capturing to leave yourself room for expression at presentation time.
What this gives you isn't necessarily the ability to "fix" things in post, but the ability to decide how you want your image presented in a certain medium or format when "developing". Even master photogs like Ansel would take liberties when developing to realize their vision from the negatives they were able to capture.
The legacy editing workflows are generally, if not entirely, still available in Darktable. I haven't yet encountered a defect in my old edits on new versions of Darktable.
It absolutely is, it is what I use for RAW developing and post. Does everything, does it good and is, above all else, non-destructive.
It is, at least of I go by my dad who is a Photoshop veteran, quite different to what he used to.
The only things I could see as, if I am really really critical, are:
- sharpening, usually decent enough but SharpenAI from Topaz is another league. As I said, good enough for all except the edge cases
- de-noising, same as sharpening, astro-denoise works like a charm so
- masks, which I haven't really figure out yet, so my problem and not darktable's, Lightroom and Photoshop seem a tad more intuitive so
One thing I'd love, but again maybe I just didn't find it yet, is the possibility to export the database of picture edits. For now, I have darktable create dedicated files once a photonis edited and I make back-ups of those. I did loose edits for around 100ish photos due to some unrelated issues which required reinstallation of darktable so, which again was on me for missing darktable stopped creating said files after an update. Being to just dump the darktable database of edit data would be really nice so.
Summary, I can only recommend it. Especially for people starting post processing, the learing curve for each software is basically the same after all, and without prior knowledge they wont recognize any differences.
> "Ansel is what Darktable 4.0 could have been if its developers were not so busy turning it into an usability nightmare. Ansel is a Darktable 4.0 variant where 30.000 lines of poorly-written code and half-broken features have been removed, and 11.000 lines rewritten : it runs faster, smoother, uses less power and requires less configuration. Enjoy an app focusing on getting work done and stability."
This opinion comes from a former pho photographer, one who desperately wanted to love Darktable...the shots are warranted in my opinion. Darktable is a complete car crash of poor usability and militant contrarianism on established user experience design.
It has so much promise but the 'lead by committee' approach just resulted in some kind of collective 'demand avoidance' from the devs who seem to revel in delivering an unusable product. And I mean unusable for those not willing to learn an entirely new paradigm of interacting with a piece of photographic software and dive into the docs for everything, including stuff as silly as a keyboard shortcut or move between modules.
I've yet to read all the Ansel blurb but I'm pretty sure this is from the guy who's made the most improvements to Darktable in recent releases. So it's incredibly exciting to see.
I doubt it'll get any DAM capability though, even for a fork that is asking too much :-)
As a darktable user, I have to say none of that would motivate me to switch.
But then I care about the results, a nice picture to print or look at on a screen, way way more than about the tools used to get that result. Goes for cameras and lenses and whatnot as well.
> I have given 4 years of my life to the Darktable project, only to see it destroyed by clueless geeks playing code stashing on their spare time, everyone pushing his own agenda with no sense of design, in a project where nobody is responsible for anything and where we work too fast on everything at the same time.
Anyone know what happened to the Darktable project? I've only used it a few times, but it seems nice for someone who knows how to use it (which isn't me!) but curious what drama happened.
When I switched to Linux full time about a year ago, darktable was a godsend. I currently have it pointed at a NAS share with ~8k raw images and it works pretty flawlessly and I can barely tell that the images are offhost.
Personally, I really like a number of the features that this fork removed (like the timeline). The software does have a bit more of a learning curve than the commercial variants out there, but darktable is impressively capable and I personally jive more with its theory-based approach.
I _do_ agree that deprecating the display-referred mutations is a good thing, but the darktable documentation is already pretty adamant about scene-referred being the future; though there's no way people are going to go through their entire library and update their past tweaks from display to scene-referred, so I don't know that those modules can ever be removed.
I guess if I was going to be as petty as the author of this fork, I'd say that the Ansel logo looks awful.
The author is the "Dr. Rant" (his own words) of Darktable, so a lot of what he says is probably exaggerated. A lot of it isn't, though - Darktable does indeed lack focus and direction lately, leading to unnecessary bloat and unresolved issues. In other words, typical FOSS problems that sometimes lead to a fork.
Darktable is still going strong. I am a pro photographer and use it. I tried Ansel but most of the useful modules are removed and personally, I really don't care much for the "right way" of doing things from an engineering perspective. Darktable works and that's why I use it.
darktable is still being developed. There are pretty regular releases. I use it as my main photo processing software (raw-based workflow).
As I said in my other comment, Aurélien has strong opinions. He felt he could not effectively work with the other darktable devs and decided to fork the project.
That's kind of the nature of non-destructive editing. While I do think the operation stack could be smarter about collapsing edits that are commutative, once I got a workflow order down I haven't really worried about this much.
The documentation actually has a pretty good example workflow that flows through mutations in an order that makes sense for most cases. Though it's not really that simple, and so you'll find yourself trying to relearn each time if it's something you do only on occasion.
It’s not your fault. It has the worst UX of anything I’ve used. Be careful if you use the mousewheel anywhere, you don’t know what unexpected action it’s going to perform. Drawing vector shapes for masks is wildly frustrating too. It does have a lot of powerful modules though… and it’s free.
If you're using nix, I was able to make a build from the darktable derivation[0] modified to use fetchgit (since he hasn't made a github Release since December) and `s/darktable/ansel/g`.
I use Darktable quite extensively for underwater photos, but keen to try Ansel out and see if it's less friction.
An example of friction in darktable:
- I have an external strobe which means I have to put the exposure down to its lowest when shooting, otherwise everything is washed out. Darktable in newer versions has "Compensate camera exposure" on by default, which washes out all the images until I click it off. I'm sure there's a way to make this checkbox disabled by default, but why can't it accept what comes out of the camera?
- No favourites: there used to be a way to have all your panels in a favourites tab. This was great as I usually only use a handful of modules that I use. It's gone in later versions
- The "color balance" panel, not to be confused with "color balance rgb", it's not in any of the default tabs but useful for saturation adjustments. Why are some of these useful modules hidden? Shouldn't all modules be available by default. The only way you can get to it is by searching.
- White balance: there are now two modules and it warns you if you adjust one or the other: "white balance" the standard one on the "base" tab and "color calibration" tucked away on the "color" tab. Both modules are turned on by default, but if you adjust one or the other without turning one off it has a big red warning.
- One upgrade decided to reset export settings, and so my EXIF data was stripped out when exporting. It took me way too long to figure it out.
You can create a preset for the exposure module and define rules when it kicks in. For example based on the camera manufacturer, focal length, iso, etc. I use that to increase the default exposure compensation with my Fuji. I deliberately underexposes to prevent highlights from clipping. So I usually want a +1.25 exposure compensation. Likewise, you might want denoising on for high iso files.
You can organize modules into profiles and simply hide all the ones you don't use. The default profile hides some of the deprecated or display referred modules. You can change this.
White balance indeed has a deprecated variant for display referred and a scene referred one that works completely different that you typically use together with color calibration (which is where you should do most of your color correction, including color temperature changes). The reasons are mathematical and beyond me to explain properly (Aurelian does a great job on his Youtube channel). It boils down to not throwing away the baby with the bath water in terms of rounding errors accumulating and switching color model (to the one used by your display) too early in the pipeline. It might look pleasing but then it bites you when you want to tweak tone or do other things. This is the whole point of working with the scene referred modules.
Having all the legacy modules around is indeed somewhat confusing and Aurelian solves this in Ansel by hiding all the deprecated modules now. They are there for legacy files still.
My favorite photo development program remains lightzone, I find it has by far the most intuitive work flow that let's you achieve extremely advanced steps in a quite straight forward way (much of the functionality can be achieved in darktable but it's often very unclear how). I originally bought a copy but it has since been open sourced. Unfortunately it's photo management features are really subpar and development has been quite slow.
I wish I could use it just for the development and use something else for the management, but last time I tried that wasn't really possible. I have looked into contributing several times, but it's written in java and I really don't the have time to invest in getting up to speed first.
Somewhere very recently I encountered a quote from Ansel Adams, in which he seemed to anticipate that "electronic" photos would be the next big thing, in (IIRC) 1980. Wish I could find that again. Seemed remarkably prescient.
“There’s no end in sight. Electronic photography will soon be superior to anything we have now. The first advance will be the exploration of existing negatives. I believe the electronic process will enhance them. I could get superior prints from my negatives using electronics.
“Then the time will come when you will be able to make the entire photograph electronically. With the extremely high resolution and enormous control you can get from electronics, the results will be fantastic. I wish I were young again!”
I have only read The Negative, but from it I get the impression that Ansel Adams is really good at boiling things down to fundamentals and understanding the key concepts involved in things (much like I gather Elon Musk can be, I suppose). I'm not surprised he was able to grasp the benefits of digital photography also.
Electronic imaging in terms of television has been around since the 1940s or 50s. We all watched Neil Armstrong walk on the moon. It was a pretty safe bet that resolution would get better until it exceeded film.
In early 2000 a lot of photographers were saying that digital photography is not "real", it doesn't have a "soul", it should not be allowed in photo contests and it's just worthless in general.
To be fair, early-2000s digital cameras were ... not great. 4 megapixels if you're lucky (not that megapixels are the only thing that matters, but they do matter, up to at least 20 megapixels).
Looks good, I'll give it a whirl. I could never figure out a good darktable workflow. The UI seemed all over the place with some basic features missing and way too bloated in certain areas that I imagine 99% of users would never touch. Hopefully Ansel has figured out a better feature balance and UI.
My current Linux photo processing tool is Another RawTherapee [1], which is a wonderful blend of the power of RawTherapee with a UI that has a lot of similarities to Lightroom.
I also throught of ART as a fork of RawTherapee, also forked with the aim to make it easier to use.
I wondered if that is something hard to avoid: Over time features get added, usability worsens. This might be general, but it could apply to FOSS in particular, which often takes a modular approach (cue UNIX philosophy) and rarely includes structures where potentially useful features are rejected in order to keep the whole experience simple.
Yeah, I guess there's a point where starting afresh is beneficial to refocus. A bit different, but it's the same for institutions too. I know some countries have "sundowner" clauses on every institution, where they need to apply for a permit to continue operating every 10 years or so. Provides a good point to think "is this working and still serving its original purpose?".
I can't get this to build for MacOS, has anyone succeeded? I ran the brew commands from the mac-nightly CI script, did `git submodule init; git submodule update` and get this error running `build.sh`:
```
$ sh build.sh --build-type Release --install --sudo --clean-all;
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX14.0.sdk/usr/include/cups/http.h:39:
/Library/Developer/CommandLineTools/SDKs/MacOSX14.0.sdk/usr/include/netinet/ip.h:189:2: error: unknown type name 'u_char'
u_char ipt_code; /* IPOPT_TS */
Did you see the OS Support section in the README [0]?
I tried for about 15 minutes and didn't get it to build. And even if it did, it would probably not be stable enough to use for anything productively.
Readit News
darktable has seen some major changes in the past few years, moving away from a "display-referred" to a "scene-referred" workflow. Aurélien contributed a lot of code to make that work, most significantly, the Filmic module. darktable is not as user friendly and as polished as other commercial tools (Lightroom, Affinity, Capture One) but it is capable if you take the time to learn it.
What is that?
Edit: they have a page about it: https://ansel.photos/en/workflows/scene-referred/
https://www.youtube.com/@AurelienPIERREphoto/videos
I had no idea he was working on this.
Having come across his rants on Darktable last year, I think he does have a point on the UX front. A lot of the filtering in the light table (where you organize your photos) is a bit of a mess of confusing buttons, options, and weird convoluted abstractions. I never liked that part of the software. I can work with it but years in, it remains counter intuitive how you get your files in there and manage them. It's just convoluted and weird all over. A lot of bad ideas layered on top of each other. Aurelian kind of freaked out when last year some pretty major changes were just pushed through without much debate. And I agree with him, it didn't really improve much things.
Anyway the magic is in the darkroom part, which is the part where you edit photos. There is a wide variety of modules aimed at different expertise levels. Scene referred mode is basically a big upgrade over what a lot of other packages do, which is to blindly apply pre-defined curves for cameras without much regard for the actual pixels in the raw image. Filmic and other modules do this a bit more intelligently by actually looking at the pixels, using some heuristics and working from the lowest levels of the pipeline all the way up to do the right things. It adds up to a lot less work when editing photos for me compared to earlier versions. Mostly photos come out pretty OK without much tweaking. I might tweak perceptive saturation a bit, add some contrast in filmic, etc.
Basically, the workflow is roughly: 1) tweak the exposure as needed for the gray point. Filmic adapts with sane settings for black and white points and you typically don't have to tweak that. 2) add some contrast in filmic 3) maybe add some local contrast 4) in the color balance module fiddle with perceptive saturation. Done. There are a few more things I do for sharpening, profiled denoise (as needed), etc. But that's pretty much it. One nice thing is being able to apply defaults based on rules to photos.
I might play with Ansel a bit if I can find some time over Christmas. Kind of curious to see what he's done to lighttable and the rest.
I'm perpetually in the process of beating this dead horse, but FOSS would have so so many banging gold-standard user-facing apps if they enlisted the help of experienced UI or maybe UX designers and really worked to make them part of the community. To do their job right, they need to talk to the community to figure out what their needs are, and if maintainers shrug their shoulders while the few people who speak up are skeptically bikeshedding everything they say into oblivion, then we're also going to shrug our shoulders and walk away. That's what happened to me the several times I tried to contribute to various FOSS projects as a(n experienced, professional) designer rather than a(n experienced, professional, former) developer. Often, the response you get for merely intimating that something could work better if it was set up differently is like calling someone's kid ugly.
It would be like a team of civil engineers working on a restaurant design scoffing at an architect that specializes in restaurants offering to help make an effective kitchen layout. From the civil engineers' perspective, the architect's input is superfluous and would probably slow down progress. Meanwhile, everyone else that has to interact with that kitchen suffers.
Darktable offers a few really powerful, generic tools that you can use in different ways to get different effects – things like equaliser, parametric masks, LAB curves, etc. It makes little sense to use it without reading up on some of those more advanced tools first.
Lightroom, in contrast, focuses more on offering a small selection of pre-defined tools for specific purposes. But once you want to do something outside of that (parametric masking is one of those things I really missed) you're shit out of luck.
But as a Darktable user, I found the implementations of strong opinions frustrating because I value actual workflow above potential technical superiority.
Display referred worked fine for me because the important work happens before the shutter is clicked. The skill I want to develop is fixing things in the lens not fixing them in post.
Breaking changes suck.
But again open source developers don’t owe me anything.
What this gives you isn't necessarily the ability to "fix" things in post, but the ability to decide how you want your image presented in a certain medium or format when "developing". Even master photogs like Ansel would take liberties when developing to realize their vision from the negatives they were able to capture.
It is, at least of I go by my dad who is a Photoshop veteran, quite different to what he used to.
The only things I could see as, if I am really really critical, are:
- sharpening, usually decent enough but SharpenAI from Topaz is another league. As I said, good enough for all except the edge cases
- de-noising, same as sharpening, astro-denoise works like a charm so
- masks, which I haven't really figure out yet, so my problem and not darktable's, Lightroom and Photoshop seem a tad more intuitive so
One thing I'd love, but again maybe I just didn't find it yet, is the possibility to export the database of picture edits. For now, I have darktable create dedicated files once a photonis edited and I make back-ups of those. I did loose edits for around 100ish photos due to some unrelated issues which required reinstallation of darktable so, which again was on me for missing darktable stopped creating said files after an update. Being to just dump the darktable database of edit data would be really nice so.
Summary, I can only recommend it. Especially for people starting post processing, the learing curve for each software is basically the same after all, and without prior knowledge they wont recognize any differences.
Shots fired!
It has so much promise but the 'lead by committee' approach just resulted in some kind of collective 'demand avoidance' from the devs who seem to revel in delivering an unusable product. And I mean unusable for those not willing to learn an entirely new paradigm of interacting with a piece of photographic software and dive into the docs for everything, including stuff as silly as a keyboard shortcut or move between modules.
I've yet to read all the Ansel blurb but I'm pretty sure this is from the guy who's made the most improvements to Darktable in recent releases. So it's incredibly exciting to see.
I doubt it'll get any DAM capability though, even for a fork that is asking too much :-)
The whole "if you don't like how a program works, you can fork it and change it" thing.
Amazing to see this actually working in practice. You might not like Ansel, but he does, and more power to his elbow!
But then I care about the results, a nice picture to print or look at on a screen, way way more than about the tools used to get that result. Goes for cameras and lenses and whatnot as well.
Deleted Comment
Anyone know what happened to the Darktable project? I've only used it a few times, but it seems nice for someone who knows how to use it (which isn't me!) but curious what drama happened.
Personally, I really like a number of the features that this fork removed (like the timeline). The software does have a bit more of a learning curve than the commercial variants out there, but darktable is impressively capable and I personally jive more with its theory-based approach.
I _do_ agree that deprecating the display-referred mutations is a good thing, but the darktable documentation is already pretty adamant about scene-referred being the future; though there's no way people are going to go through their entire library and update their past tweaks from display to scene-referred, so I don't know that those modules can ever be removed.
I guess if I was going to be as petty as the author of this fork, I'd say that the Ansel logo looks awful.
That's a far cry from what I'd find acceptable in any project.
As I said in my other comment, Aurélien has strong opinions. He felt he could not effectively work with the other darktable devs and decided to fork the project.
Are you referring to the fact of there being no releases in the last year or so?
Edit: Ignore the above - it's incorrect.
4.4 was released in June 2023: https://www.darktable.org/2023/06/darktable-4.4.0-released/
4.6 is slated for December 2023: https://github.com/darktable-org/darktable/blob/master/RELEA...
Their release schedule has been remarkably consistent.
The documentation actually has a pretty good example workflow that flows through mutations in an order that makes sense for most cases. Though it's not really that simple, and so you'll find yourself trying to relearn each time if it's something you do only on occasion.
[1] https://github.com/NixOS/nixpkgs/issues/269535
An example of friction in darktable:
- I have an external strobe which means I have to put the exposure down to its lowest when shooting, otherwise everything is washed out. Darktable in newer versions has "Compensate camera exposure" on by default, which washes out all the images until I click it off. I'm sure there's a way to make this checkbox disabled by default, but why can't it accept what comes out of the camera?
- No favourites: there used to be a way to have all your panels in a favourites tab. This was great as I usually only use a handful of modules that I use. It's gone in later versions
- The "color balance" panel, not to be confused with "color balance rgb", it's not in any of the default tabs but useful for saturation adjustments. Why are some of these useful modules hidden? Shouldn't all modules be available by default. The only way you can get to it is by searching.
- White balance: there are now two modules and it warns you if you adjust one or the other: "white balance" the standard one on the "base" tab and "color calibration" tucked away on the "color" tab. Both modules are turned on by default, but if you adjust one or the other without turning one off it has a big red warning.
- One upgrade decided to reset export settings, and so my EXIF data was stripped out when exporting. It took me way too long to figure it out.
You can organize modules into profiles and simply hide all the ones you don't use. The default profile hides some of the deprecated or display referred modules. You can change this.
White balance indeed has a deprecated variant for display referred and a scene referred one that works completely different that you typically use together with color calibration (which is where you should do most of your color correction, including color temperature changes). The reasons are mathematical and beyond me to explain properly (Aurelian does a great job on his Youtube channel). It boils down to not throwing away the baby with the bath water in terms of rounding errors accumulating and switching color model (to the one used by your display) too early in the pipeline. It might look pleasing but then it bites you when you want to tweak tone or do other things. This is the whole point of working with the scene referred modules.
Having all the legacy modules around is indeed somewhat confusing and Aurelian solves this in Ansel by hiding all the deprecated modules now. They are there for legacy files still.
I wish I could use it just for the development and use something else for the management, but last time I tried that wasn't really possible. I have looked into contributing several times, but it's written in java and I really don't the have time to invest in getting up to speed first.
https://petapixel.com/2022/07/30/ansel-adamss-interview-with...
“There’s no end in sight. Electronic photography will soon be superior to anything we have now. The first advance will be the exploration of existing negatives. I believe the electronic process will enhance them. I could get superior prints from my negatives using electronics.
“Then the time will come when you will be able to make the entire photograph electronically. With the extremely high resolution and enormous control you can get from electronics, the results will be fantastic. I wish I were young again!”
Ah, the oft-repeated refrain of those who never stop learning.
My current Linux photo processing tool is Another RawTherapee [1], which is a wonderful blend of the power of RawTherapee with a UI that has a lot of similarities to Lightroom.
[1] https://discuss.pixls.us/c/software/art/36
I wondered if that is something hard to avoid: Over time features get added, usability worsens. This might be general, but it could apply to FOSS in particular, which often takes a modular approach (cue UNIX philosophy) and rarely includes structures where potentially useful features are rejected in order to keep the whole experience simple.
``` $ sh build.sh --build-type Release --install --sudo --clean-all;
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX14.0.sdk/usr/include/cups/http.h:39: /Library/Developer/CommandLineTools/SDKs/MacOSX14.0.sdk/usr/include/netinet/ip.h:189:2: error: unknown type name 'u_char' u_char ipt_code; /* IPOPT_TS */
```
...etc
[0] https://github.com/aurelienpierreeng/ansel#os-support
I don’t mind a few gtk bugs.