GNOME Bugzilla – Bug 421175
Crash when thumbnailing Canon raw image using libopenraw
Last modified: 2008-02-28 14:57:44 UTC
gThumb 2.10.0, built with libopenraw support (libopenraw-0.0.2 used) crashes after entering a directory with this file http://www.safo.cz/foto/IMG_9410.CR2 Here is a backtrace. BTW interesting is that nautilus reports the file as 'TIFF', which is not true, either. I'll happily provide any feedback. (gdb) bt
+ Trace 120880
I can't reproduce the crash. Does it happen reliably? What if you move it to another directory? In Edit > Preferences > Browser, is the "Determine Image Type from Content" selected or unselected? Does it make a difference if you change that? Do you have dcraw installed? The incorrect mime type is worrisome, though. We may have to override gnome's mime type detection for CR2 files (we do that for NEF files already). Anyway... if you have any additional clues, they would be useful... - Mike
Happens every time. After it happens, I need to delete thumbnails cache to make it happen again (rm -rf ~/.thumbnails). The "Determine Image Type" checkbox is unchecked. When I check it, it no longer crashes. But it does not display any thumbnail either. I don't have dcraw installed. You get the thumbnail?
Yes, I get a thumbnail. Do you know how to compile from svn? I added a patch to svn trunk to override the gnome mimetype detection, so CR2 files will not be recognized as TIFF files. I don't see much in your backtrace. Can you try "bt full" and "thread apply all bt" and see if it generates something more suggestive of a crash? - Mike
The change from svn made only difference in that now it tried to thumbnail the CR2 file regardless of the preference toggle "Determine Image Type". I also slurped a NEF file from the internet (http://www.steves-digicams.com/nikond1/samples/DSC_0489.nef) and it crashes on it, too. After restart, it reads corrupted thumb from ~/.thumbnails. Opening that NEF file then gives me correct image, but only 160x120 in size.
bt full backtrace available at http://raven.oook.cz/gthumb.txt
Created attachment 85105 [details] libopenraw-generated thumbnail of DSC_0489.png Here is the thumbnail of DSC_0489.png generated on my system. Note the odd garbage at the top of the image. Maybe libopenraw is generating corrupt pngs or something. I will ask Hubert Figuière, the author of libopenraw, to comment. - Mike
I think it is more about Gnome/gthumb picking up that file as being TIFF and libtiff choking on it. I have seen that happening. The version of Gnome I currently have does not exhibit the problem.
Hubert, the svn versions of gthumb override the gnome mimetype identification for CR2 files. (The release and svn versions do this for NEF too). I don't think it is a libtiff issue. What do you think of the thumbnail in comment 6? Do you see similar "noise" at the top of the image when you generate a thumbnail from http://www.steves-digicams.com/nikond1/samples/DSC_0489.nef? - Mike
Pav, Can you temporarily remove libopenraw, and install dcraw? (And delete your thumbnail cache too.) If libopenraw is not present, gthumb will use dcraw to generate thumbnails. - Mike
With gthumb built without libopenraw and no dcraw, I get letterboxes thumbnail on NEF file, and nothing on CR2 file. With dcraw added, I get good thumbnails on both NEF and CR2 files. I can also open the pictures just fine. Only drawback of dcraw seems to be ~15 second processing time on the CR2 file.
> What do you think of the thumbnail in comment 6? Do you see similar "noise" at > the top of the image when you generate a thumbnail from > http://www.steves-digicams.com/nikond1/samples/DSC_0489.nef? the D1 is not in the list of supported cameras YET. Because I didn't have a sample. I'll check that.
(In reply to comment #11) > > http://www.steves-digicams.com/nikond1/samples/DSC_0489.nef? > > the D1 is not in the list of supported cameras YET. Because I didn't have a > sample. > > I'll check that. Works for me with the "demo" program from libopenraw. Make it is libopenraw that is called and not libtiff.
The demo/thumbc from libopenraw dist gets me a correct thumbnail, when invoked on the CR2 file manually.
BTW it spits this on console ** (gthumb:98633): DEBUG: file /usr/home/pav/_/IMG_9410.CR2 is raw I checked and this comes from libopenraw, so it's obvious it's called.
The demo/thumbc program doesn't seem to work on the http://www.steves-digicams.com/nikond1/samples/DSC_0489.nef file for me. It creates a jpg file, but gthumb can't read it (nor can any other viewer). - Mike
Pav, what version of gtk2 do you have installed? (I have 2.10.8). - Mike
gtk-2.10.11, and the GNOME platform is at 2.18.0
Downgrading to 2.10.8 changed nothing for me.
(In reply to comment #15) > The demo/thumbc program doesn't seem to work on the > http://www.steves-digicams.com/nikond1/samples/DSC_0489.nef file for me. > > It creates a jpg file, but gthumb can't read it (nor can any other viewer). It does not generate a JPG file. Just a file that has a .jpg extension (because I was lazy when I wrote these). The file is actually a 160x120 RGB8 pixmap. Use rawtoppm to convert it to a ppm file.
Oh, thanks. The demo program does create a good thumbnail. There is something flaky in the gthumb/libopenraw interaction though. Sometimes I get corruption in NEF thumbnails, sometimes I don't. (A corrupted thumbnail is shown in comment 6). I've seen this in at least two NEF files. But right now, I can't reproduce it! Maybe there is some sort of race condition in "or_gdkpixbuf_extract_thumbnail"... - Mike
does the problem still occur with libopenraw 0.0.4?
Created attachment 105765 [details] thumbnails with libopenraw 0.0.4
It no longer crashes with libopenraw 0.0.4. But the thumbnail have wrong colors, see attachment.
without the original file, hard to tell. but I can assure you that the thumbnail data is just *extracted* from the file. no processing applied.
Different raw file is available for download in the original bug report - it too exhibits wrong color in thumbnail. The airplane shot from the sample I just attached is temporarily for download from http://hood.oook.cz/letadla/
Created attachment 105770 [details] the thumbnail from IMG_8013.CR2 Attached is the thumbnail I extracted. You'll notice that there is not problem unlike on the screenshot. Are you sure it is using libopenraw?
./configure said Have libopenraw: yes so I suppose it's using libopenraw, and I don't have dcraw installed. But you're right, yours look like embedded thumbnails, with those characteristic black bands. When I run demo/thumb thingie from the libopenraw's tarball on these files, I get correct files, too. So it must be something in interaction between libopenraw and gthumb.
AFAI, gthumb use the available thumbnail if it exists.
I have added some debugging printf calls to the gthumb source, and I can confirm that or_gdkpixbuf_extract_thumbnail() is actually getting called, and that it returns non-NULL pixbuf. There seems to be a problem with the second argument to that function call. When I give it a zero, it returns correct thumbnail. When I give it 120, which happens to be a size of the embedded thumbnail, it returns correct thumbnail. But when I give it 164, it returns a green blob.
Correction: anything below and up to 160, which is a size of embedded thumbnail.
The size is actually 160 in that specific case. Apparently the bug is that the higher resolution preview has a strange color cast. I don't know exactly why. However this revealed another bug I forgot about as the bigger resolution is not recognized as JPEG.
The intermediate size thumbnail is now recognized in the right format, ie 8RGB. Code in git. I think that this bug should be closed. I'll release 0.0.5 very soon now.
I have upgraded to libopenraw-0.0.5, but the thumbnails are still green.
Just checking... did you remember to rm -rf ~/.thumbnails? - Mike
Yes, I did rm -rf ~/.thumbnails, even renamed the raw file to be absolutly sure.
I never said the green was fixed nor that it would be. This is because that's the way the data is in the file. This bug is about a crash due to wrong format being used or provided. I think I have ironed out most of the issues now.
As for the crash alone, yes, that seems to be fixed now. Thank you!