I haven’t been able to follow this post step by step, but I’ve seen how @kofa’s creation—adapting Blender’s AgX to darktable—has delivered exceptional results. With each update, the advancements made by @kofa have left me in awe, and like many users/developers here, I appreciate the contributions to this excellent program. The possibilities of this module are vast, and thanks to the input and suggestions from @s7habo and other users testing the module, we’re witnessing a Proof of Concept (POC) gain momentum, evolving from an idea into a more solid project.
Regarding the UI design of the module—and this is just my humble opinion (I’m not a programmer)—I’d like to share an idea, which may or may not be worth considering.
The module currently has the necessary sliders to achieve detailed tone mapping, perhaps not as extensive as Filmic RGB (which can become complex due to its many functions) but closer to Sigmoid in terms of the options it provides (I’m commenting on the UI, not the module’s functionality).
I believe the module should focus on including only what’s essential to achieve its purpose without overcrowding the interface with sliders or expanding its size. For example, displaying the curve isn’t inherently bad, but in this case, the curve is purely informational, as users can’t interact with it directly like in other software—or even elsewhere in darktable, such as the tone equalizer or color equalizer. In the latter, I particularly like how nodes on the curve can be adjusted, while keeping advanced, precision controls hidden (these can be toggled via middle mouse button: “You can also adjust the color nodes using sliders, which can be shown/hidden by middle-clicking on the curve adjustment section of the module.”) Look at Tone Equalizer proposal - #9 by difrkaguilar
In this module, since the curve isn’t modified via direct interaction (only through precise sliders), hiding the curve entirely—or not displaying it at all—could result in a cleaner UI. This would better accommodate users on laptops or screens with 1920x1080px resolutions.
The curve is always on top and not collapsed. Let’s keep this consistent in darktable if possible. If we want to change this for good, then it should be consistent across all dt modules and part of another PR.
I firmly believe that for less experienced/knowledgeable people seeking to build their competence in darktable, it will be a clear asset to have the option to watch the curve for a stringent visualization so as to better understand the sliders’ impact.
I also use the curves in e.g. filmic and tone equalizer as a “sanity check”: it’s easy enough to hit a combination of settings that is not doing what you want. Viewing the curve has often given me a hint what went wrong.
Personally, the curve isn’t that important to me. But that’s because I spent a lot of time going over grey scale sweep images and playing with each slider to gain an understanding of what each control does and how they interact with one another. I doubt most users are inclined to do that. Some of this could be mitigated with a detailed description in the user manual and module videos as they come out.
Quick suggestion: maybe it would be easier to rebase your changes on top of the darktable master one.
Your current branch mixes commits from darktable and yours, and it’s not easy to follow your work.
The day you’ll want to create a PR, you’ll probably have to do that work.
Is anyone else on Windows having issues with resizing the graph? Whenever I try to reduce the size, it glitches out and the module’s elements disappear. They then reappear when I mouse over them. I did a fresh install, but it’s still happening.
Thanks for the suggestion. I’m aware of the difference. For now, I’ll stay with merging upstream changes. The ‘problem’ with rebasing (it’s not a problem, per se, rather a feature) is that it rewrites history. So, if someone comes to me saying something worked fine in Darktable-5.1.0+585~g791110d2b3-x86_64.AppImage, but is broken in Darktable-5.1.0+656~gde4613e6e7-x86_64.AppImage, I can easily check those commits. In the beginning, I used rebase, so now if someone said something about 10ac2ef45b, you wouldn’t find that commit on GitHub any more (I actually still have it in my local copy, until git decides to clean up its database, so I was able to find that it’s the commit that ended up with hash 8d539b79b43 after a rebase).
Once it’s ready for an MR, I’ll squash and rebase everything. Until then, this is less risky. My commits are easy enough to find based on my user name.
I nuked my DT-AGX-TMP folder and its contents. Started again from scratch with a freshly re-downloaded appimage and a wrapper script to launch it and all seems to be working albeit with some DT UI changes that I was not expecting (Module presets in a hierarchy rather than all listed etc etc- but not relevant to AGX). I have no idea as to what caused the problem.
As soon as I do Shift + Alt + Scroll, I completely lose the graph and all the graphical elements. I’ve deactivated OpenCL but the same problem occurs. The annoying thing is that there’s no way for me to get the graph back, and the only fix is a full reinstall. Is there a way to manually tweak a file to get the graph back or completely reset the module?
Indeed, this is probably easier for users than a rebase. This makes the history a bit confusing, but help bisecting in case of problems.
Anyway, I made a Fedora copr parallel installable with the default darktable, I’ll be happy to test
I added a patch to use different config folders and avoid mistakes.
@kofa Can the “Look” area be defined more simply to avoid having to stretch the module in order to see descriptions?
I don’t think it’s necessary to include (decrease (-) or increase (+) or (deepen (-) or lift (+). I think that would be obvious if the “Power” slider was reversed whereby it would act like the “Slope” slider when moved left to right, - or +. In general my impression is that most people expect that moving sliders to the right, increases and to the left, decreases.
“Slope” has both contrast and brightness and “Power” has brightness which I find confusing. Is “Slope” regulating the white point or contrast and brightness?
Could the “Power” slider be described as “contrast in medium gray”.
should the picking of the white and black point be automatic by default (until disabled)?
some of you have written that the auto-picker makes the slope and the offset unnecessary; should those be removed?
how about a default set of controls that contains only saturation (from the looks section) and contrast (from the tone mapping section) (if the relative black/white exposure is automatic)?
I just tried this myself and still didn’t have any problems. I placed the cursor over the graph and did the shift-alt-scroll sequence and the graph opens and closes as I expect.
