Bug #639

Editing existing XMP properties in XMP sidecars does not work

Added by Vladimir Nadvornik over 8 years ago. Updated 7 months ago.

Status:NewStart date:14 Jun 2009
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:xmp
Target version:1.0

Description

XMP sidecar converts xmp to exif and iptc on read and back on write. Changes done
directly in XMP are overwritten.

For example calling this on a file that already has Xmp.tiff.Orientation=1 has no effect:
exiv2 -M"set Xmp.tiff.Orientation 4" test.xmp

This is related to bug #601


Related issues

Related to Exiv2 - Bug #601: Metadata conversion enhancements Closed 07 Jan 2009
Related to Exiv2 - Feature #941: Upgrade xmpsdk source to Adobe's current version Assigned 27 Dec 2013

History

#1 Updated by Alan Pater over 2 years ago

  • Status changed from New to Assigned
  • Assignee set to Alan Pater
  • Target version set to 0.25

I am wondering if we really have a bug here. My testing indicates that if we set the orientation via the exif tag, rather then the xmp property, it works. The MWG guidelines indicate that this field is set through the exif tag, not the xmp property.

Working set of commands:

$ exiv2 -M"set Exif.Image.Orientation 4" test.xmp
$ exiv2 -iX test.jpg
$ exiv2 -g Orientation test.jpg
Exif.Image.Orientation                       Short       1  bottom, left
Xmp.tiff.Orientation                         XmpText     1  bottom, left

#2 Updated by Alan Pater over 2 years ago

Let's take another look at this. Perhaps further testing is needed.

Writing XMP data to sidecar file fails: http://dev.exiv2.org/boards/3/topics/1717

#3 Updated by Alan Pater over 2 years ago

  • Assignee changed from Alan Pater to Robin Mills

Right. What happens is that IF the XMP property in question is one of those mapped in convert.cpp then it can't be modified directly in the XMP sidecar. Instead one needs to modify the mapped EXIF or IPTC tag.

The mapped XMP property can be set initially in the sidecar if it does not yet exist. But once it does exist there, the EXIF or IPTC tags take precedence.

For properties which are not mapped in the conversion tables, modifying them in the XMP sidecar works. For example:

$ exiv2 -M"set Xmp.dc.identifier bug1717" test.xmp
$ exiv2 -g identifier test.xmp
Xmp.dc.identifier                            XmpText     6  bug1717

$ exiv2 -M"set Xmp.dc.identifier bug639" test.xmp
$ exiv2 -g identifier test.xmp
Xmp.dc.identifier                            XmpText     6  bug639

Robin, what do you think? What is there in convert.cpp that blocks modifying these properties?

#4 Updated by Robin Mills over 2 years ago

  • Assignee changed from Robin Mills to Andreas Huggel
  • Target version changed from 0.25 to 0.26

What do I think? Honestly? sidecar files are a bodge. I believe the purpose of XMP sidecar files is:

  1. To hold metadata about files which cannot embed XML (e.g. BMP)
  2. To make it easy to update metadata in large files without rewriting the whole file
  3. To enable other tools to index and search resources.

And these are very desirable features.

The problem however is that there is data duplicated between the sidecar and the resource - resolution, color space, pixel format, orientation, width, height and other stuff. And of course the XMP can be out of sync when embedded. However it's doubly troublesome in an external sidecar file.

I feel we should do nothing further about this and focus on releasing v0.25. I hope that v0.26 will link Adobe's XMPsdk as an external library (#941). So, I've assigned this one to Andreas to consider as part of #941. I've set the target version to 0.26.

#5 Updated by Robin Mills almost 2 years ago

  • Target version changed from 0.26 to 1.0

I'm setting Target = 1.0 because it will be considered with #941 which has Target == 1.0.

#6 Updated by Robin Mills 7 months ago

  • Status changed from Assigned to New
  • Assignee deleted (Andreas Huggel)

Also available in: Atom PDF

Redmine Appliance - Powered by TurnKey Linux