Feature #8514

More meaningful sorting by timestamp, rating and filename (has been: Sorting by timestamp might lead to a wrong display order)

Added by Markus Jung about 7 years ago. Updated almost 7 years ago.

Target version:
Start date:
Due date:
% Done:


Affected Version:
hardware architecture:


Pictures taken in in continuous shooting mode might have the same timestamp, at least the D5000 increases the timestamp only in steps of 0.5s. Thereby are small groups of pictures locally wrong, maybe random?, ordered.
Furthermore, darktable seems to ignore the fractions of a second and appears to sort only by whole seconds.

Proposed fix: If two or more files have the same timestamp, sort them by filename, which should normally reflect the order in which the pictures have been taken. Even if a user decides to create the filenames by himself, he could rely on a deterministic and meaningful ordering when sorting his pictures by timestamp.

Create Date : 2011:06:12 15:30:30.00
Create Date : 2011:06:12 15:30:30.00
Create Date : 2011:06:12 15:30:30.50
Create Date : 2011:06:12 15:30:30.50

Those pictures get displayed in following order: 25, 23, 26, 24


#1 Updated by Markus Jung about 7 years ago

Silly me forgot to mention: This affects (at least) darktable-version 0.8 from the darktable-release-plus PPA by Pascal (with Ubuntu Maverick)

#2 Updated by Markus Jung about 7 years ago

I added a patch which enhances the SQL-queries in common/collection.c by a ", filename". Untested but it should work.

#3 Updated by Markus Jung about 7 years ago

Ok, the proposed patch isn't the last word on this subject, after chatting a bit with dinamic and pmjdebruijn i would suggest following order:
timestamp, shuttercount, path/folder, filename

If the timestamp collides, which happens usually if you shoot a series of pictures like explained before, the shuttercount would fix the order, maybe better than the filename could do. If the shuttercount is missing/equal (which is the same, assuming that no one can make two pictures with two cameras at the same time and having the same shutter-counter-value), there is still a meaningfull fallback based on the path and the filename.

According to dinamic there is a bit more work to do, shuttercount has to be included into the database (which requires an additional column and storing the shuttercount-data into it on import).

Maybe a similar modification should be done for sort by rating (flags & 7 desc, shuttercount, path, filename) and sort by filename (filename, shuttercount, path).

#4 Updated by Markus Jung almost 7 years ago

Addendum: At least Canon DSLRs appear to NOT store the shutter count into the EXIF blob. Therefore any sorting by the shutter count MUST have a meaningful fallback.

#5 Updated by Tobias Ellinghaus almost 6 years ago

  • % Done changed from 0 to 20
  • Target version changed from --- to Future
  • Status changed from New to Triaged

Also available in: Atom PDF