https://bugs.kde.org/show_bug.cgi?id=437897
Bug ID: 437897
Summary: Windows timestamp to metadata extraction for TIFFs
changes when modifying files
Product: digikam
Version: 7.2.0
Platform: Microsoft Windows
OS: Microsoft Windows
Status: REPORTED
Severity: normal
Priority: NOR
Component: Metadata-Date
Assignee: digikam-bugs-n...@kde.org
Reporter: bbc.qui...@gmx.de
Target Milestone: ---
I've read some reports about the translation of Exiv tags to dates, but none of
them seems to fit, so I open this new one here for some curiosity I found:
I have TIFF images generated via an industrial camera - so no Exiv and such. On
the original drive Windows has equal timestamps for "creation" and
"modification". When copying those to a network drive windows sets "creation"
to the time of copy and leaves "modification" unchanged. Copying to the
computer running digiKam this happens again.
When digiKam reads those files it obviously uses "modification" as the
timestamp to store in Images.modificationDate as well as
ImageInformation.creationDate columns. This is OK for me (but also somehow
arguable regarding the names), as the creation of the image indeed is not in
line with the "creation" timestamp that Windows assigns to the file.
If the image is rotated using digiKam Images.modificationDate is updated to the
current timestamp (which is fine, too), but also ImageInformation.creationDate
is updated during that process to the original files "creation" timestamp
(which is the one from copying and has been skipped during the first read of
the file).
So behavior of using file timestamps for filling the database is not consistent
during the whole process. I would have expected the
ImageInformation.creationDate value not to be changing at all.
--
You are receiving this mail because:
You are watching all bug changes.
