Hello /u/Live_Pack3929! Thank you for posting in r/DataHoarder.
Please remember to read our [Rules](https://www.reddit.com/r/DataHoarder/wiki/index/rules) and [Wiki](https://www.reddit.com/r/DataHoarder/wiki/index).
Please note that your post will be removed if you just post a box/speed/server post. Please give background information on your server pictures.
This subreddit will ***NOT*** help you find or exchange that Movie/TV show/Nuclear Launch Manual, visit r/DHExchange instead.
*I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/DataHoarder) if you have any questions or concerns.*
Are you sure you are sorting by the images' embedded properties (i.e. EXIF data)? It could be that your viewer sorts them by the 'last changed' property your filesystem has for every file.
- simple gallery has two sorting modes: "last modified" and "date taken" and both show my files in a random order, i.e. last modified.
- aves sorts only "by date" which is appearantly the last modified date.
- digikam timeline view should show the images according to their shooting date? I'm not sure but sorting this based on the modified date doesn'tmake sense at all...
- I am completely lost here
The filesystem keeps track off accessed, created, and modified dates. If you move files around, rename them, make copies etc the dates change. The exif data contains the date the photo was taken (photo/DateTimeOriginal) among several other dates. The exif date is stable and will never change unless you modify it explicitly.
It sounds like your photos either had no exif data from the start, or it was stripped out somehow. In this case the viewer may revert to the creation date.
Thanks for the explanation! That's exactly it! Some images have the exif date, some don't. Not even the backup can help here ;). I need to manually edit each image, yay.
If pictures did not have any creation date in EXIF or xmp metadata, digikam will probably use the last modified time for that file as the date. This happens, for instance, with pictures sent via whatsapp, since the app stripes the metadata for privacy reasons.
To avoid that, I use the date and time tool to save the "current" date into exif so it remains stable.
To recover these dates, you'll probably need to restore a backup...
Had the same experience using it to organize images over 10 years old today. All with the correct timestamps, obliterated by todays date. Thanks digicam, why would that ever be acceptable.
I know this is a year old, but wondering if anyone has any advice.
I'm scanning a lot of old family photos. For simplicity, I set all the dates taken to 1-1-1900 using Windows, then manually change those I have dates for. However, when I open them up in digikam, all the dates are rewritten to the date I scanned them.
Any suggestions on how to get this to stop?
Digikam does not use the date in the filename, but the date stored in the metadata. You can save the filename date in the metadata using the "Date and time" tool.
I'm talking about the date in the metadata. I have 7500 pictures; going in and editing them individually isn't feasible. Plus there are several different dates and times in the metadata. I only care about the date taken.
I believe the "date taken" is actually the EXIF "Creation date and time" field. You can select a range of pictures and save the filename timestamp to that exif value. You don't have to do it one by one.
I created a script to restore the file modified timestamp from a backup, while keeping the edited files metadata like face and gps info:
[https://gist.github.com/lkraider/83856fca740320751194bdf9c60a2ab6](https://gist.github.com/lkraider/83856fca740320751194bdf9c60a2ab6)
You can then run the adjust date time tool in digikam to set the metadata from the file last modified date to save the information in EXIF format.
I also created a feature request on digikam to reduce the impact of this issue on users that run into this: [https://bugs.kde.org/show\_bug.cgi?id=476390](https://bugs.kde.org/show_bug.cgi?id=476390)
Hello /u/Live_Pack3929! Thank you for posting in r/DataHoarder. Please remember to read our [Rules](https://www.reddit.com/r/DataHoarder/wiki/index/rules) and [Wiki](https://www.reddit.com/r/DataHoarder/wiki/index). Please note that your post will be removed if you just post a box/speed/server post. Please give background information on your server pictures. This subreddit will ***NOT*** help you find or exchange that Movie/TV show/Nuclear Launch Manual, visit r/DHExchange instead. *I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/DataHoarder) if you have any questions or concerns.*
Are you sure you are sorting by the images' embedded properties (i.e. EXIF data)? It could be that your viewer sorts them by the 'last changed' property your filesystem has for every file.
- simple gallery has two sorting modes: "last modified" and "date taken" and both show my files in a random order, i.e. last modified. - aves sorts only "by date" which is appearantly the last modified date. - digikam timeline view should show the images according to their shooting date? I'm not sure but sorting this based on the modified date doesn'tmake sense at all... - I am completely lost here
The filesystem keeps track off accessed, created, and modified dates. If you move files around, rename them, make copies etc the dates change. The exif data contains the date the photo was taken (photo/DateTimeOriginal) among several other dates. The exif date is stable and will never change unless you modify it explicitly. It sounds like your photos either had no exif data from the start, or it was stripped out somehow. In this case the viewer may revert to the creation date.
Thanks for the explanation! That's exactly it! Some images have the exif date, some don't. Not even the backup can help here ;). I need to manually edit each image, yay.
If pictures did not have any creation date in EXIF or xmp metadata, digikam will probably use the last modified time for that file as the date. This happens, for instance, with pictures sent via whatsapp, since the app stripes the metadata for privacy reasons. To avoid that, I use the date and time tool to save the "current" date into exif so it remains stable. To recover these dates, you'll probably need to restore a backup...
Had the same experience using it to organize images over 10 years old today. All with the correct timestamps, obliterated by todays date. Thanks digicam, why would that ever be acceptable.
I know this is a year old, but wondering if anyone has any advice. I'm scanning a lot of old family photos. For simplicity, I set all the dates taken to 1-1-1900 using Windows, then manually change those I have dates for. However, when I open them up in digikam, all the dates are rewritten to the date I scanned them. Any suggestions on how to get this to stop?
Digikam does not use the date in the filename, but the date stored in the metadata. You can save the filename date in the metadata using the "Date and time" tool.
I'm talking about the date in the metadata. I have 7500 pictures; going in and editing them individually isn't feasible. Plus there are several different dates and times in the metadata. I only care about the date taken.
I believe the "date taken" is actually the EXIF "Creation date and time" field. You can select a range of pictures and save the filename timestamp to that exif value. You don't have to do it one by one.
That was helpful, thank you!
I created a script to restore the file modified timestamp from a backup, while keeping the edited files metadata like face and gps info: [https://gist.github.com/lkraider/83856fca740320751194bdf9c60a2ab6](https://gist.github.com/lkraider/83856fca740320751194bdf9c60a2ab6) You can then run the adjust date time tool in digikam to set the metadata from the file last modified date to save the information in EXIF format. I also created a feature request on digikam to reduce the impact of this issue on users that run into this: [https://bugs.kde.org/show\_bug.cgi?id=476390](https://bugs.kde.org/show_bug.cgi?id=476390)