GNOME Bugzilla – Bug 61499
easy way to view/edit image metadata (author, copyright, image title, etc.)
Last modified: 2018-05-24 10:34:11 UTC
There should be an easy way for the user to view and edit some properties of the current image, such as the image comment, the resolution and other invisible information that the Gimp can store in parasites. Currently, the only way to view or edit these properties is to use the Perl Parasite Editor, but this solution cannot be used by most users because: - It requires Perl, so this will not work for Windows users or for those who do not have perl installed on their system. - It is a hackers tool, not a user-friendly interface. - It cannot provide any help about the meaning of the different parasites or the names of some "standard" parasites that could be added to an image that does not have them already. - It cannot perform some useful functions such as replacing the current image comment by the default one (defined in the preferences). As I suggested in the sixth comment in bug #51164, it would be nice to have a menu entry to edit the invisible properties of the image. This could go in "<Image>->File->Properties". For more information, see bug #51164 and bug #56443.
*** Bug 65181 has been marked as a duplicate of this bug. ***
See also bug #94416, which suggests to add the ability to view and edit the XMP/IPTC metadata besides the EXIF metadata. This "user-friendly parasite editor" should probably be a separate plug-in, because it could depend on some XML or RDF parser that should not be included in the core of the GIMP.
A little note inspired by the discussion in bug #98485: this dialog will be used mainly for editing the image comment (although it should probably be replaced by a more specific field if EXIF or XMP is used or if the target format supports more specific fields as mentioned in bug #105731). It would be nice if there was an easy way for the user to replace the current comment by whatever is currently defined as the default image comment in the preferences. This could be done with a button "Use default comment" or something similar. This would be useful if the user changes the default comment in the preferences and wants to apply this change to the images that are currently open.
Changes at the request of Dave Neary on the developer mailing list. I am changing many of the bugzilla reports that have not specified a target milestone to Future milestone. Hope that is acceptable.
I'd propose a intermediate solution for pre-2.0: Let the user at least edit the image comment.
Bumping a bunch of enhancement requests which will not be done by the feature freeze to Future. Dave.
I understand Raphaels reluctance to require an XML parser for the GIMP. Certainly it would be a good idea to keep the core nice and modular but it seems likely that the next generation file format would use XML and features like ImageMap and potentially Web Preview would benefit from having a proper XML parser. Paint Shop Pro 8 ships the Apache Xerces XML parser. Adobe Photoshop must ship an XML parser of some kind for XMP. Rather than supporting Metadata only for the file types that already support it, it would be worth looking at something like Adobe XMP (or even just following thier standard) and for any files that dont internally support the metadata, write it out to an accompanying metadata file. By not restricting the GIMP to file format specific metadata you could allow users to much more easily add thier own metadata as name value pairs. A link to Adobe XMP in case anyone is interested. http://www.adobe.com/products/xmp/ XMP is a metadata specificatoins that incorporates and builds upon various W3C specifications including Dublin Core, but it is much more than that.
My concern expressed above was about linking an XML parser directly in the core because it adds a "hard" dependency for the executable and it would increase its size and runtime requirements. Developing the metadata editor as a plug-in would probably be easier because it could attract some new developers that are not familiar with the core (I know, this is wishful thinking). This plug-in would of course be part of the standard distribution and it would be linked with Xerces or some other XML parser. Some other plug-ins such as ImageMap could also be linked with the same parser if it is useful for them. If the parser is not available on some system when building a new GIMP, the plug-ins would not be built but that would not prevent the core from being built. Anyway, this was just a suggestion. Integrating the metadata editor directly into the core could also be useful and if it adds some new depenencies then we will just have to document that and live with it (the number of dependencies for the core has tripled from 1.2 to 1.3, so one more would not harm that much). Note that the XMP format uses RDF. Parsing and generating RDF correctly requires more than a simple XML parser. By the way, the link to the XMP documentation as well as additional links providing more information about this format and its origins are present in bug #94416, mentioned above.
Please note that glib-2.0 provides a resoanable markup parser than handles XML with a SAX-like API.
*** Bug 137779 has been marked as a duplicate of this bug. ***
I'd like to add: GIMP currently retrieves and stores EXIF information when saving (it seems), but that's quite transparent for the user. I also think that "image information" should have an EXIF tab. Some EXIF tags should be changable by the user (like various descriptions and comments). In addition the EXIF standard requires the image processing program to modify some tags (e.g. modification date, image rotation, etc.). This might require some callbacks in GIMP (e.g. when rotating an image). So maybe the first simple solution actually might be to allow modifying most of the EXIF tags by the user as long as GIMP can't do it automatically.
A little update on this (before I post more details on the gimp-developer list): I re-started the implementation of a metadata plug-in that registers itself as <Image>->File->Properties. It is based on the XMP model, which also includes EXIF information. It offers several tabs for easy viewing or editing of some of the most common fields (e.g. the first tab includes author, description, etc.). The last tab (labeled "Advanced") contains a treeview widget with all XMP tags grouped by XMP schema (Dublin Core, XMP Basic, EXIF, XMP Rights Management, etc.). The tags that are marked as External in the XMP specs are editable, the others aren't (with a few exceptions for things that the GIMP cannot set automatically yet).
This is duplicating the work that Bill has done already, isn't it?
Setting milestone to 2.4 since IMO we really need the metadata editor for the next release.
Hmmm... Yeah, it's about time that I do some more cvs commits. For those who are reading this bug report for the first time, the work has started in CVS, in .../plug-ins/metadata/, although some parts of that code will probably be moved into a metadata library(-ies?) as they are likely to be used by several plug-ins.
*** Bug 321036 has been marked as a duplicate of this bug. ***
Raising priority to Urgent because it is absolutely necessary to figure out what to do about this for 2.4.
*** Bug 94416 has been marked as a duplicate of this bug. ***
rasing severity to blocker because it is essential to deal with this for 2.4.
Replacing "parasite" by "metadata" in the title in order to make this bug easier to find by those who are not familiar with GIMP internals and with the way we name our data structures.
Please use Milestone + Priority==Urgent instead of Severity==Blocker.
The "gimp-comment" parasite is now shown in the Image Properties dialog, similar to what we used to have in 2.2 in the Info dialog.
So do we have to conclude that this is not going to be ready for GIMP 2.4? The bug report should then be moved to the 2.6 milestone.
OK, milestone switched to 2.6 (assuming that 2.4 will be out Real Soon Now).
*** Bug 374858 has been marked as a duplicate of this bug. ***
I've just found this bug, and I would like to add these thoughts: - File -> Properties is not a good place to put the menu item. A better place would be Image -> Properties. Of course, the Info Window is also good. - Editing image metadata is really needed in gimp. Since this won't be done for 2.4 series, maybe only comment editing could be done before 2.4 is out? - Currently, JPG and GIF images allows us to edit and save a comment with the image. PNG allows us to save the comment, but does not allow us to edit it. Maybe this little thing can be fixed before 2.4 is out?
It is now possible to edit the image comment in the Image Properties dialog. I wonder if we now still need the comment editors in the JPEG and GIF plug-ins. A simple checkbox as used in the PNG plug-in would simplify the dialogs.
Doesn't seem like we get a meta data editor for 2.6. Bumping milestone to 2.8.
*** Bug 619554 has been marked as a duplicate of this bug. ***
*** Bug 633498 has been marked as a duplicate of this bug. ***
*** Bug 640903 has been marked as a duplicate of this bug. ***
It doesn't make sense to aim for including this in 2.8, we're late in the project and this feature is not complete yet. Removing from milestone. We will merge this feature to the main branch when it is complete and without known bugs.
Hallo Martin. Are you sure this doesn't sense? As a professional photographer I use Gimp on a daily basis, and it gives me everything I need, even in 2.6. Except for the iptc/exif info. I have to switch to an old photoshop/bridge copy only to add this information before I can send my images to clients. This is so basic, really. I can do without fancy ways of changing brushes or grouping of layers, but I can't do without the iptc/exif! And I speak for al lot of photographers out there.
Maybe you can help to find someone who wants to finish the feature? http://git.gnome.org/browse/gimp/tree/plug-ins/metadata is the current code for metadata support (using a XMP model), and some file format plug-ins will have to be extended to read and write metadata from the actual file formats.
As the author of duplicate bug report 619554, I have seen my usage of GIMP drop more than 95% since I began using IPTC fields for automated WordPress captioning of .jpg's. Simply retaining existing IPTC/EXIF info, rather than deleting it all as GIMP does now, would be a wonderful first step.
Totally agree with Jon. That would be a great first step. I use Ubuntu Linux and I can add iptc tags with phatch or rawtherapee. But with every single little thing I change to an image, GIMP deletes all the meta information :(... Please please add the suggestion of Jon to the next version.
I am sorry, but we don't have an infinite number of developers and we have to prioritize our work. There are currently more important things to work on than this. At the end of the day, it is better to make a release with 2 out of 5 features 100% complete than to not being able to make a release because 5 features are each 90% complete.
In order to retain the Exif/IPTC/... metadata, the corresponding file plug-ins will have to be extended to read and write the metadata from and to the image file formats. So, jon and kneops, maybe you can help to find someone who wants to do this task?
(In reply to comment #38) > So, jon and kneops, maybe you can help to find someone who wants to do this > task? Just an idea... Maybe this new feature could become a Google Summer of Code. Not sure if it will be in time for the next release, though.
@Denilson That would be nice :) I'm not a coder and I'm just an end user. But aren't we all? At least 99,999 % of us. I love Open Source and as a photographer and designer I'm using Ubuntu Linux for all my graphic tasks and everything else. Except for the iptc... I have no idea how these things work, but could someone like the developer of Phatch (Ubuntu) be asked to have a look at that feature?
(In reply to comment #38) > So, jon and kneops, maybe you can help to find someone who wants to do this > task? I am a retired Computing guy who just celebrated his 40th anniversary of Programming. However, over all those years, I've never written anything in C. Though I have written a fair bit of php for WordPress, including code that extracts a number of IPTC fields from .jpg's. So, I can't see me being much help. And I have more experience than any of my friends.
Hey, this is bugging me too. I'm looking at feasibility of completing this feature, with a focus on at least doing no harm (not erasing the IPTC tags). What's the deadline for inclusion into 2.8?
Contact romanofski on IRC, he is already working on this. A 2.8 release is long overdue and we're not including any more features in 2.8. Adding features at this point will postpone the release, and we badly need to make one.
(In reply to comment #37) > I am sorry, but we don't have an infinite number of developers and we have to > prioritize our work. There are currently more important things to work on than > this. At the end of the day, it is better to make a release with 2 out of 5 > features 100% complete than to not being able to make a release because 5 > features are each 90% complete. Good to hear that someone is working on at least retaining the meta information already present in an image, but I disagree on that there would be more important things to work on that this, as stated in this comment. I don't want to sound too critical (I love the GIMP), but for a professional photographer this is perhaps the most important thing in the end! For archiving images, for sending the images to all kinds of media agencies, to somehow include all the necessary copyright and contact information etc. If I have an image I want to send to a news agency I don't want to write a long message with it, all the info is already preasent inside the image.
@kneops: i submitted a patch for preserving IPTC data in JPEG images. see https://bugzilla.gnome.org/show_bug.cgi?id=629044
This completely fixes the "viewing" part, editing of IPTC tags is currently disabled tho. commit 21bed1e2fb438fa5721bddb0573a724ae0024455 Author: Hartmut Kuhse <onkelhatti@gimp.org> Date: Sat Oct 19 18:38:01 2013 +0200 Completely rewrite metadata handling using gexiv2 Based on original patches from Hartmut Kuhse and modified by Michael Natterer. Changes include: - remove libexif dependency and add a hard dependency on gexiv2 - typedef GExiv2Metadata to GimpMetadata to avoid having to include gexiv2 globally - add basic GimpMetadata handling functions to libgimpbase - add image and image file specific metadata functions to libgimp, including the exif orientation image rotate dialog - port plug-ins to use the new APIs - port file-tiff-save's UI to GtkBuilder - add new plug-in "metadata" to view the image's metadata - keep metadata around as GimpImage member in the core - update the image's metadata on image size, resolution and precision changes - obsolete the old metadata parasites - migrate the old parasites to new GimpMetadata object on XCF load
Created attachment 263030 [details] Sample image with Darwin Core XMP metadata Viewing a sample DwC (Darwin Core) image in the Gimp. The DwC XMP metadata is not visible. Some image viewers, such as eog & gthumb can view this metadata. Exiftool can read, edit and write DwC tags. Notes: Darwin Core (DwC) is a XMP metadata standard used for sharing biodiversity information. http://rs.tdwg.org/dwc/
Please file this as a separate bug, this is the general metadata support bug.
Adding the "newcomers" keywords. Now that the core feature is there, adding the "editing" part should be not too hard.
*** Bug 771030 has been marked as a duplicate of this bug. ***
*** Bug 748087 has been marked as a duplicate of this bug. ***
Um, isn't this fixed now? We have a full blown XMP editor now.
There's a Metadata Editor, but it doesn't seem to have a tab for XMP data. There are tabs for Description, IPTC, IPTC Extension, Categories, GPS, and DICOM. The Metadata Viewer has an XMP tab that does show the sample image's XMP data.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gimp/issues/10.