You can add the number at the end if the URL, e.g. https://discuss.pixls.us/t/agx-terminology-ui/53264/191
1 Like
Use the bar on the right, or in mobile at the bottom there is a number you can select and use it to scroll to the post.
1 Like
Sorry,
I am on desktop. the only thing I see is a vertical line with dates on it.
Oh I see it now. 
2 Likes
Wow you guys are quick to help. Thank you.
BTW, I already voted.
2 Likes
The polls have been closed, thank everyone, who participated!
The results:
I’ll update the code accordingly.
I’ll also add (well, keep, as I have already implemented it) the slider position indicator changes from Agx terminology (UI) - #218 by kofa.
In the other thread, we were discussing pivot x shift. If I can do it, I’ll convert it to a ‘relative to mid-grey’ absolute value (instead of shift towards white 20% or similar, you’ll get shift towards white by 0.7 EV, which is more understandable in photographic terms, and also won’t be affected if white / black relative exposures are changed – the current one is, as the proportions of the curve change).
I’ll get back to you when I have the code. Thanks again!
14 Likes
Here is a new build, and I’ll submit a PR based on this code.
- The sliders now have visual hints (hue, purity) as discussed;
- The hue and purity sliders look like in color balance rgb, not like in sigmoid / rgb primaries (there is no white stripe from the neutral position to the selected value, obscuring some of the visual hints)
- the black/white, toe / shoulder sliders have white/shoulder on the top, black/toe at the bottom:
- the module will read the exposure parameters if applied for the first time/reset, and make a guesstimate for the white/black point, similar to filmic rgb. Unlike filmic, the actual settings from the exposure module (compensate camera exposure, manually set exposure and the recently introduced compensate highlight preservation). This won’t be done automatically for HDR content (since HDR input can have much brighter highlights than what a sensor could capture, there is no point in imposing exposure limits calculated based on sensor-based heuristics), but you can still use the ‘camera’ icon if you want. The previous method (picking the limits based on image content) also remains:
- the pivot input (x) coordinate is now determined based on an EV offset from mid-grey, not as a percentage of the distance between mid-grey and black or white relative exposure. To reflect this, the slider has been renamed to pivot relative exposure.
The consequences:- the pivot’s distance from mid-grey remains constant, therefore if exposure limits are adjusted, the projection of the pivot remains the same (the same input levels are mapped to the same output levels as before). Previously, since the output remained unchanged, but the input changed, the mapping changed, and the region of highest contrast moved.
- the shape of the curve will change, reflecting the movement of the pivot relative to the mid-grey-to-end-of-exposure-range distance.
- pivot input (x) will still be enforced to stay inside the exposure range; if you shrink that so much that the pivot is forcibly moved (because it would fall outside the exposure limits), then expand the range again, the pivot will not be restored. For example: your black and white relative exposures were -8 EV and +5 EV. You set your pivot at mid-grey +2 EV. Then, you set a very low white exposure limit, like 1.5 EV → the pivot will be forced to 2 EV (minus epsilon). Then, you restore your white relative exposure to 5 EV → the pivot will remain at 2 EV.
- there are now 2 pivot pickers, since some disliked the idea of the pivot input (x) picker also adjusting the output, since that is done by calculating what the brightness would be if we used the default mid-grey → mid-grey mapping for the pivot. So, the picker next to pivot relative exposure only changes that slider. In order to set both the input and output value (as was done previously), use the new picker, placed next to pivot target output. This may be a bit confusing, at first, but if you think about it, it makes no sense to set the output using a picker without also saying the brightness of what region is to be set to that value. If you ever forget what each picker does, there are tooltips to help:
I hope I did not miss anything.
Note that, because of the parameter change (pivot x as percentage vs EV), the module version number will be updated, and you can’t go back to the previous one. This is a risk if you try the experimental build and the PR does not go through, or is changed in an incompatible way. I think the risk of that is low (there may be changes required how the exposure-based limits work, but that is unrelated to the rest of the changes).
Version info:
The code has been rebased on the current master, and includes all upstream changes up to and including:
commit e0001ac7273b80b644549ad9850331655424cda6
Author: Pascal Obry <pascal@obry.net>
Date: Sat Nov 1 18:43:28 2025 +0100
RELEASE_NOTES.md: picker issue due to coeff in colorin.
Branch: GitHub - kofa73/darktable at agx-ui-toe-shoulder-sliders-and-primaries-rotations
Linux AppImage:
https://tech.kovacs-telekes.org/dt-agx/Darktable-5.3.0%2B731~gf040bd2dea-x86_64.AppImage
@Dave22152 , @priort , @MStraeten : if you have the time, please provide updated builds.
8 Likes
Thank you!
One question: in the previous experimental built (I think it was in the poll post #188) you mentioned to use only one exposure module before AgX, otherwise the camera button will get ‘confused’. Has this been updated as well in this built?
We try to find earliest unmasked instance of exposure. We don’t check if it is before or after agx. As long as you have an exposure instance that comes before agx (in pipeline, not in history order), it will be used. Unmasked instances are preferred over masked ones (e.g., if you use a ‘global’ exposure instance to get the image in the correct midtone range, and then add a masked one to add or correct vignette, the unmasked one will be used).
If you have no unmasked instance, the very first instance will be used.
Only enabled instances are taken into account.
2 Likes
Fantastic. Thank you.
I will be honest with you. I was too anxious and excited to fully understand and digest the implications of the changes to the pivot inputs.
Am I correct to assume this limitation is because of dependency of the "auto tune levels eyedropper and camera buttons?
The picker always works: it uses the input of the agx module, actual image data.
The camera just tries to find a exposure instance. I could complicate the code even more to check the order of the modules, but:
- with the scene-referred workflow, you get an unmasked exposure module early in the pipe, and
- the result is just a heuristic estimate.
So I’d rather not jump through more hoops.
It is fine as is. I was curious as to why.
(post deleted by author)
That looks super, thanks for the detailed writeup.
Concerning the renamed “pivot input shift”: I am missing the “input” from the new name. I found that the input/output wording made it easier for me to grasp how these two are related. So maybe “pivot input exposure” makes sense. The fact that it might be “relative” and not “absolute” is secondary to the meaning in my opinion.
1 Like
It’s consistent with white / black relative exposure. There we don’t say input black / white relative exposure, either. But if others want to bring input back as well, it’s a trivial change.
There’s also another version, check the other branch.
Here’s the link to the Win 11 portable version of AgX Build 5.3.0-732-gd0f9dd5f0c:
I’ll try to build the alternate version a bit later.