<br><br><div><span class="gmail_quote">2007/6/20, Andreas Huggel <<a href="mailto:ahuggel@gmx.net">ahuggel@gmx.net</a>>:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

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,

<br>IPTC as well as XMP into tag/value structures (ExifData, IptcData,<br>XmpData for the time being, eventually, a common class for all<br>metadata). This implies that in Exiv2, XMP tags will be accessed with<br>keys, similar to the existing Exif and IPTC keys. "Standard" conversion

<br>classes to convert between Exif, IPTC and XMP could then become part of<br>Exiv2.<br>If that cannot be done, then I don't see the point of adding XMP support<br>to Exiv2.</blockquote><div><br>Totally agree. <br> </div>

<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Where I see a potential to save time by using Adobe's library/exempi is<br>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.

<br><br>Another alternative is of course to use 2 libraries, one for XMP and one<br>for Exif/IPTC and develop conversion classes outside of both of them.<br>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.</blockquote><div> I'm not favorable to use this way. To have a single library used to handle metadata will be perfect for me. It's more simple to maintain and more homogenous.

<br> </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Would it help in the short term if Exiv2::Image provided some kind of<br>getXmp/setXmp methods (at least for JPEGs) which would just deal with

<br>std::string BLOBs containing the raw XML? This would allow to<br>read/write the data using Exiv2::Image::read/writeMetadata but require<br>some other means to parse the XML.</blockquote><div><br>Fix me if i'm wrong, but I think than XMP meatadata can be hosted in both way :

<br><br>With JPEG files :<br><br>- a JPEG section.<br>- an EXIf tag.<br><br>With TIFF files :<br><br>- a TIFF tag.<br>- an  Exif Tag. <br><br>With PNG :<br><br>- A text chunk as byte array (ImageMagick technic)<br>- A dedicaced PNG chunk (Adobe technic)

<br></div></div><br>Gilles<br>