<br><br><div><span class="gmail_quote">2007/6/20, Andreas Huggel <<a href="mailto:email@example.com">firstname.lastname@example.org</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<br>infrastructure where possible. In particular, the interface to access<br>XMP metadata in files should remain Exiv2::Image so that a call to<br>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<br>decode the relevant bits (the "keys" and the "values") and the other<br>way around on write. And maybe they have code to access file types<br>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
<br>its respective metadata, i.e., scans the file twice, and that the<br>application maintains the conversion code.</blockquote><div><br>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)