[digiKam-users] digikam shows wrong create time in thumbnail view - replicable for one user, not for a different one

Sun Apr 22 10:48:20 BST 2018

The jpeg file is a mess. The sidecar sound right.

I cannot recommend to drop date in image files, or at least to let few
important one, especially in Exif, just in case where is plan to go back to
a workflow without sidecar.

Let's standard Exif time stamp and patch the tags with right value with
your script. All other one can be dropped, as IPTC and XMP, as sidecar do
the job instead.

Gilles Caulier

2018-04-22 11:34 GMT+02:00 B.M. <b-misc at gmx.ch>:

> Hi,
>
> Thank you Gilles for your fast answer, can you maybe help me understanding
> the
> second paragraph, I add some more data from a photo showing "wrong" time
> stamps:
>
> $ exiftool DSC_0003.jpg | grep Date
> File Modification Date/Time     : 2018:02:18 15:41:57+01:00
> File Access Date/Time           : 2018:04:21 21:17:01+02:00
> File Inode Change Date/Time     : 2018:02:18 15:45:03+01:00
> Modify Date                     : 2001:01:01 01:21:57
> Date/Time Original              : 2012:04:21 13:59:20
> Create Date                     : 2012:04:21 13:59:20
> Date Display Format             : D/M/Y
> Profile Date Time               : 1998:02:09 06:49:00
> Create Date                     : 2012:04:21 13:59:20.00
> Date/Time Original              : 2012:04:21 13:59:20.00
> Modify Date                     : 2001:01:01 01:21:57.00
>
> $ grep Date DSC_0003.jpg.xmp
>    xmp:CreateDate="2012-04-21T13:59:20"
>    xmp:MetadataDate="2012-04-21T13:59:20"
>    xmp:ModifyDate="2012-04-21T13:59:20"
>    exif:DateTimeOriginal="2012-04-21T13:59:20.00"
>    exif:DateTimeDigitized="2012-04-21T13:59:20.00"
>    tiff:DateTime="2012-04-21T13:59:20.00"
>    photoshop:DateCreated="2012-04-21">
>
> So I don't see any inconsistencies in the metadata.
>
> But I modified my image metadata (should be a cleanup) using a script some
> weeks ago and so I thought indeed that there might be a connection:
>
> exiftool -XMP-digiKam:TagsList= -XMP-lr:HierarchicalSubject= -XMP-
> microsoft:LastKeywordXMP= -IPTC:Keywords= -XMP-dc:Subject=
> -overwrite_original
> -r -ext jpg -ext JPG -ext jpeg -ext JPEG <my folders>
>
> The idea for that command was a huge cleanup; since I switched to the
> "write
> to sidecar files only" option for some years now, I wanted to remove all
> self-
> created metadata from the image files themselves, keep them only in the
> sidecar
> files. Because otherwise I expected to get duplicate and potentially non-
> synchronized metadata.
>
> Do you see anything?
>
> Thank you very much.
>
> Best,
> Bernd
>
> On Sonntag, 22. April 2018 10:49:54 CEST Gilles Caulier wrote:
> > Hi,
> >
> > This is an old behavior that i coded few years ago. There are many many
> > tags relevant of date time in Exif (and also IPTC and XMP)
> >
> > Typically, i preserved a date time tags with "original" shot date when
> user
> > patch a wrong time stamp in metadata, just in case. this one must never
> be
> > used in DK database while scanning.
> >
> > I currently working in 6.0.0 source code to review all metadata engine
> and
> > i will drop this feature definitively as this can introduce side effects.
> >
> > Please report this problem in bugzilla (or look if one do not already
> > exist), and comment inline.
> >
> > Thanks in advance.
> >
> > Gilles Caulier
> >
> > 2018-04-22 9:19 GMT+02:00 B.M. <b-misc at gmx.ch>:
> > > Dear all,
> > >
> > > I have a somehow strange problem: wrong Created Times are shown,
> > > replicable,
> > > but only for a certain user.
> > >
> > > Since at least a week or so, digikam shows "wrong" times in thumbnail
> > > view,
> > > which results in a wrong sorting.
> > >
> > > E.g. I have a picture which shows 02.03.12 01:00
> > > The properties tab on the right shows Created 02.03.12 01:00 (wrong)
> > >
> > > The metadata tab shows for EXIF:
> > >   Date and Time 02.03.12 13:53:45 (correct)
> > >   Date and Time (digitized) 02.03.12 13:53:45 (correct)
> > >   Date and Time (original) 02.03.12 01:00:00 (wrong)
> > >
> > > for IPTC:
> > >   Date Created 2012-03-02
> > >   Digitization Date 2012-03-02
> > >   Time Created 13:53:45+00:00 (correct)
> > >
> > > Interestingly, if I look at my different album folders, not all
> pictures
> > > are
> > > affected; in typical folders, about 30 - 60% show wrong times. Most
> > > folders
> > > are affected, but not all.
> > >
> > > The wrong times is 01:00:00 for most of the pictures, but 02:00:00 is
> > > shown as
> > > well, other times are not shown. It seem to be folder-specific, i.e.
> in a
> > > certain album folder it's either 01:00:00 or 02:00:00.
> > >
> > > If I rebuild digikam's databases (by renaming the old ones) I get the
> same
> > > wrong times (especially the wrong one in the thumbnail view).
> > >
> > > But if I copy the image (and its xmp sidecar file) to a new (test)
> user on
> > > the
> > > same machine and he imports it (new digikam setup), the correct time
> > > (13:53)
> > > is shown for this different user.
> > >
> > > I realized this behaviour about a week ago but didn't use digikam for
> some
> > > weeks before. But I don't think this happened before (I'd noticed it),
> but
> > > if
> > > I look at different album folders I get the impression that and
> increasing
> > > number is affected. My system is Debian Stable, with digikam 5.3.0.
> > >
> > > If I check with exiftool, I correctly get
> > >
> > >   Date/Time Original              : 2012:03:02 13:53:45
> > >   Sub Sec Time Original           : 00
> > >   Date/Time Original              : 2012:03:02 13:53:45.00
> > >
> > > (but why is it reported twice?)
> > >
> > > All files are on the same disk.
> > >
> > > What could be the reason for this weird behavior? Thank you for your
> > > support!
> > >
> > > No, I didn't drink too much beer or wine for the current high
> temperatures
> > > here in continental Europe...
> > >
> > > Best regards,
> > > Bernd
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digikam-users/attachments/20180422/d993eab6/attachment.html>