digiKam thumbnail view: sort by date/time photo taken

Is there a way to make digiKam sort jpeg photos in the thumbnails view using chronological order of date and time the photo was taken? Currently, in thumbnails view within ‘albums’ the jpeg images are stored in order of the date the photo was last edited. In the View menu there is an option to sort by ‘creation date’ or ‘modification date’ but It appears digiKam reads this date from the metadata of the file not the photo so if I edit a jpeg and re-save back into the database it jumps to the front of the list in digiKam thumbnail view, away from others taken on the same day.

Other image viewers I’ve used - eg Faststone and any others - don’t do this but give options to sort by either the date the photo was taken OR date the photo was last modified. Is there a reason digikam doesn’t follow this method? Am I missing something?

I’m using digikam 8.1.0 on Windows 11.

Thank you for any insight into this. Apologies if this basic question is not appropriate for this forum, I can’t find a dedicated forum to ask beginner-level questions about this lovely software.

Dave

Of course, digiKam reads the creation date from the metadata. The metadata may not have been read correctly into the database because other programs (explorer, antivirus) blocked the files. Perform a reread of the metadata from the file into the database.

Thank you Maik. I’ve tried that but it made no difference to my problem. To be a bit clearer: using the Properties tab on the right of the main browse screen under File Properties heading the correct time/date of when the image was last edited is shown and under the Photo properties is shown the correct time/date of when I took the photo. I would like digikam to sort my photos using the date the photo was taken not (as it now does and I cannot change) the date under file properties. Does that make sense?

You can select in the View->Sort Items menu whether you want to sort by creation date or modification date.

Thanks again Maik. I have tried changing the view from creation date to modification date but unfortunately that still doesn’t fix it. ‘creation date’, within the thumbnails view for digikam, doesn’t seem to be the same as ‘DateTimeOriginal’ (which corresponds to the actual date/time the photo was taken) as shown in the Exif metadata within the ‘Metadata’ tab on the digiKam screen.

But it is a strange one - having now looked at it closer - digiKam is using the DateTimeOriginal datestamp for most of the photos but not all. For example some photos taken back in March 2023 are all grouped correctly and show the correct date taken but when yesterday I did a bit of editing of two of them (using another program - Affinity Photo) and saved them as different versions with new file names digiKam now shows their creation date and modification date as yesterday though the Exif data still includes the correct DTO stamp.

Sorry I can’t explain better.

In principle, digiKam uses DateTimeOriginal with a high priority. Based on bug reports from users who have made changes to the dates metadata with other programs, digiKam could use it. Please provide me a sample image whose creation date does not match.

Hello Dave,
I stumbled upon the same problem yesterday: a raw file processed in ART and saved as a jpg did not show up next to the raw+jpg in Digikam, but at the bottom of the thumbnail page. I corrected that as follows: menu View - Sort items By Name. Does this help?

Many thanks for taking the time with this. I’ve uploaded two jpegs - the file with the name ending 499i is the recently edited one and the other is original.

I think it may be a problem with Affinity Photo somehow altering the metadata - but I have to say that it doesn’t appear to change the way they are sorted in either FastStone Image Viewer or the old Windows Live Gallery which I still use. I hope you can find something that I am doing wrong so that I can change it and have all photos displayed with correct dates as in every other way I absolutely love digiKam and would like to start using exclusively as my DAM system.


I have found (using a different file) that by altering the date under DigiKam Properties in the Properties tab I can get the file into the right place - but I don’t know what other effect that is having on the metadata and would rather not have to do that every time i make a few minor edits.

Paul, thank you for helping it’s much appreciated. Your idea does work - but only where the filenames are all in the same sequence. I use more than one camera and they have different file naming protocols so sorting by name (for me) won’t put everything into chronological order (also it doesn’t change that the file has the wrong date displayed and doesn’t show up in a search by the specific date the photo was taken).

I don’t see any problem with the two images. Both images are recognized here under Linux with a creation date of May 20, 2023. Affinity Photo has set “Exif.Image.DateTime” to a current date. But since “Exif.Photo.DateTimeOriginal” is still correct, the correct date is recognized. But I’ll test it again tomorrow on a real Windows 10 machine.

What creation date do you see for P1050499i? But don’t look at the properties bar in the file properties, that’s the modification date.
Activate the creation date under the thumbnails or look at the date in the properties bar in the digiKam settings section.

I can’t reproduce any created date issues on Windows either.
Do you use sidecars?

P1050499i shows in the digiKam thumbnail view as having a creation date of 4-11-2023 (I have the view set to display filename and date created under the thumbnail). The same date shows in the Properties tab under file properties (with a time of 12:08) and under Digikam properties (with a time of 12:06).

I don’t use sidecars except sometimes when developing RAW files but that doesn’t apply here. I confirm 20 May 2023 is when the photo was taken.

Sorry for the lateness of my reply.

The problem should be fixed in digiKam-8.2.0. The cause depended on which time zone digiKam was running. Some date metadata with 04/11/2023 have a UTC identifier. We have now given Exif.Photo.DateTimeOriginal an even higher priority.
However, if a version with this change is available, this requires the metadata to be read in from the image again.

That’s good to hear, thank you so much for your help with this.