[KimDaBa] Writting EXIF *to* files

[Shawn Willden]

On Thursday 29 December 2005 07:09 am, G wrote:
> Jesper K. Pedersen a écrit :
> >So where do you all want category information written? Does any other
> >application you use, read category information from a specific EXIF field?
> > or should it just be put into the description field?
>
> For your question about metadata, maybe (it's my opinion, but I'm not
> alone...) EXIF is not the best place to put informations about
> categorizing...
>
> Aren't IPTC, or better XMP, preferable ???

I had never heard of IPTC or XMP prior to this post, but I did a little bit of 
research and it seems to me that IPTC is specifically designed for exactly 
this kind of metadata.  As I understand it:

o  EXIF holds information about the technical characteristics of the image 
file.  File name, camera, shutter speed, lens and flash configuration, 
date/time, orientation, etc.

o IPTC holds information about the content of the image.  Caption, keywords, 
categories, etc.  IPTC can also hold lots of what's stored in EXIF.

o XMP holds everything, including all the stuff no one has thought of yet.

IMO, it makes a great deal of sense for Kimdaba to use IPTC for storing 
category, keyword, etc. metadata.  Not only is IPTC designed to manage 
exactly the sort of data that KimDaBa would like to store, the library 
KimDaBa uses to manage EXIF data already supports IPTC.

XMP, on the other hand, looks very powerful, but it also looks like a great 
deal of work.  Perhaps it wouldn't be too bad to only support a small subset 
of XMP -- maybe some of the Dublin Core schema, some of the Photoshop Schema, 
the Camera Raw schema and the EXIF schema.  It might even make sense to add a 
custom schema that allows all Kimdaba-managed metadata to be stored in the 
image.

XMP seems like a large, long-term project, though.  IPTC looks to be 
accessible and well-suited to the immediate goals, and a better idea than 
trying to find some EXIF tag that can be abused to hold category data.

Just my two cents,

        Shawn.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kphotoalbum/attachments/20051229/3927fbd5/attachment.sig>