XMP metadata and GPS support

[Mikael Lammentausta-3]

Our team needs to tag images with XMP data (freely named fields as this scheme supports that), as well as insert GPS location information into photos. I love digiKam and as we otherwise use the program to manipulate the photos, it would make sense to use to use the same program for these purposes as well.

I've noticed that on the basis of the poll on the digiKam website, XMP metadata support is a wanted feature. Also, KIPI-plugins contains a GPS-sync module. Now, the question is, what's the schedule, who's working on them, and how can we help? :)

These two are quite a big features, and I'll tell more about what I have in mind if this sparks interest. A simple XMP reader would be the first thing to do, I believe. I've done a simple Perl script with ExifTool that does read/write, and AFAIK that is the only open source tool that currently supports XMP.  Tell me if I'm wrong. For GPS, we'd need to insert the WGS84 coordinates into the XMP/EXIF tags, and I believe this would be rather simple using the Google Maps backend service and GPS-sync already does.

Our team doesn't include experienced C++ programmers, but nonetheless we will start hacking the code if someone could offer a bit hand-holding and tell us where to start. Compiling from the trunk etc is not a problem.

Cheers,
Mikael

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

Metadata support is done through Exiv2 library. XMP support should be done there and it will be available in Digikam.

----------------------------------------------------
Wrocław Non Stop - eksplozja kultury we Wrocławiu!
22 czerwca - 1 lipca 2007.
W ramach festiwalu wystąpią m.in. Iggy Pop & The Stooges!
wwW.wroclawnonstop.pl http://klik.wp.pl/?adr=http://adv.reklama.wp.pl/as/iggypop.html&sid=1194
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

2007/6/19, Mikołaj Machowski <[hidden email]>:

Metadata support is done through Exiv2 library. XMP support should be done there and it will be available in Digikam.

There is a file in Exiv2 bugzilla about this XMP support :

http://dev.robotbattle.com/bugs/view.php?id=463

To add XMP support to digiKam, Exiv2 must be improved.

I recommend you to :

1/ Contact Andreas Huggel who is Exiv2 author to review the plan of XMP support.
2/ Look links given in the Exiv2 bugzzila file like source of inspiration.
3/ Start to work to Exiv2 with me and Andreas about XMP (yes, i'm Exiv2 developper too (:=)))

Exiv2 is the low level library to acess on metatada. digiKam and kipi-plugins do not use Exiv2 directly but an high level and common interface to simplify metadata management : libkexiv2. Source code is in kdeextragear/libs. I'm the author of this ibrary with Marcel. Andreas has give tips and help to make it. So to support XMP in digiKam and kipi-plugins, this lib need to be patched of course.

digiKam need a new tab in Metadata sidebar about XMP. It a new widget to do in digiKam core. For this one, i can do it, it will be easy.

digiKam metadatahub class need to be patched too to support XMP about metadata management. Like this class have be written by Marcel, He will certainly make a patch for that (:=)))

and finally, the kipi-plugin MetadataEdit need to be improved to support XMP.

To be sync everywhere i recommend to be registered to Exiv2 and digiKam-devel and kde-imaging mailling list

I think than the most important job to do is in Exiv2. Like Exiv2 is a low level interface, in libkexiv2, we need certainly add support of XMP::XML schema used by others photo management program like from Adobe and M$. But for this point, we will talking about with Andreas.

Andreas is in this room if i remember. He CC him to be sure...

XMP support for Exiv2 and digiKam is very important for the future. This is an high priority task (:=)))

Thanks in advance for your help

Gilles

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

2007/6/19, Mikael Lammentausta <[hidden email]>:

Our team needs to tag images with XMP data (freely named fields as this scheme supports that), as well as insert GPS location information into photos. I love digiKam and as we otherwise use the program to manipulate the photos, it would make sense to use to use the same program for these purposes as well.

I've noticed that on the basis of the poll on the digiKam website, XMP metadata support is a wanted feature. Also, KIPI-plugins contains a GPS-sync module. Now, the question is, what's the schedule, who's working on them, and how can we help? :)

These two are quite a big features, and I'll tell more about what I have in mind if this sparks interest. A simple XMP reader would be the first thing to do, I believe. I've done a simple Perl script with ExifTool that does read/write, and AFAIK that is the only open source tool that currently supports XMP. 

No. digiKam & co are C++ project. We use Exiv2 to handle metadata because is a pure C++ library.

Of course Exiftools is great program, but it's Perl stuff... This is a non sence to mix C++ and PERL.

Tell me if I'm wrong. For GPS, we'd need to insert the WGS84 coordinates into the XMP/EXIF tags

digiKam and kipi-plugins already handle EXIF GPS tags. This is a standard way. Of course, we can _duplicate_ all GPS informations in XMP, but we will do it in libkexiv2 as well.

Note : i hate to see duplicate information in metadata. This can give inconsistent contents... But this is mandatory for interoperability.

 

, and I believe this would be rather simple using the Google Maps backend service and GPS-sync already does.

Our team doesn't include experienced C++ programmers, but nonetheless we will start hacking the code if someone could offer a bit hand-holding and tell us where to start. Compiling from the trunk etc is not a problem.

look my other message in this thread to guide you...

Gilles Caulier

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

Dnia 19-06-2007 o godz. 11:22 Gilles Caulier napisał(a): . 

No. digiKam & co are C++ project. We use Exiv2 to handle metadata because is a pure C++ library.

Of course Exiftools is great program, but it's Perl stuff... This is a non sence to mix C++ and PERL.

 

 

And that is why I am constantly whining about service menus in Digikam. With them more advanced users could in quick'n'dirty way added required features which for some reasons could not find its way into main Digikam.

 

With service menus Perl hacker here could query %u file for XMP data, even display that using even kdialog maybe store that in simple database. Sure that would not be very good but it would be possible.

 

m.

----------------------------------------------------
Przypomnij sobie przygody uwielbianego przez wszystkich Olbrzyma.
Shrek część 1 i 2 powraca na DVD z nową niższą ceną.
http://klik.wp.pl/?adr=http://adv.reklama.wp.pl/as/hostel2.html&sid=1197
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Mikael Lammentausta-3]

Hello all, Andreas.

We discussed about this subject on #digikam earlier today with C.Gilles and Hubert, the creator of exempi (see the link below). It seems that the Adobe XMP SDK has some problems (not trivial) that Hubert has fixed in exempi.

We all agreed that using the exempi API with Exiv2 would be preferred over the Adobe API. Unless the Exiv2 devs would like to replicate the work done on exempi to achieve full GPL library. exempi is released under the LGPL. Adobe's library is released under the BSD license.

The best solution so far seems to be to write make the Exiv2 API and the exempi API to work together. How does this sound to you?

Cheers,
Mikael

2007/6/19, Gilles Caulier < [hidden email]>:

2007/6/19, Mikołaj Machowski <[hidden email]>:

Metadata support is done through Exiv2 library. XMP support should be done there and it will be available in Digikam.

There is a file in Exiv2 bugzilla about this XMP support :

<a href="http://dev.robotbattle.com/bugs/view.php?id=463" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> http://dev.robotbattle.com/bugs/view.php?id=463

To add XMP support to digiKam, Exiv2 must be improved.

I recommend you to :

1/ Contact Andreas Huggel who is Exiv2 author to review the plan of XMP support.
2/ Look links given in the Exiv2 bugzzila file like source of inspiration.
3/ Start to work to Exiv2 with me and Andreas about XMP (yes, i'm Exiv2 developper too (:=)))

Exiv2 is the low level library to acess on metatada. digiKam and kipi-plugins do not use Exiv2 directly but an high level and common interface to simplify metadata management : libkexiv2. Source code is in kdeextragear/libs. I'm the author of this ibrary with Marcel. Andreas has give tips and help to make it. So to support XMP in digiKam and kipi-plugins, this lib need to be patched of course.

digiKam need a new tab in Metadata sidebar about XMP. It a new widget to do in digiKam core. For this one, i can do it, it will be easy.

digiKam metadatahub class need to be patched too to support XMP about metadata management. Like this class have be written by Marcel, He will certainly make a patch for that (:=)))

and finally, the kipi-plugin MetadataEdit need to be improved to support XMP.

To be sync everywhere i recommend to be registered to Exiv2 and digiKam-devel and kde-imaging mailling list

I think than the most important job to do is in Exiv2. Like Exiv2 is a low level interface, in libkexiv2, we need certainly add support of XMP::XML schema used by others photo management program like from Adobe and M$. But for this point, we will talking about with Andreas.

Andreas is in this room if i remember. He CC him to be sure...

XMP support for Exiv2 and digiKam is very important for the future. This is an high priority task (:=)))

Thanks in advance for your help

Gilles

_______________________________________________
Digikam-devel mailing list
[hidden email]
<a href="https://mail.kde.org/mailman/listinfo/digikam-devel" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> https://mail.kde.org/mailman/listinfo/digikam-devel

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

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
Exiv2.
If that cannot be done, then I don't see the point of adding XMP support
to Exiv2.
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.

-ahu.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

2007/6/20, Andreas Huggel <[hidden email]>:

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
Exiv2.
If that cannot be done, then I don't see the point of adding XMP support
to Exiv2.

Totally agree.
 

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.

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.
 

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.

Fix me if i'm wrong, but I think than XMP meatadata can be hosted in both way :

With JPEG files :

- a JPEG section.
- an EXIf tag.

With TIFF files :

- a TIFF tag.
- an  Exif Tag.

With PNG :

- A text chunk as byte array (ImageMagick technic)
- A dedicaced PNG chunk (Adobe technic)

Gilles

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

On Wednesday 20 June 2007 10:50, Andreas Huggel wrote:
> 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.

FWIW, I've added Exiv2::Image::xmpPacket() which can be used to dump the
XMP packet of JPEG images (APP1 XMP segment) and TIFF or related RAW
images (IFD0 tag 700) as per the XMP specs. Read-only access for a
start and no parsing of the XML yet.

    http://dev.robotbattle.com/cmtinfo_svn.php?r=10

Note that this is in branches/unstable only for now.

BTW, the XMP specs (p93) highlight that XMP in JPEGs suffers the same
problem as Exif:
"IMPORTANT: Following the normal rules for JPEG sections, the header
plus the following data can be at most 65535 bytes long. The XMP Packet
cannot be split across the multiple APP1 sections, so the size of the
XMP Packet can be at most 65502 bytes."
And that's plain (UTF8) XML code, not even compressed.

-ahu.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

2007/6/20, Andreas Huggel <[hidden email]>:

On Wednesday 20 June 2007 10:50, Andreas Huggel wrote:
> 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.

FWIW, I've added Exiv2::Image::xmpPacket() which can be used to dump the
XMP packet of JPEG images (APP1 XMP segment) and TIFF or related RAW
images (IFD0 tag 700) as per the XMP specs. Read-only access for a
start and no parsing of the XML yet.

    http://dev.robotbattle.com/cmtinfo_svn.php?r=10

Note that this is in branches/unstable only for now.

Thanks.
 

BTW, the XMP specs (p93) highlight that XMP in JPEGs suffers the same
problem as Exif:
"IMPORTANT: Following the normal rules for JPEG sections, the header
plus the following data can be at most 65535 bytes long. The XMP Packet
cannot be split across the multiple APP1 sections, so the size of the
XMP Packet can be at most 65502 bytes."
And that's plain (UTF8) XML code, not even compressed.

If i remember, we can use an Adobe XML packet as byte array (witch is certainly compressed...). Right ?

Note than TIFF and PNG do not have size limitation.

Gilles

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

2007/6/20, Gilles Caulier <[hidden email]>:

2007/6/20, Andreas Huggel <[hidden email]>:

On Wednesday 20 June 2007 10:50, Andreas Huggel wrote:
> 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.

FWIW, I've added Exiv2::Image::xmpPacket() which can be used to dump the
XMP packet of JPEG images (APP1 XMP segment) and TIFF or related RAW
images (IFD0 tag 700) as per the XMP specs. Read-only access for a
start and no parsing of the XML yet.

    <a href="http://dev.robotbattle.com/cmtinfo_svn.php?r=10" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> http://dev.robotbattle.com/cmtinfo_svn.php?r=10

Note that this is in branches/unstable only for now.

Thanks.

Andreas,

Where we will store XMP schema from Adobe, M$ etc...?

Look ExifTool database for details : http://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/XMP.html

This is the job to Exiv2 or a high level interface as libkexiv2 ?

I this can be in Exiv2 as IPTC or EXIF schema.

Note : if i remember, Adobe SDK do not contains XMP schema.

Gilles

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

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 :
> http://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/XMP.html
>
> 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

"Xmp.exif.ApertureValue", "Xmp.iptcCore.CountryCode"
or "Xmp.photoshop.Category" etc.

Or are there more levels than namespace and tag name? i.e., can XML
namespaces be nested?

-ahu.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

2007/6/21, Andreas Huggel <[hidden email]>:

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 :
> http://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/XMP.html
>
> 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

"Xmp.exif.ApertureValue", "Xmp.iptcCore.CountryCode"
or "Xmp.photoshop.Category" etc.

Yes, this is what i thinking too.
 

Or are there more levels than namespace and tag name? i.e., can XML
namespaces be nested?

I don't know.

Yes, XML can nested tags of course, but i'm not sure if it's already used...

Gilles

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel