[digiKam-users] DateTimeOriginal

[David McCreedy]

There's a change of behavior between 5.8.0 and 6.0/6.1.0 that is causing me headaches.
Under digiKam 5.8.0, the date for a photo in the Captions Description tab and the database's creationDate field was the EXIF DateTimeOriginal value.

In 6.x this is EXIF ModifyDate.
Is there an option in digiKam 6 that allows the previous behavior?
Is there another field in the database that contains the EXIF DateTimeOriginal value?

Thanks,
-David

[Gilles Caulier-4]

Hi,

With 6.1.0, The TimeAdjust plugin is back. Look in Item/Adjust Date & Time... menu entry. 

This must solve at least a part of your problem.

Anyway, look well in Setup/Metadata/Advanced panel to see which tags is used to get date from Exif.

Best

Gilles Caulier

Le sam. 27 avr. 2019 à 19:09, David McCreedy <[hidden email]> a écrit :

There's a change of behavior between 5.8.0 and 6.0/6.1.0 that is causing me headaches.
Under digiKam 5.8.0, the date for a photo in the Captions Description tab and the database's creationDate field was the EXIF DateTimeOriginal value.

In 6.x this is EXIF ModifyDate.
Is there an option in digiKam 6 that allows the previous behavior?
Is there another field in the database that contains the EXIF DateTimeOriginal value?

Thanks,
-David

[woenx]

I think that might be a side effect of the resolution of this bug:
https://bugs.kde.org/show_bug.cgi?id=338533

Dates in the image can be stored in three places: Exif, IPTC and XMP. In
turn, Exif has Creation date/time, Original date/time (what you referred in
the subject), and digitization date/time. IPTC also has digitization and
creation, and XMP digitization, creation and, for some reason, video date.

I am not sure how exactly the algorithm determines which is the "Creation
Date" that digikam uses from all these fields, but apparently if two or more
field matches, that date has a higher priority. In any case, in digikam 5.9
Exif's Creation date/time had a higher priority than Exif's Original
date/time, but that was changed.  That's because Creation date and time is
often considered a modified date/time by other software (picasa and
lightroom, at least)  and will get overwritten often, while and Original
date/time is the true "Creation Date" of the picture (should match
digitization date, if that field is used).  Actually, "EXIF creation date"
is called "Modify Date" in exiftool.

Yeah, it can be a  bit confusing.

I'd check the metadata of the image using the metadata editor, and see what
dates are there. Digikam's creation date should be either Exif "Original
date and time", Xmp "Creation date", or IPTC Creation date" as first
options. Or any digitization dates if these are not present or are not
consistent.

If you need to copy dates from one field to another from multiple pictures,
the TimeAdjust plugin does a good job.



--
Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html

[David McCreedy]

On the Configure, Metadata, Advanced tab I only see "Comment", "Rating", and
"Tags" in the drop-down for choosing sources.
Is there a way to add "dates" there or am I looking in the wrong place to
determine where digiKam determines which dates to use first?

Thanks,

-David



--
Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html

[Gilles Caulier-4]

Oups sorry. You are right, the handling in the settings panel is not
yet implemented.

And no, you cannot add this settings as well this require codes in
internal metadata hub.

Best
Gilles Caulier

Le dim. 28 avr. 2019 à 11:15, David McCreedy <[hidden email]> a écrit :

>
> On the Configure, Metadata, Advanced tab I only see "Comment", "Rating", and
> "Tags" in the drop-down for choosing sources.
> Is there a way to add "dates" there or am I looking in the wrong place to
> determine where digiKam determines which dates to use first?
>
> Thanks,
>
> -David
>
>
>
> --
> Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html

[woenx]

Hey, I upgraded to the last version
(digikam-6.2.0-git-20190426T172018-qtwebkit-x86-64.appimage), and I think I
am having similar problems. Pictures in the same folder are not sorted by
date, but apparently by name or last modification time? I am not sure, it's
hard to tell.

I put in a folder several pictures taken from a camera and from a phone,
from the same event, but first the pictures from the camera are displayed,
and then the ones from the phone, despite having overlapping pictures. I
have checked other folders and it's similar, pictures from different devices
are not intermixed despite sorting by date.

(Of course, I have checked that they are set to sorted by Creation date in
the menu).



--
Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html

[Maik Qualmann]

The DateTimeOriginal has a higher priority in the selection. Can you provide a
test image? By Private Mail?

Maik

Am Samstag, 27. April 2019, 19:57:17 CEST schrieb woenx:

> I think that might be a side effect of the resolution of this bug:
> https://bugs.kde.org/show_bug.cgi?id=338533
>
> Dates in the image can be stored in three places: Exif, IPTC and XMP. In
> turn, Exif has Creation date/time, Original date/time (what you referred in
> the subject), and digitization date/time. IPTC also has digitization and
> creation, and XMP digitization, creation and, for some reason, video date.
>
> I am not sure how exactly the algorithm determines which is the "Creation
> Date" that digikam uses from all these fields, but apparently if two or more
> field matches, that date has a higher priority. In any case, in digikam 5.9
> Exif's Creation date/time had a higher priority than Exif's Original
> date/time, but that was changed.  That's because Creation date and time is
> often considered a modified date/time by other software (picasa and
> lightroom, at least)  and will get overwritten often, while and Original
> date/time is the true "Creation Date" of the picture (should match
> digitization date, if that field is used).  Actually, "EXIF creation date"
> is called "Modify Date" in exiftool.
>
> Yeah, it can be a  bit confusing.
>
> I'd check the metadata of the image using the metadata editor, and see what
> dates are there. Digikam's creation date should be either Exif "Original
> date and time", Xmp "Creation date", or IPTC Creation date" as first
> options. Or any digitization dates if these are not present or are not
> consistent.
>
> If you need to copy dates from one field to another from multiple pictures,
> the TimeAdjust plugin does a good job.
>
>
>
> --
> Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html

[Maik Qualmann]

Thanks for the test image. It is recognized here with a creation date of
1999-09-14 01:00:00. I think it is correct.

Maik

Am Sonntag, 28. April 2019, 17:50:08 CEST schrieben Sie:

> The DateTimeOriginal has a higher priority in the selection. Can you provide
> a test image? By Private Mail?
>
> Maik
>
> Am Samstag, 27. April 2019, 19:57:17 CEST schrieb woenx:
> > I think that might be a side effect of the resolution of this bug:
> > https://bugs.kde.org/show_bug.cgi?id=338533
> >
> > Dates in the image can be stored in three places: Exif, IPTC and XMP. In
> > turn, Exif has Creation date/time, Original date/time (what you referred
> > in
> > the subject), and digitization date/time. IPTC also has digitization and
> > creation, and XMP digitization, creation and, for some reason, video date.
> >
> > I am not sure how exactly the algorithm determines which is the "Creation
> > Date" that digikam uses from all these fields, but apparently if two or
> > more field matches, that date has a higher priority. In any case, in
> > digikam 5.9 Exif's Creation date/time had a higher priority than Exif's
> > Original date/time, but that was changed.  That's because Creation date
> > and time is often considered a modified date/time by other software
> > (picasa and lightroom, at least)  and will get overwritten often, while
> > and Original date/time is the true "Creation Date" of the picture (should
> > match digitization date, if that field is used).  Actually, "EXIF
> > creation date" is called "Modify Date" in exiftool.
> >
> > Yeah, it can be a  bit confusing.
> >
> > I'd check the metadata of the image using the metadata editor, and see
> > what
> > dates are there. Digikam's creation date should be either Exif "Original
> > date and time", Xmp "Creation date", or IPTC Creation date" as first
> > options. Or any digitization dates if these are not present or are not
> > consistent.
> >
> > If you need to copy dates from one field to another from multiple
> > pictures,
> > the TimeAdjust plugin does a good job.
> >
> >
> >
> > --
> > Sent from:
> > http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html

[woenx]

Can you have a look at this screenshot too?

https://i.imgur.com/WyJfLop.png

The last picture was taken at 13:09, but it is placed after some pictures
taken at 14:53. If you observe the format of the filenames, you can see
pictures from different devices are not mixed together, despite having some
overlap in the dates.



--
Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html

[Maik Qualmann]

Change the item sorting and change back. We have added the sort by
modification date in the middle of the item sort option. It is possible that
there is a problem with the saved option in the config file.

Maik

Am Sonntag, 28. April 2019, 21:03:56 CEST schrieb woenx:

> Can you have a look at this screenshot too?
>
> https://i.imgur.com/WyJfLop.png
>
> The last picture was taken at 13:09, but it is placed after some pictures
> taken at 14:53. If you observe the format of the filenames, you can see
> pictures from different devices are not mixed together, despite having some
> overlap in the dates.
>
>
>
> --
> Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html

[woenx]

I already did that. I switched back and forth between filename, modification date and creation date, but that specific order in when sorted by creation date persists.

I don't quite understand why that happens.

[Maik Qualmann]

The sort order is correct here. I am also surprised that your test image is
correctly recognized here with 1999 and by you with 2018.
It almost looks like a comparison QDateTime1 < QDateTime2 is not working
correctly.
Your database is MySQL or SQLite?

Maik

Am Sonntag, 28. April 2019, 22:27:23 CEST schrieb Marc Palaus:
> I already did that. I switched back and forth between filename, modification
> date and creation date, but that specific order in when sorted by creation
> date persists.
 
> I don't quite understand why that happens.

[Maik Qualmann]

I would imagine that there is a locale problem between the AppImage and the
system. We have a similar problem with MySQL and the interpretation of the
decimal separator (dot / comma) in geolocation data.

Maik

Am Sonntag, 28. April 2019, 22:39:53 CEST schrieben Sie:

> The sort order is correct here. I am also surprised that your test image is
> correctly recognized here with 1999 and by you with 2018.
> It almost looks like a comparison QDateTime1 < QDateTime2 is not working
> correctly.
> Your database is MySQL or SQLite?
>
> Maik
>
> Am Sonntag, 28. April 2019, 22:27:23 CEST schrieb Marc Palaus:
> > I already did that. I switched back and forth between filename,
> > modification date and creation date, but that specific order in when
> > sorted by creation date persists.
> >
> > I don't quite understand why that happens.

[David McCreedy]

My database is SQLite (for both 5.8.0 and 6.x versions).  I'm running Windows
10.

-David



--
Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html

[woenx]

I suppose you meant to respond to David earlier.

Anyway, I found why that happens. It's possibly not related to David's issue
(so I apologize for hijacking this thread). It might be a bug, I can report
it if you want.

Although Digikam shows the exif "Original date and time" date in the
miniature view (correct), it uses the exif "Creation date and time" for
sorting. It's not a big deal actually.

Have a look: https://i.imgur.com/sEGZvfo.png



--
Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html

[David McCreedy]

Sorry for the delayed response... I was out of town.
Unfortunately on my system the date shows as 1/22/2018 for the p031a.jpg
test image.
Attached is, hopefully, a screenshot.

I tested out the priority digiKam gives to three date fields and, as you
noted, it has changed.
Priority for digiKam 5.8 is 1=DateTimeOriginal (ExifIFD), 2=CreateDate
(ExifIFD), 3=ModifyDate (IFD0) (field names are from exiftool).
digiKam 6.x changes this to 1=ModifyDate (IFD0), 2=DateTimeOriginal
(ExifIFD), 3=CreateDate (ExifIFD)
I could do a one-time adjustment to copy DateTimeOriginal to ModifyDate to
get the 5.8 behavior in 6.x but Photoshop updates ModifyDate so every time I
update a photo I'd hit the same problem.
BTW: The DBSCHEMA.ODS spreadsheet at https://www.digikam.org/documentation/
should be updated.  The Images workbook still shows the 5.8 order for the
creationDate field (Exif.Photo.DateTimeOriginal,
Exif.Photo.DateTimeDigitized, Exif.Image.DateTime,
Iptc.Application2.DateCreated, Iptc.Application2.DigitizationTime,
xmp:DateTime).
<http://digikam.1695700.n4.nabble.com/file/t376839/screenshot.jpg>



--
Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html

[woenx]

A developer could explain it better, but I think it's a bit more complicated
than that. I think that if any two dates match, that date has priority over
the others. That's what may be happening here. Check if the wrong date is
present in any other field (IPTC or XMP) using the metadata editor.

My personal recommendation, specially in scanned photos, is to use Exif's
Original Date (and Exif digitized date if you wish, to store when it was
scanned), and leave the other date fields empty. Other picture software will
rewrite the Exif Creation date (and, occasionally, XMP Creation date, which
shouldn't be ok), so don't rely on that field.

Also, just in case, make sure the picture metadata is re-read after making
some changes (Item, Re-read metadata from file). In my experience it was not
automatically refreshed in windows.



--
Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html

[David McCreedy]

The "two dates match" was the key for me.  After seeing that I noticed that
the pictures with different dates in digiKam 5.8 vs 6.x were ones with a
Exif DateTimeOriginal but no CreateDate (to use exiftoolGUI field names).  I
used exiftool to copy the DateTimeOriginal to CreateDate and now I have the
same dates in both major version of digiKam.

Thanks for your help.

-David



--
Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html