GNOME Bugzilla – Bug 95928
TGA plug-in does not save or load image comments
Last modified: 2004-08-15 16:19:51 UTC
The TGA format support several metadata fields that are currently ignored by the GIMP. Among others: author name, image comment, date and time, software used, etc. Although most of these fields cannot be used by the current version of the GIMP until there is a way to edit the metadata as described in bug #61499, the image comment could and should be used. For the moment, the image comment is silently dropped.
Re: the recent change in "severity": I had marked this as "minor bug" instead of "enhancement", because the image comment is something that the GIMP supports, but it is silently dropped by the current versions of the TGA plug-in. This is not what the users would expect. So I consider the "comment" part to be a bug, even if the other metadata fields fall into the "enhancement" category. But OK, I will leave this as "enhancement" for now...
Just as with JPEG/EXIF, gimp should strive to handle metadata correctly.
Since noone seems to be willing to put any work into this, I am moving it to the 2.2 milestone.
Created attachment 26980 [details] [review] patch to plug-ins/common/tga.c This patch (against current CVS, but I think the file is unchanged since 2.0.1) causes the image description to be attached to the image as a gimp-comment parasite on file-open, and any gimp-comment to be written as image description on file-save. This is the same behavior used by some other file format plug-ins. The patch also addresses bug #65534. The patched tga.c was tested in 2.0.1.
The patch doesn't follow the GIMP coding style. Did you check character encoding issues? What does the TGA spec say about the encoding of the strings?
Created attachment 27018 [details] [review] revised patch Revised patch adds spaces between if and (, and between function name and (, where they were accidentally omitted. Also removes unintentional reversion of a change that Pedro made. The Targa file spec contains absolutely no restrictions or recommendations for the contents of the image identification field, except that the length shall not exceed 255 bytes. It would of course be easy to utf8_validate the contents of gimp-comment before using them, but it is not obvious to me that this is necessary or desirable.
If the spec really doesn't specify the character encoding then we can't read nor write this info simply because we don't know what to read or write. I vote for closing this bug as WONTFIX then.
Also, if you wanted to treat the string as UTF-8 encoded, you can't simply cut it off at index 255, that might be just in the middle of a character. But either we restrict the comment to 7bit ASCII or we close this bug as WONTFIX.
Well, the image description is likely to contain useful information if it exists, so it is undesirable to simply ignore it -- that's what this bug report is about. The Targa spec, as I mentioned, does not restrict the contents. The parasites.txt file specifies that gimp-comment should be in UTF-8. How about the following approach: (1) If an image description exists and is utf-8 valid, use it, otherwise ignore it; (2) when writing the gimp-comment, trim to the longest valid utf-8 string shorter than or equal to 255 bytes? My only reservation about 7 bit ASCII is that it seems contrary to the GIMP philosophy of being multi-lingual.
I'd say normalize to ascii always. If multilingual folks want multilingual comments, they should use a format that supports it properly.
What about this?: if the comment metadata is not valid ASCII, then attach it as a parasite other than a gimp-comment (e.g. tga/comment); if it is, attach it as a regular gimp-comment. When saving, presence of regular comment takes precedence over tga/comment. The rest of metadata is preserved. I think that at least we should attempt to preserve the metadata between saves; that's what the JPEG plug-in does with the EXIF info and I think that's good.
IMHO this is wasted effort. A file format that doesn't specify the encoding of it's strings embedded into it, isn't worth to be supported completely. The code to support this properly would be overly complex and error-prune. People that need meta information should use a proper file format. Preserving the meta information w/o attempting to change and/or display it, is of course a valid approach that is worth to be implemented.
So then it seems that something close to Pedro's suggestion will do what you are asking for -- put it in a parasite called "tga-image-description" when loading; use "gimp-comment" (first choice) or "tga-image-description" (second choice) when saving. Incidentally, the Targa format defines an "extension field" after the image data, in which everything is precisely specified, down to field length and encoding. By the time they got around to doing this, though, they could not put restrictions on the "image description" data because there were already a number of applications that had used it in idiosyncratic ways.
In my opinion this isn't worth the hassle. Raphael, do you have any use for comments in TGA files at all or did you only open this enhancement request for the fun of it?
Comment on attachment 27018 [details] [review] revised patch Based on comments, setting "needs-work" on patch. And I vote for WONT-FIX.
For the record, yes I had a use for comments in TGA files, but that was some time ago and I found a workaround in the meantime. It should also be noted that other image formats (especially the "old" ones such as GIF, PBM, etc.) do not specify any encoding for their comments and are rather vague about what a "comment" is anyway. It seems that only the newer image formats such as PNG and the ones that support EXIF or XMP metadata get this correctly (even EXIF was not correct, before revision 2.2).