I played with your example and couldn’t get it to work. Then I remembered a conversation last August with @dterrahe about presets and he said they weren’t implemented yet. I don’t recall seeing a PR that did implement them, so I’m guessing they are not done yet (as evidenced by the action ... doesn't exist messages)
2 Likes
For some reason, the names of some of the presets in the code contain U+00A0 NO-BREAK SPACE characters instead of normal spaces. For example
There may be a good reason for this (although it is more likely that they were inadvertently copied from comments, where this character pops up frequently), but you could submit an issue to github to ask for these to all be removed.
One way to get this working in the mean time is to first create a shortcut to each of the presets you want to use and then (in the bottom half of the shortcuts dialog or preferences tab) ctrl-V this shortcut and past into your lua script. I did this and it worked fine (which was confusing as it looked exactly the same as yours).
3 Likes
@dterrahe thank you, that works for “soft” and “strong”. I exported the shortcuts to a file and copied the lines from there.
a similar point at the lens correction module:
dt.gui.action(“iop/lens/correction method”, 0, “selection”, “item:lensfun”, 1.0)
does not work and I am not able to define a shortcut. Do you have a solution for this?
error message: [dt_action_process] effect ‘item:lensfun’ not valid for action ‘iop/lens/correction method’
BR,
Uli.
1 Like
If I create a shortcut to this dropdown, select the correct effect and then ctrl+v it, I get this
dt.gui.action("iop/lens/correction method", 0, "selection", "item:lensfun database", 1.000000)
which is slightly different from yours and seems to work.
1 Like
@dterrahe thanks a lot! That works fine!
I did not understand, how to select the effect. I did not recognize to select it in the “effect” column in the lower half of the dialog, in the line where the shortcut is displayed
Let’s say the dialog can do a lot, but has a somewhat special handling.
Thank you for your very good and fast support!
BR,
Uli.
1 Like
@dterrahe I am very sorry, but it´s me again 
my next step is to configure the highlight reconstruction module. I want to set the reconstruction method. To do that, I define a shortcut like this:
but if I apply the shortcut, another reconstruction method is set:
looks like there is a wrong assignment / mixed up array or something like that? There is a similar strange behavior with the other values. The popup shows the correct shortcut assignement.
a small hint: within the shortcut dialog, there a six possible effects, there are only five in the module.
Yep, that’s a bug. The list in the actual widget gets manipulated at runtime and therefore the order gets out of sync with the list used for the shortcut. There may be a few other places where you could run into this. I will fix this, but that won’t help you until 4.4 (or until the fix lands in master if you self-compile).
2 Likes
This PR contains the fix define widget type mimicking actions with flexible lua scripts by dterrahe · Pull Request #13579 · darktable-org/darktable · GitHub
It also introduces some other stuff, but since what I’m working on in that PR will depend on the changes that I introduced to fix this bug, it would be inconvenient to separate them. If for some reason the full PR is not merged soon after completed I’ll submit the fix separately as well.
3 Likes
Actually… that fix only works in English (and completely breaks “item:” shortcuts in other languages), so I’ll have to look into this a bit more :-/
EDIT: Pushed a better fix to #13579. This works in all languages and hopefully I haven’t missed any breakage this time. In theory this would also allow more combos to expose their items via the shortcut system (and lua), even if the actively selectable list changes at runtime as long as the “complete” list is fixed. For example blend mode
EDIT2:
I cannot post here again until someone replies; I’m not sure how this is supposed to work if I want to notify people of updates.
I would be grateful for some testing of define widget type mimicking actions with flexible lua scripts by dterrahe · Pull Request #13579 · darktable-org/darktable · GitHub. Please report any bugs you find or remarks there if you can. Thanks!
4 Likes
Hello again!
It’s been a while since the thread was started, but finally the script for timelapse processing does the job. So, huge thanks to all the developers for their work and help here, and to all the other folks for their advice!
Still I believe there’s a lot of room for improvement, as I could not avoid sleep() black magic even where it seems to be superfluous Here are some of the problems (valid for darktable 4.2.0):
-
Image loading in the darkroom view. The promlem was already mentioned by @wpferguson earlier, but still seems to exist. There’s a
darkroom-image-loadedevent and I expected it was enough to wait for it after callingdisplay_image()(or switching to the darkroom view) to be sure the image is ready but it does not work like that:
dt.gui.views.darkroom.display_image(img)
<wait for darkroom-image-loaded>
local currentExposure = dt.gui.action("iop/exposure/exposure", 0, "value", "set", "")
Here thecurrentExposurevariable will not receive theimgexposure value. It turned out, that apixelpipe-processing-completeevent is sent as well, and things work better if both events are awaited, but still an extra-sleep is needed to make it work as expected:
dt.gui.views.darkroom.display_image(img)
<wait for darkroom-image-loaded>
<wait for pixelpipe-processing-complete>
dt.control.sleep(500)
local currentExposure = dt.gui.action("iop/exposure/exposure", 0, "value", "set", "")
Is there a way to avoid thesleep()call here? Am I doing something wrong? -
Performing some actions. The image exposure mapping generally looks like this:
dt.gui.views.darkroom.display_image(sourceImg)
dt.gui.action("iop/exposure/spot mode", 0, "selection", "item:measure", 1.0)
dt.gui.action("iop/exposure/exposure", 0, "button", "on", 1.0)
dt.gui.views.darkroom.display_image(destinationImg)
dt.gui.action("iop/exposure/spot mode", 0, "selection", "item:correction", 1.0)
dt.gui.action("iop/exposure/exposure", 0, "button", "on", 1.0)
Here the first two actions on the sourceImage do not(?) yield any event, and delays have to be inserted to make it work, and the two actions on the destinationImage fire the pixelpipe-processing-complete, but we still can not rely upon them completely, because by that very moment the exposure correction is only suboptimal. It takes an extra-sleep after every pixelpipe event to achieve the expected result. Are there events for the measuring actions? Is there a way to handle correcting actions more reliably? -
Styles manipulation. Everything could be much easier and faster if there were a possibility to create and edit arbitrary styles in the lighttable mode. The current use case: there are a lot of images, and we should iterate over them setting exposure value to a calculated value. Theoretically, it could be done in the lighttable view, by applying a style with a single exposure module with a desired value set, without the expensive image loading. Is it feasible?
And just in case, here is the current script (skipped the explanation so far to save space in the comment):
timelapse.zip (2.0 KB)
1 Like
Ulrich’s script will set the exposure with the spot exposure for a series of images so if you do your sample and then run his script with only that option I think it would work…
I’m not sure, but his script doesn’t seem to work with exposure setting from the lighttable view.
My first script still has bugs, I’ll post a new version here tomorrow. I can’t get to my computer right now.
It is as you write, you should wait for both events plus a sleep. Only then does loading from the Lightview work reliably.
2 Likes
Finally the time has come: Attached you can find the new version of the Darktable Initial Workflow Module that calls some automatisms of different modules in the darkroom view. If this suits your workflow, the script saves some clicks and time.
EDIT: There is a newer version, see posting #110.
It offers a new “inital workflow” module both in lighttable and darkroom view. It can be used to do some configuration for an initial image workflow. Several steps are offered, see the tooltip within the module for more information. Your settings are saved in Darktable preferences and restored after the next start of the application.
If you use it from lighttable view, you can select one or more images and configure offered settings. Clicking the run button, selected image(s) are opened in darkroom and all steps are performed as configured. If you use it from darkroom view, the currently opened image is processed.
I executed it with DT4.2.1 on Linux (Arch-based EndeavourOs) and Win10 (within a VM, once only).
Have fun! I am looking forward to your comments and bug reports
7 Likes
Thanks for sharing your work… I look forward to checking this out tonight…
1 Like
Doesn’t seem to work on this version…
Not sure if any recent changes messed with it…
I will dig up and install the official release and test it…
i’m running on Windows…
Seems to work on this version; running on Windows 11
+750 it just seems to add the modules with none of the actions or settings of the macro applied… Also I noted that in 4.21 for example the option in contrast eq was set to clarity and not clarity 0.25 or 0.5 which I assume would have the mix slider moved… I will go back and test for other issue on 4.21 as it seems over to work there but on my version as I said it just cycles through and adds the modules so there is no impact on the image except for the lens correction…
Actually in 4.21 its not all working either or at least I don’t think so … The mask is not set in color balance and the chroma and sat are not applied… Exposure auto seemed to work. The tone eq mask seemed to change Filmic was not auto tuned. And the macro seems to only run once for me and then it won’t run again. I have to quit and reopen DT
So in the end here the effects noted are from exposure contrast eq and lens correction… The rest of the options did not work…
Maybe I need to update something??
EDIT…
I noted that the values specified in the contrast eq were specified as 0,25 and 0,50 and not 0.25 and 0.50… changing these seems now to make the whole script work… in 4.21… will now have to check my master branch version…
Edit2 I can confirm that the macro seems broken in 4.3 +750…
There was a report that it was working in 4.3 + 705 but that should be confirmed as I found a small error in the macro that seemed critical…
I didn’t check every detail, but I clearly see a big change happening on two of my pictures; let me also go back and verify