collect images by darkroom module filtering

I’ve just posted a feature request on redmine, and wonder if anyone else is interested in such a feature, and would like to collaborate in implementing it?

2.6 brought about a magnificent improvement in collection filtering ability.
I would think that an incremental enhancement to this filtering would be to select for darkroom module used. At the moment the only possibility is to either use the history filter, or, equivalently, use the tag filter for darktable|altered. When I have many (> 20) images of a subject, I would be glad to be able to filter by an arbitrarily chosen darkroom module in the history. For example, all images I have applied crop/rotate to, or tone mapping to, or that I have denoised.

I’m prepared to put some work into this, but I’d need some hand-holding: my coding in C goes back to my first university days: 1988-1991. I can pull the entire source repository, but I don’t know where to start with locating the collect images filtering code, or how to extract the database information for history for each image in the currnt selection.


I would start by looking at commits having done something similar, like the recent collect on exposure support:

Then create a PR and discuss it with developers.

I found this one-year-old thread because I searched for exactly that feature. I hoped that this feature (filter for used modules) did already exist, and I just didn’t figure out how to do this. But it seems it really isn’t implemented.

So here is my “thumbs up” regarding that functionality. Has there been some activity about it?

1 Like

Hi @airflow, unfortunately, there has been no progress to my knowledge. This thing called life got in the way, and my available time is much curtailed due to employment secondment over and above my regular job. I did not pursue this.

1 Like

here is my very basic workaround

  • I can not code it
  • and was very interested in this idea

but really needed to get rid of all the ‘old’ modules these days …

  • open the library.db (read only) using a database browser
  • got to the history table
  • filter by the operation name and the enabled = 1 (yes) status
  • there you have a list of all images (by their image id only) using a specific module
  • done

If you want a list of all filenames using a specific module (e.g. levels active),
you will need an inner join to run this SQL statement:

  • select operation, id, filename from history inner join images ON history.imgid = WHERE operation = ‘levels’ AND enabled = 1

  • hard part, you have to enter filenames from this list in darktable …


I’ve made a try here : PR #4291.


I wanted to try to tackle this, but you showed me that this is harder than I thought it would be… Actually the “order” one is what made it more complex :slight_smile:

I see it’s taged for 3.2 release but I’d wish it reached some 3.0 point release as it seems it won’t introduce any problem for image processing.

That’s certainly not the point. We had some bad regressions by introducing what could be called “standard” and “obviously correct” code.


I both fully understand and want to know more - which “standard”/“obviously correct” code introduced bad regressions? I always wonder about interesting coding tidbits like that :slight_smile:

My last change to just display opacity in top bar. The opacity was used for all masks the same way except for brush where the hardness was indeed modifying the opacity. Fact if that using a brush and changing hadnesss would set opacity to 0 hence the huge number of report about this issue in 3.0.

The change in metadata handling, all was working fine for “small” to medium size library with not too many tags. But a missing index was a disastrous experience for people with large library with lot of tags.

etc… I can assure you that I had more than one single issue like that in the past two years. And this always require lot of work and time to fix quickly.


So your change didn’t cause the issue, only uncover it :slight_smile:

There was recently a question here about ANALYZE/OPTIMIZE/VACUUM for sqlite db - I actually plan on doing a PR for sqlite recommendation that could “help” in some cases…

1 Like

Sorry was not clear, no it was awkward but meant to be working this way.

1 Like

Keep us post, would be really nice to have something to help in this ! Thanks.

1 Like

Good news - @phweyland’s solution just recently landed in master and is taged for 3.2 release. Additionally a new way of handling history collection that would allow you to not only choose between altered and non-altered but also by module order (legacy/custom/3.0 with room to grow).

With @phweyland’s solution that’s taken care of :slight_smile:

Great news!

I think I can not wait for it, please please is there any 3.2 dev. version for windows somewhere available ?