How create a simple shortcut to camera style

[MiSt (Michael Staats)]

I have opened #18139 for the issue that Pentax *.DNG files are not processed.
Thanks in advance for having a look.

[Unscript]

I think you got the wrong thread.

[Thad_E_Ginathom]

@EspE1

Yes, you’re right – to the extent that the newbee knows what a “style” is at all, that is, (as e.g. compared to a “preset”

There are levels to “newbie!” It is only recently that I started using styles at all. Will I ever not be a newbie to the diffuse and sharpen module!

I’m several years in, but there is still lots of stuff in dt that I have not mastered, or even used. I’m always going to be a newbie at something.

[KrM]

@Thad_E_Ginathom

applies presets to some others, but leaves them “off,”

Can you explain how you do it?

[wpferguson (Bill Ferguson)]

You start an edit in darkroom and apply the modules you want to use. In my current style I have 3 instances of diffuse or sharpen that use different presets and are at different places in the pixelpipe. I have 2 instances of tone equalizer (one with a preset, one without), colorbalance_rgb with a preset. I turn off the diffuse or sharpen, tone equalizers, colorbalance_rgb, denoise_profiled.

Most of the ones I turn off are heavy hitters in terms of processing time.

I return to lighttable and select the image then create a style from it. I only select the modules I’ve added/changed and module order so everything ends up in the same place.

Now I have a style that I can apply to the images I want to process that provides me a starting place.

[wpferguson (Bill Ferguson)]

@EspE1

I’ve for some time wondered in general what determines whether a new function is integrated into “core dt”, or provided as a lua script that requires of the user that he takes action in a new domain.

I’ll address this using apply_camera_style since it’s probably a really good case.

Ralf Brown created a set of camera styles to apply to raws in an attempt to get the raw close to the jpg preview. I thought it was a good idea and would make the “I want the SOOC jpeg look” crowd happy. But, to apply it you would have to select all the images for one camera then apply the style. So, it wasn’t “easy”.

The Lua scripting language is built into darktable and has access to the internals so you can manipulate lots of things. It is the tool of choice for implementing custom workflows.

I looked at the styles and thought I can write a script to make this a “set it and forget it” option so that the styles would automatically be applied.

Why use Lua instead of including it in core?

• The script is a little over 300 lines of code.
• Sophisticated pattern matching built in
• Development speed. The first version only took an hour or so. Most changes during development only took a few minutes. A final rewrite to clean up everything took 30 minutes.
• Agility. As the styles increased and the naming changed it only took minutes to change the code and test.

If I had tried to do this in core:

• thousands of lines of code
• No pattern matching built in. I’d have to write my own
• Change code. Recompile. Test. It takes a few minutes to do each change. If you make a simple typo, it takes minutes to fix. In Lua, fix the typo restart darktable, and test. It only takes seconds.
• Pattern matching would have been a pain in the …

darktable is now released with the script and the styles. If there is a problem with the script, I can fix it and push the fix to the repository. The next time you start darktable the fixed version of the script will be automatically retrieved and loaded.

If this was a core function, and the error was found and fixed before the bugfix release in February, you would get the fix then. If the error wasn’t found or didn’t get fixed, then the fix would be in darktable 5.2, which would be released in June.

Will the functionality the script provides ever be in core?

Probably not. If the script was horribly slow and could benefit from being rewritten in a compiled language, then maybe.

What wont be done in Lua?

Image processing. If I wrote profiled denoise in Lua you would probably die of old age (or wish you had) before it could finish one image.

How do we decide core vs script

• can it be done in core?
• can it be done in a script?
• which one is someone willing to do?
• which one is easier?

I’ll give one final example.

Users that group their images want their groups to persist across database instances (I corrupt my database. I create a new database instance, reimport my images, and want to have my groups back).

darktable grouping is based on image id. When you reimport your images, the image id is assigned on import, therefore all your grouping is destroyed.

Changing grouping to a different implementation would break all existing grouping. If a migration path was available, it would still be a pain in the … And, even though it was tested, it might not be as robust as thought when released into the wild (as evidenced by the bug reports coming in now that 5.0 is out).

Based on the above…

• core - yes, but nobody wants to tackle that monster.
• script - yes, but I had to add an event to core that signaled on a group change
• which one - nobody was willing to do it in master and I was as a script
• easier? I would say this was a toss up. It took awhile to figure this out and work out the bugs
• safer - this wasn’t in the above list, but it entered into the decision. If the script is totally wrong and doesn’t work at all, existing groups will still exist and be fine. The script solution is built as another layer above the existing grouping so that they can peacefully co-exist.

[EspE1]

Wow, Bill, I hadn’t meant to bother anybody to use that much effort to indicate some answer to my wondering, but thank you very much!! This anyhow adds to the understanding of dt and what goes on around it, (as I’m about to start getting into scripts and Lua).

And thanks in general for all the work with the scripts and the support here in the forum!