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 167699 - Unable to preview modified camera images
Unable to preview modified camera images
Status: RESOLVED DUPLICATE of bug 164053
Product: GIMP
Classification: Other
Component: Plugins
2.2.x
Other Windows
: Normal minor
: ---
Assigned To: GIMP Bugs
GIMP Bugs
: 169930 309283 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2005-02-17 12:59 UTC by breehee7
Modified: 2008-01-15 12:48 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description breehee7 2005-02-17 12:59:48 UTC
Please describe the problem:
Browsing through a list of images, a preview of each image is generated in the
preview window. Whenever an image has been selected for preview, and the image
has been stripped of shootinginformation, the plugin crashes. See error message
below:
Plug-In crashed: "jpeg.exe"
(C:\Program Files\GIMP-2.2\lib\gimp\2.0\plug-ins\jpeg.exe)

The dying Plug-In may have messed up GIMP's internal state. You may want to save
your images and restart GIMP to be on the safe side.

Steps to reproduce:
1. Use Canon Zoombrowser 5.0, select an camera image with shooting information.
2. Save a copy of the image (removes shooting information)
3. Launch the Gimp, click on file open, click on the modifed file created above,
and the preview will crash.


Actual results:
The Gimp displays this message: Plug-In crashed: "jpeg.exe"
(C:\Program Files\GIMP-2.2\lib\gimp\2.0\plug-ins\jpeg.exe)

and suggests that I exit the Gimp.

Expected results:


Does this happen every time?
Yes. It was a more severe with the Gimp 2.0. It used to completely close the
Gimp. Now, it is being handled more gracefully...sorry that I did not report it
earlier.

Other information:
Comment 1 Raphaël Quinet 2005-02-17 13:23:20 UTC
This is probably a problem related to the EXIF information in the JPEG file.
I assume that the problem will be solved when libexif is upgraded in the next
release of the GIMP for Windows.  This is mentioned in bug #164053 and several
of its duplicates.

*** This bug has been marked as a duplicate of 164053 ***
Comment 2 Manish Singh 2005-03-11 18:59:51 UTC
Seems to be a different issue, reopening.
Comment 3 Manish Singh 2005-03-11 19:00:20 UTC
*** Bug 169930 has been marked as a duplicate of this bug. ***
Comment 4 Manish Singh 2005-03-11 19:01:52 UTC
It would help to have:

a) The original image from the camera
b) The image that crashes.

Provide a url if the images are too big to attach here.
Comment 5 breehee7 2005-03-12 00:35:09 UTC
Forgive my lack of either sophistication or resources, not sure how I can
provide a url for the images. Do not have a web server for that purpose.
Any suggestion on how to accomplish this would be welcome.
Comment 6 Manish Singh 2005-03-12 00:37:13 UTC
There are a number of free webhosting sites on the internet. One that comes to
mind is geocities.com
Comment 7 breehee7 2005-03-12 01:32:43 UTC
Just built a quick page on geocities. Already exceeded my data transfer limit.
Site will be available in 1 hour.
2 images are there (unmodified/modified). The Gimp cannot preview the modified
image.
Hope this is helpful.
Because of the bandwidth limitation it might take 2 visits to get both images.

Thanks.
Here's the url for the images.
http://www.geocities.com/puppy_bree/ photopage.html
Comment 8 Manish Singh 2005-03-12 10:57:21 UTC
What's going on is that the Canon Zoombrowser software isn't removing the EXIF
information as claimed, but instead saving a corrupt version of it. libexif
chokes on this. This is output from jhead:

Nonfatal Error : 'IMG_0128_1.JPG' Suspicious offset of first IFD value
Nonfatal Error : 'IMG_0128_1.JPG' Maximum directory nesting exceeded (corrupt
exif header)
Nonfatal Error : 'IMG_0128_1.JPG' Illegally sized directory

.... and the original EXIF information from IMG_0128.JPG follows.

Now, libexif should handle bogus exif data gracefully, and indeed the CVS
version does, and Debian's version has patches to workaround this as well.

So I'm going to reopen bug #164053, and remark this as a duplicate.

*** This bug has been marked as a duplicate of 164053 ***
Comment 9 Manish Singh 2005-03-12 11:00:20 UTC
Also, the bug reporter should file a bug with Canon to fix their broken software.
Comment 10 Sven Neumann 2005-07-01 17:54:42 UTC
*** Bug 309283 has been marked as a duplicate of this bug. ***