GNOME Bugzilla – Bug 690089
GIMP destroys image data
Last modified: 2014-02-07 21:12:13 UTC
Let's say I have a gif and I was to report that GIMP was removing layers from images and no one cared because they were hidden. Most people at GIMP would think this was disastrous and would be pulling out the stops to correct this serious error. Those layers are just bits of information. Likewise IPTC records are just bits of information which gimp totally needlessly destroys. And this is a critical issue. Recently I copied a load of old slides from someone visiting from the US, adding lots of handwritten information. Then I realised I had copied them back to front, but thought "that's OK, I can just use gimp to transpose them". But hey presto ... all those details of who were in the slides have disappeared and it never occurred to me to check before I deleted the originals. Now lets suppose you have a relative who has died, and you want to find a picture of them. Wouldn't it be nice if you could just search for the IPTC tag with their name? But no! You can't do it because GIMP has wiped their name from the record. What gimp does is rather like removing grave stones from a cemetery. It's just records, it just happens to be information that many people do not use, but for those who use the information it is critical. And yes there is a plugin (reported to work in XP), but that is not the way to deal with something like this. By default GIMP should keep these records. It is something that has to be built into the core of the software. Gimp should extract the information and add it back when saving.
without the narative - you opened a bunch of gifs, wrote stuff on them, exported as gif's, deleted the originals and are now unhappy because you cant correct the text? GIF format does not allow for layers visible or not. It allows for frames that gimp presents as layers. Frames are either visible or not there. This sort of thing is why 2.8 has save/export distinction - most file formats are lossy. Or are you trying to report the fact that gimp somehow strips IPTC records? What file format does this impact? so much confusion... Could you please provide your issue in the following manner: What you did, why you did it, what was the expected result and what actually happened. With mphasis on exactly what you did.
What I did was search using google for any mention of IPTC on the gimp site and generally and all I could find is people annoyed that gimp destroys image information. And as it did this in the past (with the consequences I outlined) without any mention of a update to solve it, I assumed nothing had changed. However, repeating the same steps now appears to retain this information. So, the critical problem is that there is no mention on the gimp website or generally for "IPTC" except those reporting Gimp does not keep IPTC headers. Which if I know programmers, means that everyone assumes there is no problem now! (But there is ... because if users don't know it still is a critical problem)
See bug 629044, bug 620552 and bug 689906. All of them have one thing in common - they can be solved if someone would work on them. Your bug report does not provide a clear indication whether you want to work on the problem, can you clarify?
Is this bug about GIF? If yes then this bug was fixed in 2.8 because we noe clearly separate "save" from "export".
AFAIK handling of IPTC metadata worked better in GIMP 2.6. Can you please check this and report back within the next 6 weeks. Thank you in advance.
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for. Thanks!
This is still very much an open bug with 2.8.4 and as it only takes a few second for anyone to check it really is laziness for someone to close this. E.g. When I open a tif file, and export it with LNZ compression all the xmp (dublin core) is lost. And e.g. when I open a jpg, I get "x-default" in xmp-dec description when I look at file properties. And a quick check on windows file properties show that everything I have added (using exiftools) has been lost. NONE OF IT WORKS. AND IT CLEARLY HASN'T BEEN CHECKED AT ALL. If you really need a test file -- get in touch with me (afrodites@haseler.net) BUT DON'T CLOSE A BUG WHICH IS STILL VERY MUCH OPEN.
Mike, the bug was closed because you didn't react to any of the requests for additional information in comments #3 to #5, and because there are several other bugs regarding this topics already (comment #3).
I've not had any emails and there is plenty of information here: http://gimpforums.com/thread-gimp-destroys-key-information-what-alternative-to-gimp?pid=16056#pid16056 And, I even have a website which was started as a result of this bug: http://fortriu.co.uk/ (more to share info on the xmp-dc field interpretations). You will also find several forums where this problem has been discussed. In other words, you didn't do any checking what-so-ever before closing this.
Well, I did search for other bugs related to IPTC, and posted them as comment #3. So what's your opinion - I'd say that this bug is a duplicate of bug 629044 or maybe even bug 56443 (mentioned in the previous one).
No. 629044 is iptc (which most people now accept is on the verge of being defunct and irrelevant) 56443 mentions xmp twice but as the post was in 2005 it is hardly "current" - and even if it had been the same bug it would speak volumes about the way no one seems to be interested in fixing it despite the numerous complaints.
Yes, bug 56443 is old, but it is the one central bug about better metadata support, be it XMP, IPTC, Exif, ... It would be great if someone who complains at first would also offer their help in fixing one of these bugs - this happens from time to time, and frankly this is the way free software works.
What help do you want?
Basically someone who take responsibility of the metadata handling in GIMP. The meatadata plug-in itself (which will be responsible to viewing and editing the data), and support for importing and exporting the data to the image files within the respective file plug-ins. This will involve coding in C, and some understanding of the GIMP and GIMP plug-in internals.
I can already see your problem. By its very nature "meta"-data is supposed to be global. You've got a compost arrangement. Nice tidy labelled buckets for each type of image file. A nice big forked labelled "edi" ... and a nebulous dump of old garbage (un-named) where all this information is dumped. So, the key questions are "how" and "Where" is this data stored within gimp?
In a so-called parasite - a data structure that can be attacked to various items, for example an image. See http://developer.gimp.org/api/2.0/libgimpbase/libgimpbase-gimpparasite.html The metadata plug-in is supposed to make access to this transparent for other plug-ins, however - e.g. you could ask it to to retrieve the xblfrmsbl-value from Exif, and tell it to store that as the rrfblst-value of Dublin Core XMP, for example. Within a GIMP image, the metadata will probably always be XMP. The code for the metadata plug-in is in plug-ins/meatdata of the GIMP source tree, go to https://git.gnome.org/browse/gimp/tree/plug-ins/metadata to browse it online. Check out the README file there, it tells you about the current state.
Michael. Thanks for that information. Reading the README file, it seems that a lot of effort has gone into creating an editor, whereas an editor is only a "nice to have" feature whereas preserving the metadata in the image is a critical show-stopper (It makes Gimp impossible to use by many users). I would therefore suggest dividing this problem into two: 1. Preserving metadata as a critical show stopper. 2. Displaying metadata correctly as a ... It should be right but it's not a show stopper. 3. Editing metadata as ... a "nice to have feature". 4. Adding new metadata fields as a ... "nice to have sometime in the future feature". I think dividing it like this will help focus on the serious problem whereby someone could loose a lot of valuable information (often without knowing it). In order to try and get help for you from someone who has the faintest clue about metadata ... I've posted a message on the exiftool forum: http://u88.n24.queensu.ca/exiftool/forum/index.php/topic,4879.0.html
Nice, maybe someone will show up. BTW, do you know why you haven't received any of the notification mails for comments #3-5?
Comment #5 is still unanswered, would be nice to have an answer for that. Mike, did you check whether 2.6 was any better in this regard?
This is too much to read :) Is it fixed with the new metadata system in master?