After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 56443 - Add support for EXIF or TIFF/EP data (in JPEG, TIFF and PNG formats)
Add support for EXIF or TIFF/EP data (in JPEG, TIFF and PNG formats)
Status: RESOLVED FIXED
Product: GIMP
Classification: Other
Component: Plugins
git master
Other All
: Normal enhancement
: 2.10
Assigned To: GIMP Bugs
GIMP Bugs
: 94317 98848 111056 112435 118262 138482 323130 466376 521878 613826 644781 663683 (view as bug list)
Depends on: 118384
Blocks: 118191 118202
 
 
Reported: 2001-06-20 07:59 UTC by Raphaël Quinet
Modified: 2013-10-26 23:22 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Diff against 1.2.2 to add exif support in one big parasite. Changes needed, but it's a start. (8.08 KB, patch)
2003-01-03 10:22 UTC, Dave Neary
none Details | Review
Same patch as before with s/=3D/=/g - sorry, the patch came from the list archives. (8.00 KB, patch)
2003-01-03 10:25 UTC, Dave Neary
committed Details | Review
PNG with EXIF (277.08 KB, image/png)
2008-06-10 16:29 UTC, Pascal de Bruijn
  Details

Description Raphaël Quinet 2001-06-20 07:59:07 UTC
Most digital cameras available today save their images in EXIF format.
These appear to be normal JPEG files and they are compatible with all JPEG
applications including the Gimp, but these files contain much more
information.  Among other things, the following items are included in EXIF:
- document name
- image description, user comments
- artist name and copyright
- camera make and model, software version
- image orientation
- X and Y resolution
- date and time at which the image was taken, including time zone
- white point and lots of other color info
- GPS info (latitude, longitude, altitude, direction, speed, ...)
- exposure time
- aperture
- shutter speed
- focal length
- flash data
- sound file
- ...

More information about EXIF (including the full specification in PDF)
can be found on these pages:
  http://www.pima.net/standards/it10/PIMA15740/exif.htm
  http://it.jeita.or.jp/jhistory/document/standard/exif_eng/jeida49eng.htm

There is also a proposal for converting TIFF/EP or EXIF files to and from
PNG format, available here:
  http://pmt.sourceforge.net/exif/drafts/history/

Since several file formats support this information, it would be useful
to define standard image extensions (parasites) that can preserve this
information in the Gimp while the image is being edited.  In addition, it
would be useful to have a way to view (and maybe edit) these, from a menu
entry File->Properties or Image->Properties.  See also bug #51164.

The "Rationale" section of the proposal for converting TIFF-EP/EXIF/PNG
files is very interesting and some of the arguments can be applied to the
Gimp.  For example, the reasons for using separate chunks (PNG) instead of
embedding the whole TIFF/EP information in a single eXIF or eXIf chunk can
be applied to Gimp parasites.

Implementing this feature would require some changes in the load/save
plug-ins for the JPEG, TIFF and PNG file formats.  It would also require a
separate plug-in (or an addition to the core) in order to allow the user
to view or edit this additional image info.
Comment 1 Raphaël Quinet 2001-07-03 16:10:47 UTC
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/
  
Comment 2 Jens Müller 2002-05-26 20:20:54 UTC
It would be nice if the GIMP at least did not remove the EXIF data on
saving.
Comment 3 Raphaël Quinet 2002-05-27 07:19:52 UTC
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.
Comment 4 Raphaël Quinet 2002-10-02 16:36:26 UTC
*** Bug 94317 has been marked as a duplicate of this bug. ***
Comment 5 Akkana Peck 2002-11-07 00:51:48 UTC
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).
Comment 6 Dave Neary 2002-11-18 09:26:13 UTC
*** Bug 98848 has been marked as a duplicate of this bug. ***
Comment 7 compwiz 2002-12-01 17:38:25 UTC
Note to self: this is Debian bug #160164
Comment 8 Raphaël Quinet 2002-12-02 09:26:57 UTC
Correct link to the Debian bug:
  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=160164
Comment 9 Jakub Steiner 2002-12-08 03:02:00 UTC
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.
Comment 10 Dave Neary 2003-01-03 10:06:55 UTC
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.
Comment 11 Dave Neary 2003-01-03 10:22:24 UTC
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.
Comment 12 Dave Neary 2003-01-03 10:25:31 UTC
Created attachment 13329 [details] [review]
Same patch as before with s/=3D/=/g - sorry, the patch came from the list archives.
Comment 13 Sven Neumann 2003-02-09 11:34:37 UTC
See bug 105623 for a different approach to preserving the metadata.
Comment 14 Raphaël Quinet 2003-02-10 13:13:01 UTC
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.
Comment 15 rlrosario 2003-03-13 02:12:38 UTC
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.
Comment 16 Peter 'grin' Gervai 2003-04-03 13:24:19 UTC
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.
Comment 17 Jakub Steiner 2003-04-18 11:55:42 UTC
*** Bug 111056 has been marked as a duplicate of this bug. ***
Comment 18 Pedro Gimeno 2003-05-06 23:29:13 UTC
*** Bug 112435 has been marked as a duplicate of this bug. ***
Comment 19 Dave Neary 2003-07-26 20:45:59 UTC
*** Bug 118262 has been marked as a duplicate of this bug. ***
Comment 20 Dave Neary 2003-10-21 11:45:02 UTC
Changing milestone to 2.2 - this has been partially addressed in
current CVS.

Dave.
Comment 21 Maurits Rijk 2004-03-30 20:57:29 UTC
*** Bug 138482 has been marked as a duplicate of this bug. ***
Comment 22 Bugzilla Maintainers 2004-04-01 23:44:57 UTC
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 23 Luis Villa 2004-04-28 04:05:38 UTC
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 24 Dave Neary 2004-08-09 13:53:00 UTC
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.
Comment 25 Sven Neumann 2004-10-25 00:32:13 UTC
Nothing in CVS as of today and this report is rather vague anyway. Moving from
the 2.2 milestone to Future.
Comment 26 weskaggs 2005-02-24 19:24:28 UTC
Just to make the report less vague, the remaining "to-do" things are adding EXIF
support for TIFF and PNG files.
Comment 27 Eric Spehr 2005-03-09 14:17:42 UTC
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"
Comment 28 Raphaël Quinet 2005-03-11 09:46:05 UTC
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...
Comment 29 Ulrich.Windl 2005-03-11 10:46:12 UTC
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).
Comment 30 Manish Singh 2005-12-03 18:16:04 UTC
*** Bug 323130 has been marked as a duplicate of this bug. ***
Comment 31 Jeffery Small 2006-02-26 19:31:06 UTC
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.
Comment 32 Dennis Gnad 2006-10-05 19:12:22 UTC
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! ;-)
Comment 33 Raphaël Quinet 2006-10-06 20:57:11 UTC
(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.
Comment 34 Sven Neumann 2007-05-08 07:43:30 UTC
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.
Comment 35 Michael Schumacher 2007-08-14 08:57:06 UTC
*** Bug 466376 has been marked as a duplicate of this bug. ***
Comment 36 Michael Schumacher 2008-03-11 22:59:17 UTC
*** Bug 521878 has been marked as a duplicate of this bug. ***
Comment 37 Martin Nordholts 2008-05-28 05:14:28 UTC
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.
Comment 38 Pascal de Bruijn 2008-06-10 16:29:30 UTC
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.
Comment 39 Bilbo 2008-07-17 03:25:35 UTC
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?
Comment 40 Ulrich.Windl 2008-07-17 06:48:41 UTC
(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.
Comment 41 Sven Neumann 2008-07-17 19:07:08 UTC
(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.
Comment 42 tat 2009-04-22 06:36:14 UTC
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.
Comment 43 Martin Nordholts 2010-01-23 09:29:03 UTC
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.
Comment 44 Sven Neumann 2010-03-24 19:31:37 UTC
*** Bug 613826 has been marked as a duplicate of this bug. ***
Comment 45 Michael Schumacher 2011-03-15 08:06:13 UTC
*** Bug 644781 has been marked as a duplicate of this bug. ***
Comment 46 Michael Schumacher 2011-11-10 20:55:04 UTC
*** Bug 663683 has been marked as a duplicate of this bug. ***
Comment 47 Michael Natterer 2013-10-26 23:22:08 UTC
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