It’s a general darktable thing. With filmic, too, if you switch the workflow to agx or sigmoid, there is no scene-referred default preset, and the controls are set to some default values:
I guess what I can do is to hard-code the sliders to the values of the scene-referred default values, or otherwise handle the ‘reset’ event. You’ll have to bear with me, this is my first module, I don’t know how these work.
I’d open an issue, I’m sure @Pascal_Obry or @hannoschwalm can get you pointed in the right direction.
In your code you have the unmodified values as the defaults so I would guess the reset is always going to give those as it is. Then there was code that if agx was the workflow to use the modified primaries… Is this necessary…should the defaults for the module not just be determined and applied by default…And of course there is a preset to get to unmodified primaries???
Sorry, issues with video recording, the screen is not updated.
Anyway, random slider settings, default workflow is filmic, so there’s no preset:
After reset, the values we would use for the scene-referred default preset are loaded:
That’s not how it works. The scene-referred (default) preset is only created if the selected workflow is agx; and it’s actually removed if you switch to another workflow type (I don’t know how that works, sorry).
I then don’t apply any values, darktable’s framework does that (applying the ‘winning’ auto-applied preset, if there are several, or the only one, if there’s just one).
If there is no auto-applied preset, then controls have default values, e.g. for most sliders it’s 0. But it’s again not applied programmatically, you just declare the defaults (this slider runs from x to y, the default is z). You only need to set soft limits programmatically, and special conversions, e.g. ‘this slider stores a number between 0 and 2, and present it as per-cents’, so it should run from 0% to 200%).
But there’s also a separate function that gets called when the module is reset. I’ve now used that to load the same values we use to create the scene-referred default preset.
Not perfect: if you don’t reset the module, it comes up with the unmodified primaries.
It’s 11 PM here, so end of day. Tomorrow is another chance, but not at 2 AM. 
Why would there be an agx only preset. I could see people having their preferred workflow for a tone mapper but perhaps wanting to switch during editing to AGX from filmic or the reverse to assess results. I would think the defaults for the module would be the same in any of the “scene referred” workflows
OK, found the right API method: reload_defaults. I’ll send a PR. It’s not 2 AM, yet.
Update: agx: reload_defaults + auto-gamma by kofa73 · Pull Request #19337 · darktable-org/darktable · GitHub
Whilst it is excellent news that AGX is now part of DT-Master, does that fact mean that there will be no more appimages here?
Yes. AppImages are available on darktable’s GitHub releases page.
Thank you - that is much appreciated news.
It’s just rather sensitive. Compare with the Exposure slider, mouse movements create smaller changes in the image compared with Pivot Target Output (at least on my setup).
It’s the display-referred output, running from 0 (black) to 1 (white).
This is what using ctrl/shift is for, making things go in smaller/larger increments.
Current master fixed the issue in my system. The default is using the Agx primaries.
Thanks Kofa/Pascal for the PR.
As long as you select one of the scene-referred workflows. So people using display-referred (legacy) or none as a workflow preference won’t get them. If you feel that’s also needed, please submit a new PR based on the one above. (Which was post #2000, yay!)
I am currently testing the latest version, and is there a specific reason to have the “keep the pivot in identity line” option enabled in the default settings?
I know that this ensures that the curve always has an S shape, but the biggest disadvantage is that you now have to constantly struggle to eliminate the clipping in shadows.
I have to turn it off almost every time and correct the gamma manually.
I find that option weird as well. I mentioned before I understand it as “dynamically changing the picture’s native target display device transfer function based on the exposure range”, I just don’t understand why anybody would want to do that. I assume most people would just want the picture to natively target sRGB 2.2 or Rec.1886 2.4. Now it’s dynamically changing the target function to an arbitrary number based on the exposure range, I am honestly not sure about the intention. If the intention is to keep the curve in an s shape… I just don’t understand why this would even be a requirement.
Interesting. I thought it was quite safe, it did not seem to affect overall contrast any more.
But you are right, it does trigger the clipping indicator more:
In the deepest shadows:
I can undo it, if it’s really a big issue.
Edit: the colour picker was affected by my display profile.
With sRGB, both version go to 0, so here’s an average instead:
Any input from others? Should auto-gamma (generally safer) remain the default, or would you like the previous behaviour back?
I recall a 0.1 change in the limits for clipping could make the difference if you saw warnings or not…if that is what you might be suggesting ie why it shows clipped???
