-
-
Notifications
You must be signed in to change notification settings - Fork 22
Home
Welcome to the Ansel wiki!
The philosophy of Ansel is :
If it's half working, then it's fully gone.
Ansel is a darktable fork with 22229 lines of bad code, bugs and ill-designed features removed. (Updated 19th July 2022)
Only the general-purpose and robust features have been kept, in order to focus on efficient image-processing and reduce the overhead:
- It runs slightly faster than upstream darktable: although not the ultimate goal, removing GUI events leads to less CPU load
- It provides a minimal set of tools and simplified GUI and doesn't overwhelm users with loads of geeky options which don't make them more productive.
- It solves the long-standing problem of re-inventing basic GUI interaction in ways that are inconsistent with every operating system and desktop environment out there.
- It keeps pixel code and pipeline compatibility with upstream darktable 4.0: you have the choice of your UI, you keep the compatibility of your edits. Compatibility is lost at darktable 4.2 which contains nonsense that will stay the burden of the darktable idiots only.
The reasons for having forked are detailed here:
- Why a fork ?,
- Open source and professional photography : lies and wishes,
- Design by committee will not save FLOSS.
TL; DR : darktable stability, usability and code quality have degraded too much these past years due to the lack of management and working method, bugs get merged faster than they get fixed, and it's impossible to keep up with the pace at which technical debt is introduced. There is no uniform line of development, but a collection of random contributions from random people who pop up at random times to push new pet projects. This way of working is simply unsustainable since darktable has become an high-traffic project and incurs only stress and frustration on my side. I simply don't put my name on shit.
- It does not aim at making darktable faster : the pixel pipeline code is exactly the same, and darktable already has a pipeline as fast as it will ever be under the architecture and design chosen in 2009. Improving performance is the goal of vkdt, which will not be ready for production for at least a couple of years, and is a full rewrite with a different pipeline. But, of course, removing GUI bloat is going to speed some things up.
- It is not a beginner-friendly photo-editing app : the goal is to simplify the overhead, meaning everything not directly related to outputting processed images. That is software configuration/options, GUI disposition, file management, labels, etc. Color science is still what it is, and boy, it's no easy.
- It is not a community project : community is great, except when it grows too much too fast and you don't have any kind of management to keep a unified line of development and a consistent design. More people means more help until you reach a team of 4-5, above this you need to allocate resources to management, so more people means more work. This is exactly what has happened to darktable: lots of hype since v3.0 leading to 2 releases/year with almost 2000 commits in each, so everything gets merged too soon and more bugs are introduced than fixed at each release, all that to keep momentum.
- It is not a hot project : I consider darktable's development (and therefore R&Darktable's one) roughly 90% finished, meaning it's close to feature-complete. We are reaching the limits of its initial design & architecture regarding how much we can still extend it without actively harming performance and stability. The goal right now is to polish existing features, fix the worst usability pain points and the low-hanging fruits, then keep it stable pending vkdt's availability. But the darktable's team does not want to hear it and wants to keep adding as much as possible in it.
See also : The future of darktable.
https://ansel.photos/en/support/
(Updated January 18th 2023).
The immediate goal for now is:
- publish a 4.0 version compatible with upstream darktable 4.0 pipeline (modules),
The mid-term goal is:
- to rewrite the module groups with something simpler with fixed modules layout, closer to what was in darktable 3.0,
- remove some options from the great MIDI turducken (at least the triple click thing and the shortcuts for Gtk notebook tabs… the shortcut window is currently a nightmare to configure due to way too many possible shortcuts).
The long-term goal is anyway to transition to vkdt, which simplifies the pipeline (GPU-only, full-resolution rendering – no heuristics), breaks free from the performance bottleneck that is Gtk by using Imgui (low-bloat and running straight on GPU), and keeping GUI code really separated from pixel code. Because darktable's core has deep design flaws that have no foreseeable solution under the constraint of preserving compatibility with older edits, so the only solution is a rewrite.
That is to say, I will pick here the low-hanging fruits, fix what can be easily fixed, to build a reliable tool usable while we wait for vkdt to be mature enough for production.
© 2022 - Aurélien PIERRE