Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find.


*** This bug has been marked as a duplicate of 313579 ***

I took a look at 313579.

What do we do, if the image format does not support EXIF (or IPTC) tags?
We will still need to store the comments somewhere. Normally I think
the program should fall back to a file based storage (the .comments subdir).
But here I think we should use the extended attributes (if available) instead!!

What is the advantage of using extended attributes, instead of the .comments subdir?

- Mike

If you move, copy or delete the file you'll do the same to the extended attributes.

It's like the EXIF/IPTC tags attached to the file, but not in the image format but  as additional data to the file. As an advantage you can store any data in your own format...

It should be easy (but I do not know the whole framework).
The necessary library is available at "http://acl.bestbits.at/", but should
be available by default on any current distribution.
I think you will only need these three system calls:
  setxattr, getxattr and removexattr

Sven,

I hope to use exempi to store the metadata in XMP fields, instead of exif, iptc, or xml files. Other applications can share the metadata easily then.

- Mike

Fine. This will be future-proof and I think the correct direction.

But:

 1. This will reduce compatibility with older image programs, which
    do not support XMP yet.
    (If the meta-data framework is generic, it should be possible to
     write standard data in the other formats too.)

 2. It does not solve the problem, if a the image format does not
    support XMP at all. Where do you want to store metadata in GIF,
    PNG, TIFF or TGA files?
    (A easy solution would be to store the XMP data in an extended
     attribute :-) )

- Sven

Well, no other programs know how to use gthumb xml comment files, and no other programs would know how to use the extended attributes, so using XMP would be an increase in compatibility.

XMP can be applied to jpg, tiff, png, and gif files. (I don't know about tga).

The comment code will have to juggle and prioritize exif / iptc / xmp / xml data.  Adding extended attributes at this point would just make it even messier.

- Mike

> Well, no other programs know how to use gthumb xml comment files, and no other
> programs would know how to use the extended attributes, so using XMP would be
> an increase in compatibility.

Correct, but I was speaking of other programs that do only support EXIF and IPTC,
and not XMP.

> XMP can be applied to jpg, tiff, png, and gif files. (I don't know about tga).

How is this data stored? In the standard comment flags of each format?

> The comment code will have to juggle and prioritize exif / iptc / xmp / xml
> data.  Adding extended attributes at this point would just make it even
> messier.

XMP is stored in XML, so if you cannot store the data in the image format itself, you would just save it in the extended attribute. I think you did not need a special format for this. And the XMP format should have all (interesting) field, so you should not need the additional data in the EXIF and IPTC tags.
(Isn't the XMP in some way the successor of the IPTC format?=

> Correct, but I was speaking of other programs that do only support EXIF and
> IPTC, and not XMP.

I don't understand - what are you suggesting we do? That these programs can't read XMP, but they could use extended attributes? Or something else?

 
> How is this data stored? In the standard comment flags of each format?

I don't know the details, but it is explained here: http://www.adobe.com/devnet/xmp/pdfs/xmp_specification.pdf, page 91.


> XMP is stored in XML, so if you cannot store the data in the image format
> itself, you would just save it in the extended attribute.

No, you are supposed to store it in a "sidecar" file. (If your image is xyz.jpg, you can store the XMP data in xyz.xmp, and a good program should recognize that.) See page 36 of the above XMP standard.

I'm not an expert on XMP (so your comments are most welcome) but that is my understanding of it...


- Mike

> I don't understand - what are you suggesting we do? That these programs can't
> read XMP, but they could use extended attributes? Or something else?

Oh, sorry we mixed it up.
Other programs support only EXIF and IPTC, so do not only support XMP. This was
a general hint/advice, it has nothing to do with the extended attributes.

> No, you are supposed to store it in a "sidecar" file. (If your image is
> xyz.jpg, you can store the XMP data in xyz.xmp, and a good program should
> recognize that.) See page 36 of the above XMP standard.

Ok, I wasn't aware, that it's in the spec. The advantage still would be, that
the extended attributes are tight-knit to the real file. But as this isn't in
XMP spec and XMP support most of the formats, I think it's not really necessary to support it yet.
Maybe I should propose it as an extension to XMP?! ;-)