Add support for XMP metadata
|Assignee:||Andreas Huggel||% Done:|
XMP metadata can be supported as a new type of metadata - with conversions to/from Exif/IPTC
or XMP as a new data format to read Exif and IPTC data from - in this case, the read/write functions need to know which format to prioritize.
First, this requires further research and a decision whether it makes sense to support XMP with the Exiv2 framework.
#1 Updated by Andreas Huggel almost 12 years ago
This is roughly how I see XMP support:
+ It is a new type of metadata, only the extended IPTC stuff is
supported for a start (Dublin Core schema).
The related metadata keys will start with Xmp instead of Exif
+ A new class XmpData is the container for XMP data (copy and paste
IptcData to get started - not the other one)
+ Use an XML parser to help decoding and encoding from the XML structure
to Exiv2 Key/Value Metadatum (Xmpdatum) objects (my guess is libxml2,
but I haven't evaluated any yet). This will be the most
+ Start with JPEG format (or maybe PNG)
Ok, thanks. For these informations.
I never used libxml2 because Qt have a perfect XML parser. But F-SPOT use this
one if i remember (in all case, it' support XMP)
Also, Gimp currently support partially XMP (in current implementation from cvs
Also, there is the official XMP toolkit from Adobe witch can use like a
reference if we have some problem to implemente it into Exiv2...
#2 Updated by Andreas Huggel almost 12 years ago
Some additional info about XML parsers is in this thread:
(and this note is mainly to test if it goes to the group now.)
#4 Updated by Gilles Caulier over 11 years ago
I recommend you to take a look here :
This way can be a fast solution to add XMP support on Exiv2
#6 Updated by Andreas Huggel over 11 years ago
XMP support in Exiv2 should use the existing Exiv2 API and
infrastructure where possible. In particular, the interface to access
XMP metadata in files should remain Exiv2::Image so that a call to
Exiv2::Image::readMetadata() scans a file only once and loads Exif,
IPTC as well as XMP into tag/value structures (ExifData, IptcData,
XmpData for the time being, eventually, a common class for all
metadata). This implies that in Exiv2, XMP tags will be accessed with
keys, similar to the existing Exif and IPTC keys. "Standard" conversion
classes to convert between Exif, IPTC and XMP could then become part of
If that cannot be done, then I don't see the point of adding XMP support
Where I see a potential to save time by using Adobe's library/exempi is
with the low-level decoding and encoding parts, i.e., scanning XML to
decode the relevant bits (the "keys" and the "values") and the other
way around on write. And maybe they have code to access file types
which Exiv2 doesn't support yet.
Another alternative is of course to use 2 libraries, one for XMP and one
for Exif/IPTC and develop conversion classes outside of both of them.
But this would require that the client calls each library's API to read
its respective metadata, i.e., scans the file twice, and that the
application maintains the conversion code.
Would it help in the short term if Exiv2::Image provided some kind of
getXmp/setXmp methods (at least for JPEGs) which would just deal with
std::string BLOBs containing the raw XML? This would allow to
read/write the data using Exiv2::Image::read/writeMetadata but require
some other means to parse the XML.
#8 Updated by Andreas Huggel over 11 years ago
On Wednesday 20 June 2007 16:33, Gilles Caulier wrote:
Where we will store XMP schema from Adobe, M$ etc...?
Look ExifTool database for details :
This is the job to Exiv2 or a high level interface as libkexiv2 ?
My preliminary thinking is that Exiv2 will use these just like the
existing tag lists. Exiv2 XMP key strings would then be
or "Xmp.photoshop.Category" etc.
Or are there more levels than namespace and tag name? i.e., can XML
namespaces be nested?