GNOME Bugzilla – Bug 710937
Cannot open JPG images taken with long exposure BULB setting
Last modified: 2014-02-28 22:09:29 UTC
Open as layer dialog box locks up and cannot be cancelled without closing GIMP. No progress bar activity when opening only certain JPG images created on a Canon T5i. Images that were created by using an extremely long exposure > 30 seconds (1 to 4 minute exposures) are the only ones that seem to be effected. Images taken with normal shutter speeds of 15 seconds or less open in GIMP normally. The attached image is one that GIMP doesn't open yet other programs can open it without issue. Using GIMP 2.8.6 on Win 7 Home Premium Sp 1 64Bit 2.8GHz AMD Athlon with 4GB memory
Hello, You seem to have forgotten to have attached your image. Thanks!
The attached file is a 5mb jpeg and is apparently larger than the 1.6MB limit. THe file must have been stripped from this bug report automatically. Please download from BOX.com using this link: https://app.box.com/s/3j2u9nu7hcr9fgpz1two Images taken with a Canon T5i which use the BULB shutter setting in manual mode with exposures > 30Seconds cannot be opened in GIMP unless the embedded EXIF data is first erased. Used http://www.verexif.com/en/ to delete EXIF data.
Created attachment 258387 [details] Link to JPG file uploaded to BOX.COM JPEG file is too large for Bugzilla.
Changed to Unconfirmed after uploading file to Box.com and providing link
I've tried both with master (which has had a new improved metadata support for a few days) and the gimp-2-8 branch on Linux and I could not reproduce. Your image opened completely fine both by itself or in "open as layer". My GIMP is compiled with EXIF support, so if there was a problem with metadata, I should get it. But maybe there is a problem with the specific libexif embedded in the Windows installation. I will try in my Windows VM, but not today.
Uploaded a second image to Box.com that cannot be opened by GIMP https://app.box.com/s/jlywxmsu91gbs5v0l6o8 Please try this second file to see if you can duplicate the problem.
Hi, just to say I could reproduce with IMG_4810.JPG both with GIMP 2.8.6 released and gimp-2-8 branch (not IMG_4779.JPG, it works fine even under Windows 64-bit, both 2.8.6 released binaries and gimp-2-8 dev branch). I will try later with master on Windows, since we have brand new metadata support. It may be fixed with master. Still working like a charm under Linux though, except that I get these messages in my console: --------------------------- jehan@DarkMarmot ☃ [gimp-2.8|gimp-2-8] $ app/gimp-2.8 While parsing XMP metadata: Error on line 46 char 1: End of element <exif:Flash> not expected in this context Metadata parasite seems to be corrupt --------------------------- So the metadata seems to be corrupt (or else the library has not support of some extension?). This may explain the problem (except that on Windows, it blocks, and not on Linux). The image IMG_4779.JPG displays also an error, but a different one: ---------------------------- While parsing XMP metadata: Error: No XMP packet found -----------------------------
Hi, I finally got to test our new metadata system under Windows. The good news is that now both images load fine. No error. So the specific issue is fixed with our new metadata system. IMG_4779.JPG is loaded without metadata though (encoding issue apparently). I created bug 711241 for this one. IMG_4810.JPG loads well all the metadata, though some values are a bit off. I created bug 711242 for this. The current bug is confirmed though, so I won't close it. But it pertains to the stable 2.8 branch only. It is obsoleted in the development branch (the 2 bug reports I reported are different issues, the image loads fine at least and no hold nor crash). So that's not high priority. If someone is willing to fix this in our gimp-2-8 branch though, you are welcome to provide a patch! In the meantime, Mark, I would suggest you work around the problem by fixing the metadata with another program first, just as you did, for the time being. I know this is not very cool workflow, but some members of the team completely rewrote from scratch the metadata support these last few weeks. So I am guessing that not many people will want to touch code which will only be valid until the next major release (but I may be wrong, as I said: patches welcome!). Sorry for this.
Judging from comment 7, is this perhaps bug 667038?
The error on Linux seems to be the same as for one of the images. Anyway as said, that's fixed in GIMP master with the new metadata system. This bug is now only GIMP 2.8 and earlier. So I honestly won't spend too much time on it.
OK let's resolve as duplicate then. Please reopen if I was wrong. *** This bug has been marked as a duplicate of bug 667038 ***