Bug 407034 - Editing an image in the Image editor adds a XMP video date field.
Summary: Editing an image in the Image editor adds a XMP video date field.
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Metadata-Xmp (show other bugs)
Version: 6.1.0
Platform: Appimage Linux
: NOR normal
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-04-28 23:03 UTC by MarcP
Modified: 2021-05-09 17:00 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In: 7.3.0
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description MarcP 2019-04-28 23:03:43 UTC
SUMMARY

Apparently, editing an image using Digikam's Image editor (and saving it as a new version, at least), adds the XMP Video Date field, copying the date from the XMP Creation date. But it depends on the existing metadata, as it not happens in all cases.

Check this screen capture: https://i.imgur.com/A2Zu7Wv.gifv

I am pretty sure there are other cases where digikam adds the XMP Video Date, but this is the only one I've been able to identify.

STEPS TO REPRODUCE
1. Check image in the metadata editor to make sure that the XMP Video date is empty.
2. Use the image editor, and save the image as a new version.
3. Check the metadata of that new image, and observe how the XMP Video date is no longer empty.

OBSERVED RESULT
Digikam has added a date in the XMP Video Date field.

EXPECTED RESULT
Metadata should be identical to that of the source picture.

SOFTWARE/OS VERSIONS
Ubuntu 18.04 with gnome and digikam-6.2.0-git-20190423T140539-qtwebkit-x86-64.appimage
Comment 1 caulier.gilles 2019-04-29 02:48:02 UTC
*** Bug 407033 has been marked as a duplicate of this bug. ***
Comment 2 Maik Qualmann 2019-04-29 06:02:56 UTC
Problem is not reproduce here. The "video date" can only add the TimeAdjust Tool or the Metadata Editor. Where else is there no code for it. The Image Editor only copies the metadata from the original image. Does a sidecar file exist?

Maik
Comment 3 Maik Qualmann 2019-04-29 06:12:09 UTC
Yes that's the cause, you've written in sidecar and now has disabled again. I have to see why the image editor, although disabled, reads from the sidecar.

Maik
Comment 4 MarcP 2019-04-29 08:44:57 UTC
Do you mean that digikam momentarily created a sidecar and then deleted it after reading? (Sidecars are disabled in the settings, and I can't see any sidecar file in the folder the picture is stored. Weird=.

Look, here is the original picture in which I observed this behavior, in case you want to test it by yourself: https://drive.google.com/open?id=1CvSTNv7lbFmYG_fqFhZIJshdSyLiXp_L
Comment 5 Maik Qualmann 2019-04-29 19:50:02 UTC
I can not reproduce the problem now. Is also not dependent on the sidecar. I was wrong this morning because I used two very similar images to test, one with video date and one without. If you can reproduce it exactly, please a step by step instructions.

Maik
Comment 6 MarcP 2019-04-30 14:54:06 UTC
I don't know, it seems a bit complex. I am able to reproduce this behavior in that specific picture, but not in other pictures with equal metadata. So I guess it depends on the very specific metadata of the file? Maybe it has non-standard format that triggers that effect when metadata is written?

Moreover, every now and then I found that the Video Date tag has been added (copied from the xmp Creation date) to a picture, and I don't know exactly how that happens. I barely use the Image editor, so I'm pretty sure it also happens by doing some other actions. And I mainly use Digikam nowadays, so I suspect it's not other software's fault.

(Btw, that was the reason I opened bug #398624 and bug #405825 back in the day.)

I will keep you updated if I find out more.
Comment 7 caulier.gilles 2019-07-24 05:46:53 UTC
Hi,

This problem still reproducible using last Linux AppImage bundle 6.2.0 pre release available here : https://files.kde.org/digikam/

Thanks in advance

Gilles Caulier
Comment 8 caulier.gilles 2020-08-01 14:27:40 UTC
digiKam 7.0.0 stable release is now published and now available as FlatPak:

https://www.digikam.org/news/2020-07-19-7.0.0_release_announcement/

We need a fresh feedback on this file using this version.

Thanks in advance

Gilles Caulier
Comment 9 MarcP 2020-08-01 15:14:33 UTC
This bug is still present. I experienced it yesterday in a batch of pictures I scanned yesterday. At some point, the xmp metadata autopopulates (it gets copied from some value in the exif, I think), including the video tag. I don't know when it happens, maybe when tagging or geolocating them?

But in any case it's quite consistent, it happens every time I work with scanned photos, and I have to manually remove the xmp and iptc dates.
Comment 10 caulier.gilles 2021-05-05 05:45:47 UTC
Mark,
I tried to reproduce the problem with your image shared by GDrive. I cannot.

I imported in editor the JPEG and exported to TIFF. There is no XMP video tag appended. I double checked with ExifTool metadata view (digiKam 7.3.0 support ExifTool now)...

So, my Q is: what do you do exactly in editor ? Do you use a specific tool to apply on image ? How do you scan your image ? Which software is used ? There is a XMP sidecar file with scanned images ?

Gilles Caulier
Comment 11 caulier.gilles 2021-05-09 03:42:04 UTC
Maik,

I can reproduce the problem with an unit test.

I written a DMetadata method to list changes to perform of file before to apply. This list Exif, Iptc and Xmp tags modified.

https://invent.kde.org/graphics/digikam/-/blob/master/core/libs/metadataengine/engine/metaengine.cpp#L258

The unit test load a file and call DMetadata::setImageDateTime() with current date. Finaly i list changes without to apply.

https://invent.kde.org/graphics/digikam/-/blob/master/core/tests/metadataengine/dmetadatadiff_cli.cpp

Look the result with a simple JPEG image:

 [gilles@localhost metadataengine]$ exiv2 -pa M104.jpg 
Exif.Image.ImageDescription                  Ascii      14  IDL TIFF file
Exif.Image.Orientation                       Short       1  haut, gauche
Exif.Image.XResolution                       Rational    1  600
Exif.Image.YResolution                       Rational    1  600
Exif.Image.ResolutionUnit                    Short       1  Pouce
Exif.Image.Software                          Ascii      20  Adobe Photoshop 7.0
Exif.Image.DateTime                          Ascii      20  2003:09:25 17:30:51
Exif.Image.ExifTag                           Long        1  180
Exif.Photo.ColorSpace                        Short       1  Non calibré
Exif.Photo.PixelXDimension                   Long        1  11472
Exif.Photo.PixelYDimension                   Long        1  6429
Exif.Thumbnail.Compression                   Short       1  JPEG (ancienne version)
Exif.Thumbnail.XResolution                   Rational    1  72
Exif.Thumbnail.YResolution                   Rational    1  72
Exif.Thumbnail.ResolutionUnit                Short       1  Pouce
Exif.Thumbnail.JPEGInterchangeFormat         Long        1  318
Exif.Thumbnail.JPEGInterchangeFormatLength   Long        1  12385
Iptc.Application2.RecordVersion              Short       1  2
Iptc.Application2.Caption                    String     13  IDL TIFF file
Xmp.xmpMM.DocumentID                         XmpText    58  adobe:docid:photoshop:85e8fa57-a0f3-11d7-aea6-e74f76773090
Xmp.xmpMM.InstanceID                         XmpText    41  uuid:af6d5080-ef91-11d7-96ef-9036d9cb0c44
Xmp.dc.description                           LangAlt     1  lang="x-default" IDL TIFF file

./dmetadatadiff_cli M104.jpg
digikam.metaengine: Loading metadata with "Exiv2" backend from "M104.jpg"
digikam.metaengine: List of changes to perform on: "M104.jpg"
digikam.metaengine: New Exif tag Exif.Photo.DateTimeOriginal with value 2021:05:09 05:35:42
digikam.metaengine: New Exif tag Exif.Photo.DateTimeDigitized with value 2021:05:09 05:35:42
digikam.metaengine: New Iptc tag Iptc.Application2.DateCreated with value 2021-05-09
digikam.metaengine: New Iptc tag Iptc.Application2.TimeCreated with value 05:35:42+00:00
digikam.metaengine: New Iptc tag Iptc.Application2.DigitizationDate with value 2021-05-09
digikam.metaengine: New Iptc tag Iptc.Application2.DigitizationTime with value 05:35:42+00:00
digikam.metaengine: New Xmp tag Xmp.exif.DateTimeOriginal with value 2021-05-09T05:35:42
digikam.metaengine: New Xmp tag Xmp.photoshop.DateCreated with value 2021-05-09T05:35:42
digikam.metaengine: New Xmp tag Xmp.tiff.DateTime with value 2021-05-09T05:35:42
digikam.metaengine: New Xmp tag Xmp.xmp.CreateDate with value 2021-05-09T05:35:42
digikam.metaengine: New Xmp tag Xmp.xmp.MetadataDate with value 2021-05-09T05:35:42
digikam.metaengine: New Xmp tag Xmp.xmp.ModifyDate with value 2021-05-09T05:35:42
digikam.metaengine: New Xmp tag Xmp.video.DateTimeOriginal with value 2021-05-09T05:35:42
digikam.metaengine: New Xmp tag Xmp.video.DateUTC with value 2021-05-09T05:35:42
digikam.metaengine: New Xmp tag Xmp.video.ModificationDate with value 2021-05-09T05:35:42
digikam.metaengine: New Xmp tag Xmp.exif.DateTimeDigitized with value 2021-05-09T05:35:42
digikam.metaengine: New Xmp tag Xmp.video.DateTimeDigitized with value 2021-05-09T05:35:42

Look like XMP includes new video time stamp tags...

Gilles
Comment 13 caulier.gilles 2021-05-09 03:58:17 UTC
Git commit 10cdfe4a5aedb3c38303fba8d3d8f1e72d6e2ead by Gilles Caulier.
Committed on 09/05/2021 at 03:55.
Pushed by cgilles into branch 'master'.

Do not add Xmp video date-time stamp tags on non video files
Related: bug 407033
FIXED-IN: 7.3.0

M  +12   -4    core/libs/metadataengine/engine/metaengine_item.cpp
M  +1    -0    core/libs/metadataengine/engine/metaengine_p.h

https://invent.kde.org/graphics/digikam/commit/10cdfe4a5aedb3c38303fba8d3d8f1e72d6e2ead
Comment 14 MarcP 2021-05-09 16:57:09 UTC
Hello Gilles, 

sorry, I just saw your email.

I wouldn't know exactly how to replicate this behavior, because it was a long time ago that I reported it, but I know that it still happens from time to time. 

My usual workflow is the following:

1. I scan a picture using XSane in PNG Format.
2. I apply some corrections (deskew, color temperature) using some imagemagick scripts. 
3. In some cases, I use an external tool (Gigapixel AI) to improve the resolution.
4. I convert the png files to jpg.
5. I put them in my picture libraries, and let digikam scan them.
6. In digikam, I tag the pictures, geolocalize, and enter the date (by default, I only save it to EXIF.

It's at some point that I realize that the date I enter is not being applied, and when I check why, I see there's another date in the xmp video field. 

But only happens in some cases, not all the time.

Anyway, I see that you found something. I hope that was the cause of the issue.

Thanks in any case!
Comment 15 caulier.gilles 2021-05-09 17:00:25 UTC
Yes i found the origin of the problem. Thanks to unit tests which allow to check function and feature step by step...