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

B.M. b-misc at gmx.ch
Mon Apr 23 08:42:10 BST 2018 

I think that's the case (will check in the evening). Unfortunately I didn't see that bug report when I searched for it - apparently my result list was too long, sorry for that.

I added some thoughts on date / time handling there.

Best,
Bernd 

Am 22. April 2018 21:11:56 MESZ schrieb Maik Qualmann <metzpinguin at gmail.com>:
>I think the cause is this problem:
>https://bugs.kde.org/show_bug.cgi?id=386959
>
>Maik
>
>Am Sonntag, 22. April 2018, 20:37:41 CEST schrieb B.M.:
>> Hi,
>> 
>> I further checked other affected files, and here's an example which
>doesn't
>> have the conflicting date/times:
>> 
>> $ exiftool DSC_0014.jpg | grep Date
>> File Modification Date/Time     : 2018:02:18 15:41:47+01:00
>> File Access Date/Time           : 2018:04:21 21:17:03+02:00
>> File Inode Change Date/Time     : 2018:02:18 15:45:03+01:00
>> Modify Date                     : 2012:04:21 15:00:50
>> Date/Time Original              : 2012:04:21 15:00:50
>> Create Date                     : 2012:04:21 15:00:50
>> Date Display Format             : D/M/Y
>> Create Date                     : 2012:04:21 15:00:50.20
>> Date/Time Original              : 2012:04:21 15:00:50.20
>> Modify Date                     : 2012:04:21 15:00:50.20
>> 
>> $ grep Date DSC_0014.jpg.xmp
>>    xap:CreateDate="2012-04-21T15:00:50"
>>    xap:MetadataDate="2012-04-21T15:00:50"
>>    xap:ModifyDate="2012-04-21T15:00:50"
>>    exif:DateTimeOriginal="2012-04-21T15:00:50.20"
>>    exif:DateTimeDigitized="2012-04-21T15:00:50.20"
>>    tiff:DateTime="2012-04-21T15:00:50.20"
>>    photoshop:DateCreated="2012-04-21">
>> 
>> Should I continue the discussion in a bug report?
>> 
>> Can you give me a hint how I can correct that using exiftool (which
>> date/time should I keep / remove)?
>> 
>> Also I want to repeat my observation that I had the very same "wrong"
>date/
>> time shown in digikam when I deleted all digikam databases and
>recreated
>> them; but when I copied affected test images to a new user his
>digikam
>> instance (same machine) showed the date/time correctly. I don't see
>yet how
>> that is possible.
>> 
>> Best,
>> Bernd
>> 
>> On Sonntag, 22. April 2018 15:16:59 CEST Gilles Caulier wrote:
>> > Modify Date                     : 2001:01:01 01:21:57
>> > Date/Time Original              : 2012:04:21 13:59:20
>> > 
>> > ^^^ how it's possible to create a file in 2012 and modify it in
>2001 ???
>> > 
>> > Gilles Caulier
>> > 
>> > 2018-04-22 15:10 GMT+02:00 B.M. <b-misc at gmx.ch>:
>> > > Well, I'd appreciate a bit more inputs - why exactly is the jpeg
>file a
>> > > mess?
>> > > There are several dates (modify, create, file modification and
>file
>> > > access) and
>> > > information is reduntant, but I don't see conflicting date/time
>> > > information.
>> > > 
>> > > What I started with is overwriting Original Date by Create Date,
>but
>> > > doing
>> > > it
>> > > with the BQM for several 10'000 files in many different folders
>takes
>> > > quite
>> > > some time, so I decided to stop it and have a look to find out
>what
>> > > really
>> > > is
>> > > the case.
>> > > 
>> > > A exiftool-based script would be faster and (for me) easier, but
>what
>> > > should I
>> > > keep / remove exactly? And: the exiftool command I mentioned (see
>last
>> > > message) didn't change any date/time information, did it?
>> > > 
>> > > Thank you!
>> > > 
>> > > Best,
>> > > Bernd
>> > > 
>> > > On Sonntag, 22. April 2018 11:48:20 CEST Gilles Caulier wrote:
>> > > > 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/20180423/53021b7c/attachment.html>

More information about the Digikam-users mailing list