darktable 4.8.1 released

What version on lensfun is this?

My Arch’s pacman -Q says lensfun 1:0.3.4-4.
I just notice, that there are two locations for lensfun database. The first one is /usr/local/share/lensfun/version_2. Thats the only one that i was aware off until now. I checked what lensfun commands are available. One of them was lensfun-update-data. I run the command which show me:
Successfully updated the database in /var/lib/lensfun-updates/version_1.
Successfully updated the database in /var/lib/lensfun-updates/version_2. This folders are new to me. The xml-files in this two folders are from today 00:39 o’clock. Additional there is a timestamp.txt with the date/time from when i run the lensfun-updata-data command.

See darktable 4.8 location of lensfun database for personal use - #2 by kofa

This version uses the v1 profiles.

I’ve upgraded to 4.8.1 and now when I apply a style thourhg lighttable, it no longer overwrites existing module parameters, instead it creates an additional module with a “-1” version next to it. The resulting image is of course incorrectly edited. This is extremely annoying, and render the software unusable.

Also, when I save a style using an existing one, I get the message “style-name-here” already exists. No option to overwrite. Is it a feature in the config? If so, the default behavior should have been to keep it as the previous version’s, with an option to prompt. Extremely annoying since I can no longer basically edit and save an existing style.

The previous version used to crash often, 4.8.1 no longer crashes, thanks for that, but again with the above issues I am finding myself going back to another commercial editor.

I really like DT but I’ve seen it becoming a lot more complex than it needs to be, extremely bloated with endless modules and sliders, modules which perform similar function. I totally support free and opensource software, but with that comes the freedom for the developers to make decisions without financial repercussion, meaning if users don’t like the upgrade “they can go to hell”. Well here I go…

Is the style set to “overwrite” or “append”? It sounds like “append” when you want “overwrite.”

So just use the ones you like.

Perhaps you should peruse the manual, it’ll tell you how to customize the modules list. It helps a lot.

I don’t think that’s the general attitude here. Developers are mostly open to feature suggestions, and they certainly don’t just reject bug reports.

Something may be fishy with styles, others have also complained about the issue you described with the new module instances.

There’s a bug report here:

You cannot set that in the darkroom.

In the lighttable view, the wording of the manual suggests overwrite does not mean overwriting the state of modules included in the style, but rather overwriting the whole stack:

create duplicate
When applying a style to images, tick this box to create a duplicate of each image before applying the chosen style to that duplicate. Disable this option to apply the chosen style directly to the selected images. Beware that in this case any existing history stack is overwritten (depending on the mode – see below) and cannot be recovered.

mode
As with the history stack module, this combobox allows you to either “append” the style to the current history stack or to “overwrite” the history stack of the target image.

That is a completely inappropriate statement. Darktable is FOSS, the developers work on the software in their spare time, generously making their work available to the public. If darktable does not meet your needs, you should make meaningful suggestions for improvement and discuss them with the developers if necessary, or you should choose another application.

1 Like

Otoh, this kind of “suggestions” aren’t really stimulating the developers to take into account user opinions.


Developers may not react to bug reports here, there’s a bug tracker over on Github, where you see what info to provide. That system helps the developers tracking progress on the report, contrary to threads here.

As for the bloat: part of that is the introduction of a new workflow a few years ago, which means functionality had to be “duplicated” for that new workflow. The old modules have to stay in the program to ensure backwards compatibility with old edits, and unless they pose some serious problems, they are also kept available in the GUI.

But darktable gives you the possibility to adjust the visibility of modules in the darkroom, so you can just see the modules you want to use (caveat: new modules after an update won’t be visible either). How to do that is described in the manual, and not all that hard to figure out on your own.

TL;DR: read the manual.

1 Like

if someone dosn’t like the upgrade then he can simply stay with the older versions.
Why do you expect developers stopping improving stuff just because there’s one user not needing that?

Don’t forget, in FOSS, developers are users too, and certainly a lot of the occasional developers make things because they want them and have a use-case for them. Of course, if you don’t like a feature, you don’t need to use it, but if a new feature breaks your workflow somehow, the developers are usually pretty receptive to either advise how to change your workflow or modify the feature to support that workflow.

1 Like

Getting the human stuff out of the way first: if you delete the last paragraph, you might get more of the useful-to-you responses. Think about being on the receiving end.

Having said that… Yes, several of us have had trouble with styles generating multiple modules (eg exposure particularly when we only want one. Yes, we have had trouble with the naming of modules when we do want more than one.

And yes, I too find it a nuisance that I can no longer overwrite an existing style. This one does glare a bit, as it usually takes me more than one attempt to set up the style, but it can be worked around by new-naming, removing and re-naming. Yes, that is a pain, but it is only a one-minute pain. I hope it will get fixed (but I haven’t, personally, reported it) but I’ll live with it until it is.

On the problems with multiple modules and naming, I don’t know if these are workarounds for your situations (or even infallible ones for mine) but try collapsing the history stack before you make a style from it. It might help also not to include “system” modules or modules you are not changing.

Since first version of darktable years ago the UI has not changed. On panel on the left, one panel on the right, a top panel with some controls and a panel at the bottom for filmstrip or timeline. So I just don’t understand the “becoming a lot more complex”… You probably have issues with the UI but a generic sentence like this one won’t help.

1 Like

Style is set to “overwrite”. I’ve been using DT for many years, and the “overwrite” option had always worked flawlessly, until now. It seems that at virtually every upgrade, there are either introduced bugs, or new modules replacing old ones, with a steep learning curve, Color Balance RGB comes to mind.

As far as developers and making suggestions to improve the software, here is mine:
“Please test the software upgrade thoroughly before release”

My comment has nothing to do with the UI layout, or feel. Please read my comment with an objective mind, I am referring to Color Balance RGB for example, which replaced the “Contrast, Brightness, Saturation” module, I am referring to complexity WITHIN the module, not the placement of the modules within the UI.

I’m not sure what you mean by renaming modules… I know how to do that. I am talking about applying a style to a hundred or so images, and seeing that the output images are unusable, and there are up to 6 versions or Filmic, Exposure, and other modules. How do you fix that, for a hundred images? Thanks.

Please take your own advice. You can stay on whatever version you like, nobody is forcing you to upgrade.

Or even further, you can help test new releases to ensure that the functionality that you want or need is bug free for your use.

but this just follows darktable’s UX pattern of leaving the user relatively close to the algorithm, its always been this way.

And no modules have been removed, you can access every module that’s ever been there. Use what works for you.

1 Like

How can I access the old Contrast, Brightness, Saturation module?

there is a module layout called “deprecated.”