I’m not sure if it’s possible with DT. I’m just asking.
For example I have 1000 images. I’ve decided to make an exposure compensation of, say, +0.25EV to 750 of them. Is there a way to make it in bulk with something like copy&paste? I.e. I need to change 750 images’ exposure by +0.25EV at once.
You could probably create an additional named instance of exposure with +0.25EV and add it to all the images in question, but it’s not possible to make relative adjustments using “regular” darktable functionality (e.g. add 0.25EV to an existing exposure module). Perhaps with Lua?
Can I suggest developers to make a kind of a flag in some modules where possible?
This flag can be called ‘Consider all values of the module as relative’. So that users could clone a needed module to then apply its relative values by copy&paste tool to multiple images?
This module can be a kind of virtual. And after it’s applied, it won’t be visible inside affected images. So DT will use this type of virtual module for fine tuning values of modules that were previously attached to the images before.
Given that there is already a way to do what you want (at least for certain modules like exposure), not sure developers would be interested in implementing such functionality (*).
Your procedure would mean:
create a new instance of the module
set the change
copy that module
paste it to all images concerned
Currently, I would do that in dt as:
create a new instance of the module
set the change
create a style with just that module
apply to all images concerned
Extra advantage: such a style would be available later as well, so you can skip the first three steps
So in short, no changes to dt needed for this kind of operation.
(*: your example isn’t a relative change to the module setting, but an absolute change (add x to all images; a relative exposure change would be “add x% of current value”. ) That’s actually what makes it possible to do what I described, as there’s currently no way (except perhaps lua scripting?) to make a change relative to the parameter value of a previous instance of a module: afaik, modules do not have access to parameters of other module instances.)
Sounds really easy when you put it like that, but I think it would require an extensive rewrite to implement, and would only be easily applicable to a couple of modules. Given that this functionality can already be achieved by creating a duplicate module, it sounds like a lot of pain for not a lot of gain.