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 677759 - certain jpg images cannot be opened
certain jpg images cannot be opened
Status: RESOLVED NOTGNOME
Product: GIMP
Classification: Other
Component: General
2.8.0
Other Mac OS
: Normal normal
: ---
Assigned To: GIMP Bugs
GIMP Bugs
Depends on:
Blocks:
 
 
Reported: 2012-06-09 15:09 UTC by Abel
Modified: 2012-06-09 21:17 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Abel 2012-06-09 15:09:11 UTC
Using Gimp 2.8.0 on OS X, opening photographs taken with my mobile phone (Nokia N9) doesn't work properly.

On the build I got at gimp.lisanet.de, Gimp will start two instances of ufraw-gimp, taking all available processor power. This can be worked around by changing the Select File Type option from Automatically Detected to JPEG image.

On the native OS X build I got here: http://www.gimpchat.com/viewtopic.php?f=7&t=4440&start=10#p55119, the files will also not open. The ufraw process doesn't get started and the progress bar in the Open Image window moves nicely from the left to the right, but when it gets there nothing happens and I just have to press Cancel in the Open Image window. On this build, setting the Select File Type option to JPEG image doesn't seem to make any difference.

I've seen the same problem reported on Ubuntu: http://discussions.nokia.com/t5/Maemo-and-MeeGo-Devices/Problems-opening-N9-photos-in-GIMP-format-issues-EXIF-JFIF/td-p/1292935.

Opening and resaving the offending file in some other image editing program does help; Gimp will open the resaved file without any trouble.

An example file that does not open properly can be found here: http://www.everholt.org/abel/gimp/Berkebladeren.jpg.
Comment 1 Michael Schumacher 2012-06-09 15:55:42 UTC
Multiple issues in one report - which one should we concentrate on?

Probably the one of native build, because X11 builds (like the lisanet one) are considered obsolete?
Comment 2 Mukund Sivaraman 2012-06-09 16:06:50 UTC
tigert reported such an issue in #gimp earlier this year, and I could confirm it back then.

Something is wrong inside ufraw's JPEG parser. It registers for all these extensions:

01:30:46 <@muks> as a fallback, it's written to call GIMP's JPEG loader, but it doesn't even get there
01:31:17 <@muks> const char raw_ext[] = "3fr,arw,bay,bmq,cine,cr2,crw,cs1,dc2,dcr,dng,erf,fff,"
01:31:17 <@muks>                       "hdr,ia,jpg,k25,kc2,kdc,mdc,mef,mos,mrw,nef,nrw,orf,pef,pxn,qtk,raf,"
01:31:17 <@muks>                        "raw,rdc,rw2,rwl,sr2,srf,srw,sti,tif,ufraw,x3f";
01:44:42 <@muks> ufraw embeds dcraw which does manual JPEG parsing.. and
because this is not a JFIF file but an Exif file, they probably screwed up
in the parser

The hang is inside ufraw, and GIMP's code is never called. I think you should take it up with the ufraw developers.
Comment 3 Abel 2012-06-09 16:15:47 UTC
The native build issue turns out to be quite different indeed; a dialog got hidden behind the image window and when moving the image window away the file actually opened.

This leaves the issue on the X11 build and the one on Ubuntu, but that report is from the 2.6 series. I'll try to file on Gimp 2.8 on Ubuntu and report back.
Comment 4 Michael Schumacher 2012-06-09 16:28:12 UTC
For furte bug reports: only one issue per report, please.
Comment 5 Abel 2012-06-09 21:17:24 UTC
On Ubuntu 12.04, both Gimp 2.6.12 an 2.8.0 open the file without any problems, so disregarding the X11 build the only remaining issue is the window order on the native OS X build. As that is quite a different issue from what I reported here I'll open a new report if that issue hasn't been reported yet.

@Michael: I was under the impression that everything I wrote about in the original report was related, I'm sorry about the confusion.