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 165362 - Loading certain JPEGs blocks the loader
Loading certain JPEGs blocks the loader
Status: RESOLVED DUPLICATE of bug 164053
Product: GIMP
Classification: Other
Component: Plugins
2.2.x
Other All
: Normal normal
: ---
Assigned To: GIMP Bugs
GIMP Bugs
Depends on:
Blocks:
 
 
Reported: 2005-01-26 23:27 UTC by Oliver Knoll
Modified: 2008-01-15 12:46 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
JPEG from mobile phone which is working (62.39 KB, image/jpeg)
2005-01-26 23:31 UTC, Oliver Knoll
Details
JPEG image which blocks the JPEG loader (20.19 KB, image/jpeg)
2005-01-26 23:34 UTC, Oliver Knoll
Details
The dependency graph 1 for jpeg.exe (21.39 KB, image/gif)
2005-01-27 00:40 UTC, Oliver Knoll
Details
2nd part (end) of dependency graph (22.77 KB, image/gif)
2005-01-27 00:42 UTC, Oliver Knoll
Details

Description Oliver Knoll 2005-01-26 23:27:14 UTC
Please describe the problem:
Certain JPEG images (which come from my mobile phone, a Samsung E700, but not
that important...) can't be loaded: When I drag them from the Explorer onto Gimp
the progress bar appears, goes quickly up to 100% and then stops (it doesn't
disappear). The image never appears.

The task manager shows that the process jpeg.exe takes 100% processor power.

When I try to open the image via file open dialog the image preview can't be
generated (it constantly sais "Generating preview" ("Erzeuge Vorschau")). For
each preview being created another jpeg.exe process starts and hangs, taking as
much as CPU power as possible.

Clicking on "Open" the progress bar in the file dialog goes again quickly to
100% and then hangs.

Clicking on "Cancel" in each progress bar / dialog helps, the jpeg.exe process
is killed.

The funny thing is that it seem to depend on the image size produced by my
mobile phone: I CAN load the 640x480 images, but not the smaller ones like
320x240 or 160x120.

Off course I can load each of these JPEGs in any other application I've tried
(Windows Image Preview, XnView, PhotoShop...)

I'm not saying the JPEG data is correct - it probably contains bogus data - but
IMHO the JPEG plugin should gracefully abort (or show the images nevertheless,
with some warning if necessary :)

Steps to reproduce:
1. File - Open
2. Choose the JPEG image 
3. Watch the progress bar go to 100% and never disappear, image doesn't show up


Actual results:
Image doesn' appear, CPU power is consumed up to 100%

Expected results:
The image should be shown off course (with a warning if the JPEG data is faulty)

Does this happen every time?
Yes!

Other information:
Actually I was hoping I could upload the JPEG images, the one which is working
(640x480) and the one which doesn't (320x240). Sorry don't have a webserver
handy right now where I could upload them... :/ You can contact me via email and
I'll send them to you.
Comment 1 Oliver Knoll 2005-01-26 23:31:48 UTC
Created attachment 36575 [details]
JPEG from mobile phone which is working

This is the JPEG from my mobile which is working. The only difference to the
non-working JPEG (to be uploaded) is that I set the image size to 640x480 in my
mobile phone. The image hasn't been modified elsewhere, simply downloaded from
my mobile.
Comment 2 Oliver Knoll 2005-01-26 23:34:41 UTC
Created attachment 36576 [details]
JPEG image which blocks the JPEG loader

And this is one of the troublemakers (EVERY picture with size 320x240 from my
mobile doesn't work - and I can open them with other applications - PhotoShop 5
SE, XnView... - without warnings). It blocks the JPEG loader which consumes CPU
power at 100% (progress bar at 100% as well).
Comment 3 Oliver Knoll 2005-01-26 23:41:45 UTC
So I've found a means to do uploads :) When I click on the attachements in my
webbrowser both images show up fine. Right-clicking and saving the images still
produces the same results with Gimp 2.2.3 as described above (I remember I had
the same problems with an earlier version, like 2.2.0 or even 2.0.x, sorry can't
remember...). Both images come straight from my mobile phone camera and haven't
been changed with another image manipulation program
Comment 4 Michael Schumacher 2005-01-26 23:54:36 UTC
Both images load fine im my gimp-2-2 build - could be a libexif issue.
Comment 5 Oliver Knoll 2005-01-26 23:56:23 UTC
This is interesting: loading a JPEG image which would block in Win32 Gimp 2.2.3
with a Gimp 2.0.0 on Linux DOES work (not sure if it's because its on Linux or
because it's an older Gimp...).

Loading a JPEG which would block with PhotoShop 5 SE and storing it again as
JPEG, normal baseline encoding etc. makes it a "valid" JPEG again, that is I can
also load it with The Gimp 2.2.3 on Win32.
Comment 6 Manish Singh 2005-01-27 00:01:06 UTC
Most likely a libexif problem, given where the stall happens. Probably old
libexif's loop forever cause of something it didn't expect (the images
themselves don't have any exif data).

This doesn't happen for me with gimp 2.2.x on Linux.
Comment 7 Oliver Knoll 2005-01-27 00:07:43 UTC
Almost forgot: my Gimp 2.2.3 (and GTK lib) comes from here:
http://gimp-win.sourceforge.net/stable.html

I'm running Windows XP Home, SP 2 (and I guess the latest patches as well). 
Comment 8 Oliver Knoll 2005-01-27 00:40:39 UTC
Created attachment 36580 [details]
The dependency graph 1 for jpeg.exe

This is (part of) the dependency graph of my jpeg.exe plugin.
Comment 9 Oliver Knoll 2005-01-27 00:42:08 UTC
Created attachment 36581 [details]
2nd part (end) of dependency graph

The end of the dependency graph (the middle part showing mostly Gtk lib stuff
skipped) shows that jpeg62.dll lib is used.

Maybe that's of any help...
Comment 10 Raphaël Quinet 2005-01-27 09:26:00 UTC
This is most likely related to the old libexif shipped with the Windows version.
Jernej said that he will update it in the next release.

*** This bug has been marked as a duplicate of 164053 ***
Comment 11 Oliver Knoll 2005-04-07 21:49:19 UTC
I'd like to happily confirm that Gimp 2.2.4 for Win32 solves the issues with the
JPEGs coming from my mobile :) They're loading just fine now...

Thanks a lot! Oliver