During the development of the AgX module, I’ve created no less than 7 versions. This is normally not done for in-development modules. Providing backward-compatibility was a dubious decision: while these versions were helpful for those brave enough to test the yet unreleased module as a daily driver, the migration code has become a maintenance hurdle for the future, requiring almost 400 lines of code – code, which would be a dead weight for the rest of darktable’s hopefully long years ahead, never used by most users, who will start with v7, once the release is out.
Therefore, this migration code will be removed. It does not mean that you will lose your edits; it simply means that edits made with v1 to v6 will no longer be supported. Should you wish to keep those, you will have to upgrade them (by simply opening them in the darkroom) using the as of today (17 November 2025) current master version. You should filter the image collection to see which ones were edited using Agx (or agx, as the module was previously known). It is enough to upgrade ‘darktable|history = altered’ images, as only those may have manual modifications.
Unfortunately, module version information is not available via tags. Then, open each image in the darkroom (you can open the first one and use space to go through them).
Then, in a few days (I will let you know in this thread), one of the new daily builds will come with a version of the module that will no longer be able to properly migrate old versions; any parameters for versions 1 to 6 will simply be replaced with the defaults of v7.
My understanding for other pieces of data where history is involved:
darktable migrates presets when it starts, so those are safe. However, exported preset files will not be migrated once they are restored into darktable, once the new version arrives, so if you have any that you wish to migrate, import them into darktable, restart darktable to trigger a migration, and export the presets, if desired.
styles are not migrated; you will have to recreate them using the current master build
if you export an image from the lighttable (without opening it in the darkroom, which would update the history stack), I think that the history stack embedded in the metadata will be the old version. Processing takes place with an in-memory migrated version of the settings, but that is not written back to the database, the XMP, or inserted in the exported metadata.
And, of course, any PlayRaw etc. XMPs stored online will not be migrated.
can you use the darktable collection module to find all photos that use a certain module in their stack? or do we need to beg @wpferguson for a lua script to do that?
This is a very sensible approach you are taking. I am more than happy to accept that some of my previous edits will be broken as you fine tune the AgX module for the upcoming DT5.4 release. The risk we choose to take when we use the development versions.
Great work with AgX. It has become my go to module. I find that the tone equalizer module also works better in my hands now that AgX is the tone mapper that I am using. I am just so loving AgX.
I agree @Terry above very much and am happy with this.
Only I’ve just today started the process of building dt and I’ve still some hurdles to take before mastering it. To be shure, where do I find today’s current master version (preferably in the form of an AppImage which I started getting used to)?
With early versions your image would come up black and you would need to reset the module…so of course you get the new module and defaults applied…Likely depending on how old the edit is something like that might happen…
I store my images on a NAS and remove the RAW files from darkroom after exporting them. I would like to contribute two observations/lessons from upgrading my history stacks to AgX V7:
1.) Importing the RAW Files into darktable itself seems to already upgrade the AgX-modversion (I suspect because I have “use raw file instead of JPEG from size = always” set in the lighttables settings; this would trigger dt to re-render the rawfile?).
BUT
2.) the .xmp sidecars are not updated, this requires triggering “write sidecar files”. Not doing this will not be a problem if all your edits live inside your database but still poses the risk of losing your upgraded history stacks if the database is lost.
I wonder if it would make sense to introduce a category of “experimental” modules that are not guaranteed to have backward compatibility for all edits (and may even be removed, renamed, etc, while they are still experimental).
These modules would be hidden from users unless they explicitly enable experimental modules in the settings.
With this feature, it would be possible to
include modules still in development in stable releases, for those who want to experiment and/or provide feedback,
test modules for a longer time and with a broader audience
I think everything not in a release should be considered experimental. It’s one of the risks you take if choosing to use the development version as part of your daily workflow. If we’re including things in a release that we don’t think are ready yet (I’m not sure we should do this at all TBH, and usually modules in this state wouldn’t even be merged) then they should probably be prevented from running within the release.
That goes without saying. In case it is unclear, my suggestion is to have experimental features in releases. Hidden, but available for testing.
For testing. A lot of modules are technically “ready”, in the sense that they produce sensible output, do not crash, etc. Nevertheless, they are modified by user experience after wider testing.
I think the policy is that if the module cannot be properly tested, it’s not merged into master until the release is out (just like AgX lived in its own branch until September, even though people were using it in May). We have half a year between releases, so a module can still spend 3-5 months on the master branch, and feedback can be gathered, bugs can be ironed out before it gets released. People who want to test stuff can already use the daily builds.
Also even looking at a simple commit to a single module during development often requires changes in one or more other modules as a part of the update or fix or change so its not going to be just as easy I don’t think to simply label a module as experimental and turn it on because of some of the potential codependencies involved…or at least it would seem that way to me…
