Bug 273811 - HUB : recreate file metadata taking information stored in database
Summary: HUB : recreate file metadata taking information stored in database
Status: CONFIRMED
Alias: None
Product: digikam
Classification: Applications
Component: Metadata-Hub (show other bugs)
Version: 2.0.0
Platform: Compiled Sources Linux
: NOR wishlist
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
: 283011 (view as bug list)
Depends on:
Blocks:
 
Reported: 2011-05-21 19:29 UTC by rene
Modified: 2021-03-09 05:51 UTC (History)
2 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description rene 2011-05-21 19:29:14 UTC
Version:           2.0.0 (using KDE 4.5.5) 
OS:                Linux

Rewriting an xmp sidecar file using the Picture-> rewrite Metadata (in German Bild -> Metadaten in das Bild schreiben) only writes part of the available Metadata to the file.

Reproducible: Always

Steps to Reproduce:
select an image
Assign Coordinates using the Geolocation tool
Check the xmp file:

<?xml version="1.0" encoding="UTF-8"?>
<x:xmpmeta xmlns:x="adobe:ns:meta/" x:xmptk="XMP Core 4.4.0-Exiv2">
 <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
  <rdf:Description rdf:about=""
    xmlns:exif="http://ns.adobe.com/exif/1.0/"
   exif:GPSVersionID="2.0.0.0"
   exif:GPSMapDatum="WGS-84"
   exif:GPSLatitudeRef="N"
   exif:GPSLatitude="50,47.06539122N"
   exif:GPSLongitudeRef="E"
   exif:GPSLongitude="7,9.59396638E"/>
 </rdf:RDF>
</x:xmpmeta>

Delete the xmp file and recreate it using the picture->write metadata to picure menue item

check the xmp file

Actual Results:  
Not all metadata has been written to the xmp file 

the GPS Data is missing although it is still present in the database (the geolocation tab on the right side correctly places the image on the map).

<?xml version="1.0" encoding="UTF-8"?>
<x:xmpmeta xmlns:x="adobe:ns:meta/" x:xmptk="XMP Core 4.4.0-Exiv2">
 <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
  <rdf:Description rdf:about=""
    xmlns:tiff="http://ns.adobe.com/tiff/1.0/"
    xmlns:xmp="http://ns.adobe.com/xap/1.0/"
    xmlns:exif="http://ns.adobe.com/exif/1.0/"
    xmlns:photoshop="http://ns.adobe.com/photoshop/1.0/"
    xmlns:digiKam="http://www.digikam.org/ns/1.0/"
    xmlns:MicrosoftPhoto="http://ns.microsoft.com/photo/1.0/"
   tiff:Software="digiKam-2.0.0-beta6"
   tiff:DateTime="2011-05-04T11:59:18"
   xmp:CreatorTool="digiKam-2.0.0-beta6"
   xmp:CreateDate="2011-05-04T11:59:18"
   xmp:MetadataDate="2011-05-04T11:59:18"
   xmp:ModifyDate="2011-05-04T11:59:18"
   xmp:Rating="0"
   exif:DateTimeOriginal="2011-05-04T11:59:18"
   photoshop:DateCreated="2011-05-04T11:59:18"
   digiKam:PickLabel="0"
   digiKam:ColorLabel="0"
   MicrosoftPhoto:Rating="0"/>
 </rdf:RDF>
</x:xmpmeta>



Expected Results:  
the xmp file is recreated with all available metadata
Comment 1 Marcel Wiesweg 2012-03-19 20:31:47 UTC
This is not a sidecar issue. Delete the metadata from the file with exiv2, and call the above function: you will get the same result. The "write metadata to file" function refers only to the properties which are edited by digikam, mostly tags, rating, comments, copyright and IPTCcore properties.
The GPS is stored in the database as a cache, but as with other data such as shutter speed or aperture, the primary storage is only the metadata, and there is currently no method to recreate lost metadata from cached values.

Obviously, using metadata is easier if it's separate in a sidecar, but technically there is no difference.

This remains a wish for a metadata recreation function (which will, btw, necessarily be incomplete compared to the original file)
Comment 2 caulier.gilles 2014-08-28 15:42:03 UTC
*** Bug 283011 has been marked as a duplicate of this bug. ***
Comment 3 Justin Zobel 2021-03-09 05:51:38 UTC
Thank you for the bug report.

As this report hasn't seen any changes in 5 years or more, we ask if you can please confirm that the issue still persists.

If this bug is no longer persisting or relevant please change the status to resolved.