[Digikam-users] IPTC handling and limits
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