[Digikam-users] IPTC handling and limits

Thomas Hummel hummel at pasteur.fr
Thu Sep 13 07:00:11 BST 2007

On Wed, Sep 12, 2007 at 04:18:08PM -0400, Gilles Caulier wrote:

> IPTC metadata format is undependant of file format, excepted about where
> picture store the IPTC byte array and which size restriction is relevant.
> in IPTC you can store an unlimited list of keywords, of 64B each (nx64B)

Clear now, thanks, except you said above :

"> > yes, in theory. For JPEG, the IPTC  section is limited to 64Kb. for PNG
> > and
> > > TIFF, there is no limit."

which imply the file format has some relevance though ?

> the pach is not yet apply in source code.


> DB store all strings in UTF-8. 


> When you store tags as IPTC keywords, all
> char are converted to ascii latin1 format.
> You create all you tags using accents as well, but you must take a care than
> IPTC will not support it very well. 

ok, are you saying that IPTC is not only full ASCII (7bits) but is somehow
iso-latin1 "compliant" (I thought IPTC would support only 7bit ASCII) ?

According to what you are saying, if the "limited" support of iso-latin1 of
IPTC works for me, I have better to create tags with accents in digikam since :

  . they would be stored internally in UTF-8 (so XMP ready)
  . they would "work enough" for now (stored as iso-latin1 IPTC keywords)

> If you is patient, XMP support will be
> available for 0.10 planed for KDE4 release.

Ok. What happens then to the IPTC meta-datas one would have put into the
picture file ? I guess XMP would correspond to another file area so we will end
up in files containing both IPTC headers (with tags/keywords we assigned
"before") AND XMP headers elsewhere in the file : is that correct ? (note :
that wouldn't be a problem I guess, since we wouldn't use IPTC metadata

Thanks again for the time you take to clarify thoses issues. 

More information about the Digikam-users mailing list