GNOME Bugzilla – Bug 428037
GIMP is not able to read EXIF format used by Windows Photo Gallery
Last modified: 2008-01-15 14:11:28 UTC
Steps to reproduce: 1. Save any .jpg with EXIF information in MS Vista Windows Photo Gallery 2. Than try to open it in GIMP 3. The jpeg.exe plug-in will crash during opening the file, unable to handle with EXIF Stack trace: After I've resaved EXIF(for example after rotation) information included within .jpg file with Windows Photo Gallery (integrated in my new Windows Vista), I was not able to open the file in GIMP. I've tried different versions of libexif and GIMP (from 2.2.6 to 2.3.14) and nothing helps. Other information:
Another incarnation of the closed #300186 and similar bugs, I assume. Could you attach an example?
Created attachment 86111 [details] Troubled picture
Upward is an exaple. This photo was edited and saved in Windows Photo Gallery. Original version from my old Olympus camera works fine. This caused jpeg.exe plug-in crash. Actually tested in GIMP 2.3.14 on my Windows Vista Home Premium 64-bit.
I also have this problem with photos from my Olympus 770 SW, reproduced in GIMP 2.3.14 running on Windows. Cheers.
BTW, I mean photos taken directly from the camera, not photos from the camera edited with Windows Photo Gallery. ie: original photos from the camera do not work fine for me.
I get the following warnings on the console before the JPEG plug-in crashes (after allocating more than a GB of memory): ** (metadata:32180): WARNING **: While parsing XMP metadata: Error on line 2 char 42: Expected element <x:xmpmeta>, found <xmp:xmpmeta> instead ** (jpeg:32179): WARNING **: JPEG - unable to decode XMP metadata packet
The XMP packet is skipped so there is nothing wrong with that (although the parser could be a bit more tolerant). The crash seems to occur later, when trying to use the EXIF data: Program received signal SIGSEGV, Segmentation fault. 0xb775dc4a in exif_set_sshort () from /usr/lib/libexif.so.12 (gdb) bt
+ Trace 127149
Unfortunately, I do not have a debug version of libexif installed. But this could be another duplicate of the various crashes related to libexif. I'm still trying to analyze this a bit deeper, although I'm not sure that I will be able to find much without debugging libexif itself.
Note that this is happening with libexif 0.6.13, so this is not a duplicate of bug #300186 (which is related to the old version 0.6.12).
*** This bug has been marked as a duplicate of 381182 ***
For the record, my recent commit to xmp-parse.c (SVN rev 22242) gets rid of the warning while parsing the XMP block and allows it to be parsed correctly despite the fact that "Windows Photo Gallery 6.0" does not follow the recommendations in the XMP specification. So what remains is the bug in libexif, which is covered in bug #358117 (as well as similar bug reports for other applications depending on libexif).
As on many places in EXIF-related entries in this bugzilla, here are again combined several actually unrelated problems. 1) Original report, Comment #2 : Looks like this Windows Photo Gallery tool reads Olympus EXIF JPEG Intel-order IFD with Intel makernote, but saves back Motorola IFD with Intel makernote. This can be a simple consequence of the fact that Photo Gallery doesn't know how to handle the makernote and thus copies it back unmodified, while it swaps endienness of the rest of Exif data. Anyway, just yesterday I checked in a heuristical fix to libEXIF CVS repository that detects this problem on read. Because libEXIF keeps endianness and I haven't seen any Olympus makernote with Motorola endianness, libEXIF keeps Motorola-order for the main IFD and Intel-order for the makernote when resaving this document. 2) Comment #4 : Apparently Olympus S760 and S770 started to use a new variant of Olympus makernote. I checked in enhancement to the libEXIF CVS repository just yesterday. 3) Comment #1 : Bug #300186 is 2 years old, it is about something different... I am not able to reproduced it now, it must have been fixed. -- Jan Patera, libexif developer