If anybody wants to help in implementing this (be it only to specify
a list of "standard EXIF parasites" for the Gimp), here are some
useful resources:

* GPhoto2 (http://www.gphoto.org/) contains a program called
  exifdump or gphoto-exifdump.  As the name implies, it dumps the
  EXIF information so you can see all the information contained in
  the photos that have been taken by a digital camera.
* There is also a Python script that does more or less the same thing:
  http://topo.math.u-psud.fr/~bousch/exifdump.py
* There is a nice small program called "jhead" which extracts the
  EXIF information and EXIF thumbnails from JPEG files.  Source code,
  Linux binary and Windows binary are available:
  http://www.sentex.net/~mwandel/jhead/
  

It would be nice if the GIMP at least did not remove the EXIF data on
saving.

I disagree.  If the image is modified within the GIMP and then saved
in a new file, copying the EXIF data to the new image could be worse
than removing it.  Some programs could be confused by the mismatch
between the image data and the EXIF data.

In the worst case, the user could open an image with EXIF information,
clear its contents, resize it to some new dimensions, copy a totally
different image inside the empty canvas and then save the results.  If
the old EXIF data is saved in the file, then it would have nothing in
common with the image (different size, different contents, etc.).  Of
course this is an extreme example, but there are many cases that are
less extreme and that could also cause problems.

There is no way around it: if the GIMP saves EXIF data to a file, it
must be able to understand what it saves and it must save only the
relevant parts and re-construct the parts that are new or modified.

I started to work on this a couple of months ago, after some
discussion on the gimp-developer mailing list (you can have a look at
the mailing list archives if you want to get more information and see
what was the consensus about how the GIMP should store the EXIF data
in individual GIMP parasites).  Unfortunately, I lost a large part of
this work (the list of GIMP parasites) in a disk crash a few days ago.
I am re-writing this list now and I hope that EXIF support can be
added in GIMP 1.4.

*** Bug 94317 has been marked as a duplicate of this bug. ***

I could see an argument for being optional, but I think most people
would want to preserve the EXIF.  While it's certainly possible to
edit a jpeg and replace its entire contents with something else,
that's likely to be fairly uncommon compared to the very common
operation of taking a jpeg and cropping, adjusting contrast, and
resizing.  It's disappointing to lose all the date and exposure data
just for a simple resize, and would be wonderful if gimp had code to
preserve this info.  If you need help with testing or coding of this,
please let me know (and good luck with recovering your lost work).

*** Bug 98848 has been marked as a duplicate of this bug. ***

Note to self: this is Debian bug #160164

Correct link to the Debian bug:
  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=160164

I agree keeping the EXIF info for start is a good thing. It is very
common to fix color casts, brightness etc. Losing all the EXIF info by
doing this incredibly sucks.

Someone on the mailing list recently brought this up again.

To ensure it doesn't get lost, I'm attaching Lutz Müller's patch
agaist 1.2.3 to enable EXIF data loading, editing & saving - getting
this to work against 1.3 should be trivial. In any case, it's a
baseline from which to work.

I believe that we should get at least this functionality into the gimp
for 1.4, for the case where we don't have a more flexible & generic
metadata editor in place.

Cheers,
Dave.

Created attachment 13328 [details] [review]
Diff against 1.2.2 to add exif support in one big parasite. Changes needed, but it's a start.

Created attachment 13329 [details] [review]
Same patch as before with s/=3D/=/g - sorry, the patch came from the list archives.

See bug 105623 for a different approach to preserving the metadata.

I don't think that bug #105623 would help at all.  This bug report is
not about preserving the metadata, but about how to update it in the
appropriate way (i.e., keep the relevant parts from the original file
and update the fields that must be updated according to the specs).

If this bug was simply about preserving the metadata, then we could
just copy the EXIF block from the old file to the new one, as some
people have suggested.  Unfortunately, this would violate the EXIF
specs and this would only work for JPEG/EXIF files, not for TIFF/EP
or PNG files.  Some arguments against doing a blind copy of the EXIF
block can be found on the pmt drafts page linked above.

You may want to take a look at the Picture Metadata Toolkit for
handling metadata (http://picturemetadata.sf.net). It currently
supports Exif and Tiff ( so you can transfer metadata from one to the
other ), and there are plans for adding support to more formats.

Or use:

http://sourceforge.net/projects/libexif/

Btw a "Keep EXIF data (may violate EXIF std) [ ]" switch in the JPEG
save dialog would at least offer the possibility not to lose the
metadata. I'd rather have one bad entry in EXIF (dimensions) than to
lose all the other 21.

*** Bug 111056 has been marked as a duplicate of this bug. ***

*** Bug 112435 has been marked as a duplicate of this bug. ***

*** Bug 118262 has been marked as a duplicate of this bug. ***

Changing milestone to 2.2 - this has been partially addressed in
current CVS.

Dave.

*** Bug 138482 has been marked as a duplicate of this bug. ***

The URL field has been removed from bugzilla.gnome.org. This URL was in the old URL field, and is being added as a comment so that the data is not lost. Please email bugmaster@gnome.org if you have any questions.

URL: 
http://pmt.sourceforge.net/exif/drafts/

Comment on attachment 13328 [details] [review]
Diff against 1.2.2 to add exif support in one big parasite. Changes needed, but it's a start.

Marking obsolete based on comment on other patch. Sorry for the spam.

Comment on attachment 13329 [details] [review]
Same patch as before with s/=3D/=/g - sorry, the patch came from the list archives.


This was committed ages ago. Marking as such.

Nothing in CVS as of today and this report is rather vague anyway. Moving from
the 2.2 milestone to Future.

Just to make the report less vague, the remaining "to-do" things are adding EXIF
support for TIFF and PNG files.

Just a confirmation on the TIFF stripping.  Files from a Nikon Coolscan ls-5000
get their TIFF data(exif?) removed after saving.  Gimp message "IMG006.tif:
unknown field with tag 34665 (0x8769) encountered"

Regarding comment #27: once the correct framework for metadata is in place (some
minor progress has been made in CVS), several file plug-ins will have to be
updated in order to use it.  This includes the TIFF plug-in and others such as
JPEG, PNG, GIF, etc.  The TIFF case is rather complex because several vendors
have used non-standard TIFF tags for storing metadata in various formats including
EXIF, IPTC, XMP and some proprietary formats.  These non-standard tags are the
ones that the GIMP (or libtiff) complains about when loading the files.  It will
probably take a while until all common cases are handled correctly by the GIMP,
but we will try...

Regarding comment #28 about vendor extensions: The TIFF file fomat was designed
to enable handling of private extensions (if done properly): A TIFF editor can
preserve the data associated with a unknown tag.
However some tag data actually contain references, not data themselves. Such
data will be invalid if not adjusted (in the case of EXIF, the application must
know how to copy the EXIF IFD; only copying the tag is invalid).

*** Bug 323130 has been marked as a duplicate of this bug. ***

I understand the issues regarding changes to the exif data, but I would like to see gimp preservee the exif data abd offer and editing window that would allow the user to review all exif data, modify approprriate fields and clear check boxes to have ceartin fields cleared.  I do think it is important that gimp preserve the full set of exif data when saving a file unless the user explicitly indicates otherwise.

If gimp changes the image size, brightness, rotation, etc., it could automatically reset or clear these fields as appropriate, but should otherwise preserve all of the original camera and camera setting information.

There are many camera maker extensions to the exif data that also need to be preserved.  Here is a good document that lists much of this exif field data:

http://www.hugsan.com/EXIFutils/Documentation/EXIFutils-FieldRef.pdf

I think the exif plugin is not very useful if it doesn't preserve all the data fields.

Hey it seems I know a solution, as nobody mentioned it so far, and it wasn't discussed:

There is a library called "exiv2" which supports nearly all the exif, even of most of the makernotes of the common manufacturers. It is used for example in "ufraw" and the latest "digikam" beta.

Please look into that library, it supports reading and writing. I guess that libexif which seems not to be developed anymore (or just very slowly) shouldn't be used anymore. You should by all means use something that supports all the exif, like exiv2 does. You can find more about it at http://exiv2.org

I would like to edit my photographs etc. in gimp as it offers layers, brushes, object extraction, and all the cool stuff. But at the moment, additionally to not available 16bit support, the second thing which is really a no-go for doing it good, is the exif support.

If those two things get "fixed" it will be very very very nice and more closer to photoshop than it is now! ;-)

(In reply to comment #32)
> There is a library called "exiv2" which supports nearly all the exif, even of
> most of the makernotes of the common manufacturers. It is used for example in
> "ufraw" and the latest "digikam" beta.

Yes, exiv2 looks interesting.  There are some minor problems with it:
- This is a C++ library, not a C library.
- It only deals with EXIF and (old-style) IPTC, not XMP and (new) IPTC Core
- It is licensed under the GPL while the code dealing with metadata tries to be LGPL if possible.

I don't see why the code dealing with metadata should be necessarily LGPL. If someone wanted to write a closed-source plug-in then they could simply not use the libgimpmetadata library (in case this becomes a library). I think that's fair.

*** Bug 466376 has been marked as a duplicate of this bug. ***

*** Bug 521878 has been marked as a duplicate of this bug. ***

No use having this on the 2.6 milestone since no one seems to be interested in working on it. Let's hope someone can get it done for 2.8.

Created attachment 112484 [details]
PNG with EXIF

This PNG has EXIF data embedded in it, as done by UFRaw.

Please support this in the future, as UFRaw -> PNG+EXIF is currently the only lossless way to convert raw photos, into something editable by The GIMP.

Currently, GIMP read and writes EXIF info well for JPEG. It does not work well for TIFF files. Reading a JPEG file and saving it as TIFF, only saves a little bit of the EXIF data. Reading a TIFF file and saving it as JPEG doesn't save any data. Is there a chance of fixing this?

(In reply to comment #39)
Relying on libraries is nice, but when you can write EXIF data into JPEG files, you can also write EXIF data into TIFF files! Why? EXIF Data is actually stored inside a TIFF file inside a JPEG file! So you'll have to handle the TIFF tags in any case.

(In reply to comment #39)

Guys, can you please refrain from making uneducated comments on this bug report. If you want to discuss any details, there's the gimp-developer mailing-list for doing that. This bug report is here to track progress on this feature, nothing else.

Hi, it is possible to copy the exif data from a jpg file to a png or tif file with exiftool:

exiftool -AllTagsFromFile source-file destination-file

By the way it would be great to fix this "bug" in gimp and make it natively.

With the current estimates we won't have time to do this for 2.8. In fact, I don't think we will get around doing it for 2.10 if not someone from the outside starts working on this. Putting on milestone Future.

*** Bug 613826 has been marked as a duplicate of this bug. ***

*** Bug 644781 has been marked as a duplicate of this bug. ***

*** Bug 663683 has been marked as a duplicate of this bug. ***

Fixed in master:

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