GNOME Bugzilla – Bug 136286
Store comment within the image file (EXIF, IPTC, ...)
Last modified: 2015-09-18 21:34:11 UTC
Several image filetypes support having embedded comments (e.g. PNM (PGM/PPM etc.), PNG (I think), and possibly JPEG (you could probably use an EXIF tag if nothing else)). Would it be possible to store comments inside the image file whenever possible, so that the comments move with the file? I don't want to lose all my image comments because I rename or move a file, so right now I don't comment anything in gThumb! Great program though -- thanks!
This could be a VERY usefull feature. I dislike the comment system of gthumb (but I like gthumb). Use the comment system of the exif tags or of the other images format could be better. Or we can integrate them (possibility to change the comment into the images and/or display of the embedded comment). please!! :)
I have a patch for this. Currently stores the comment in the COMMENT section of JPEG files - works on all JPEGs, not just EXIF. However, doesn't work on other formats at the moment. Can't go in yet due to string freeze. I haven't attached it here since it may get tweaked/need re-diffing.
Great stuff. It might be good to abstract this out into a library, so that a generic interface can be provided to add/modify comments to/in arbitrary image filetypes. This could be useful to other projects too, e.g. the GIMP. In fact, I think the GIMP already has code to read/write comments in several image formats, but I don't think there's a consistent interface to this functionality.
Using Exif to store the comment could be a nice feature but that should remain optional. Remember the 'history' features in MS-Word files :-) Another way to insure that comments are not lost when images are moved is to store the image checksum (md5sum) in the comment.
I strongly support this enhancement. See also bug #123533 about making comment locations configurable. If comments are embedded, when possible, then external comments (and complexity about configuration/backup/etc. and bug 123533) go away.
A bunch of programs use the ImageDescription EXIF field to store the image description (several photo applications, and the Gallery web album at least). Might make sense to store it in that field instead of Comment?
I would just like to add my vote for this enhancement. I would be much happier commenting my 10,000 photos if I knew the comments were being stored in the image files themselves. :) Thanks for a great piece of software. Matt
The de facto standard at the moment seems to be that comments should be stored in the "Caption" field of IPTC metadata (not EXIF, since that is meant for technical details rather than intellectual content). This is the strategy currently used by Photoshop, Photoshop Elements, Google's Picasa, and is starting to catch on for web album software. See here: http://searchenginewatch.com/searchday/article.php/3460061 One of the advantages over EXIF or the jpeg comment field is that IPTC provides additional useful fields such as Copyright, Headline, Keywords, Photographer, Location, etc. that are good for describing the content of images. I am currently writing a simple C-library for IPTC metadata, structured nearly the same as libexif with a similar API. This will hopefully be released in the next few days. I'll post a comment here when it's available.
I've been pleased to discover gThumb with my freshly install Fedora Core 3 - the ability to attach comments to the actual image file would be an excellent enhancement.
As promised, I've completed my first public release of a C library for manipulating IPTC metadata, available at http://libiptcdata.sourceforge.net This should make adding support to gthumb easier. I may take a stab at some patches myself.
This looks like really nice work, David. It's great you've gone to a lot of effort to document the API too. You may want to notify the Gallery guys as well that this is available (http://gallery.sf.net/). Then the only thing missing to have the perfect image annotation, management and sharing system is a way to push images from gThumb to a PHP gallery :-) (I think someone suggested this in another Bugzilla entry.)
gallery is written in PHP, so they wouldn't really benefit from a C library for IPTC data. However, PHP does have native support for IPTC, so adding such a feature into gallery is quite easy. In fact, judging from some comments on their message boards, it looks like IPTC support is in the works.
Created attachment 38510 [details] [review] Patch to store comments inside image metadata Okay, I've finished my patch to gthumb. This patch does two things: 1) For jpeg files, image comments (including place and date) and categories are now stored inside the file using IPTC metadata. Other filetypes still use the existing external comment format. For any jpegs that already have an external comment, that comment is moved inside the image the next time the comment is modified and saved. 2) Anytime you modify or save a copy of a jpeg after modifying it with the image editing tools, the IPTC metadata of the old file is imported into the new file. This is the same behavior that currently occurs with EXIF data. To use the patch: 1. Apply it to a fresh checkout of gthumb from CVS. 2. Install libiptcdata (from http://libiptcdata.sourceforge.net/) 3. run this: 'export PKG_CONFIG_PATH="/usr/local/lib/pkgconfig"' so that the gthumb configure scripts can find libiptcdata. 4. run gthumb's ./autogen.sh. Make sure you see the line "Have libiptcdata: yes" near the end of the output. If not, gthumb cannot find your libiptcdata for some reason. If you don't get it to work, gthumb will still compile and run, but IPTC support will be silently disabled and gthumb will revert to the old behavior. 5. make and make install 6. run gthumb I would be grateful to anyone who can test this patch for me. Once we're satisfied that it's working, hopefully it will be applied to the gthumb source. Since this is experimental code, I suggest you first test the patch on a backup of your image files until you've satisfied yourself that it won't corrupt your images. By the way, libiptcdata comes with a command-line utility called 'iptc' that will let you view IPTC metadata inside an image. So a good way to verify this patch is working is to add some comments to images and then run 'iptc image.jpg' to verify that the comment is actually stored inside. Another useful test to do is to add some image captions using Google's Picasa or Adobe products and then verify that the comment shows up in gthumb next time you run it.
*** Bug 300828 has been marked as a duplicate of this bug. ***
Updating summary to make this bug easier to find. Has patch, setting Prio High.
fixed in current CVS.
I suppose gThumb should save IPTC character set tag too.
I have not seen any other IPTC-enabled applications that handle non-ascii character sets. Thus, adding such support to libiptcdata and gthumb will not provide any additional compatability. However, please let me know if you find another application that "does it right". If so, I can attempt to be compatable with it.
Then gThumb as GNOME application should be a pioneer in IPTC internationalization and standards compliance... It shouldn't be too difficult since there is already the IPTC_TAG_CHARACTER_SET defined in libiptcdata.
I agree, we should not wait for someone to come up with an implementation that we need to copy (even if we think it's wrong), but start using it correctly (as in "save it as UTF-8 encoded string and also expose this in the character-set field").
Yes, it is being done exactly as you suggest at the moment. It is always saved as UTF-8 and marked as such in the character set field. However, when reading, if the character set field indicates something other than UTF-8, we just assume the text is UTF-8 (since ISO 2022 is far too complicated to parse).
*** Bug 138189 has been marked as a duplicate of this bug. ***
This seems to have regressed some time in between 2006 and now. I tried applying David Moore's patch, but it only says: $ patch -Np1 --dry-run < ../gthumb.patch can't find file to patch at input line 3 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |--- configure.in 16 Feb 2005 17:32:18 -0000 1.85 |+++ configure.in 10 Mar 2005 14:35:36 -0000 -------------------------- File to patch: This is even after autogen.sh has been run - for some reason gthumb doesn't seem to have a "configure.in" file anymore. Is there any chance to get this feature back or are we stuck with gwenview?
(In reply to rainer.defender from comment #23) > ... > > Is there any chance to get this feature back or are we stuck with gwenview? It's almost 10 years that this feature is present without needing any patch, maybe you need to activate it in the preferences dialog.
And how do you do that when there's no preferences dialog there anymore because it has been rationalized away in the move to Gtk3?
It is avaiable from the application menu.
Sorry, I don't mean any disrespect, but there's no "Preferences" (or similar) option for me in what I take to be the application menu (the one with the gear symbol)? Take a look: http://snag.gy/Syx4c.jpg
If you use Gnome 3 the application menu is on the black top bar where the application icon is, otherwise it is the leftmost button on the headerbar (a button with the gthumb icon).
Hmm, seems this conversation should be in a different report then. I'm under Cinnamon, and there doesn't seem to be anything resembling what you describe (at least none of the 9 buttons in the headerbar has anything that looks like a gthumb icon). Screenshot of the full window this time: http://snag.gy/z3uPP.jpg
It should work with gthumb 3.4.0 and gtk+ 3.12 or greater, what version are you using?
I'm on LMDE (basically Debian Jessie) running libgtk-3-0=3.16.6-1 and gthumb=3:3.3.1-2+b2. Since you asked for the versions of things I went and just replaced the system-gthumb with current Git, and voila, there's the application menu now, preferences and all! Lo and behold, finally the metadata is being saved correctly as well after hitting that option. Feeling a little stupid now - thank you for the help!