GNOME Bugzilla – Bug 338632
Missing frames on some image thumbnails
Last modified: 2008-03-17 23:23:11 UTC
Please describe the problem: When Nautilus create the thumbnails for images, some of the images show the frame around the content and other don't. This bug occurs indifferently with png, gif and jpeg. See this screenshot for an example: http://img460.imageshack.us/img460/4822/nautilus2ii.png Those images were generated in different days with gimp, imagemagick and the PNG exporter of Matlab. The problem is generally reproducible, but after I've upgraded nautilus 2.12.x to nautilus 2.14.x some images that were displayed with the frame suffer from this problem. At first I thought that the bug could be related to the presence of an embedded thumbnail, but I think that for consistency sake the frame should be always added. Steps to reproduce: Actual results: Expected results: Does this happen every time? Other information:
*** Bug 338633 has been marked as a duplicate of this bug. ***
I noticed this when doing an upgrade, that the old pictures didn't have a frame, and the newly thumbnailed ones did. By removing the ~/.thumbnails/ directory I didn't see this bug anymore. Could that be the same case for you? That images that were thumbnailed by an older version are still cached?
I removed ~/.thumbnails/, and the situation worsened. Now more or less one out of four of my image files gets the frame around the thumbnail. Also, it seems that, randomly, some video files don't thumbnailed anymore.
The video issue needs to be taken with totem, but most probably, some plugins aren't installed that were, and you're now unable to open them... Can you tell any system between images that do have borders and those that don't? File type? Size (in pixels)? Filesize (in bytes)? anything of that matter you could add?
I'm afraid that it is not a totem problem, because restarting nautilus the file get thumbnailed, and removing .thumbnails/ and restarting nautilus again can end with those files thumbnailed and some others, previously working, not. The images haven't got common properties, as far as I can remember. Size varies from 50x50 to 1024x768, the format can be jpeg, png, gif or svg, the images were generated (or edited) by imagemagick, gimp, inkscape, gnome-screenshot, the png exporter of Matlab, or downloaded from internet.
sorry for the bugspam, but is there any news?
ah-ehm...
Maybe it's a artefact of (changelog) 2004-12-17 Alexander Larsson <alexl@redhat.com> * libnautilus-private/nautilus-icon-factory.c: (load_icon_file): Don't use frames for images with alpha.
Indeed, it might be related. I've looked at some of these picture-with-no-frame and they are all using an alpha channel and as soon as I remove the alpha channel, the thumbnail is generated with the frame.
(In reply to comment #9) > Indeed, it might be related. I've looked at some of these picture-with-no-frame > and they are all using an alpha channel and as soon as I remove the alpha > channel, the thumbnail is generated with the frame. > I reverted that change and now every thumbnail has its frame. I'm afraid that this is not a bug but a design choice. I think however that this behavior is acceptable when the transparency is effectively used (for example icons with blank space around the represented object) but gives bad results when the alpha channel is present but unused (for example a screenshot or a picture with white background).
I agree, maybe we could patch it to check that alpha channel values changes. Something like : check_alpha_use(img) { for( x=0; x<img.width; x++) for( y=0; y<img.height; y++) b = a; a = img[x][y]; if (a!=b) return true; return false; } Complexity would be o(img.width*img.height) (if I'm not mistaken) but I don't know if it is acceptable.
It might be a good idea to restrict those alpha-channel tests to the four border lines of the image. If the image is an icon, it would have alpha-channel used at at least any of the border.
Occurs in 2.20
*** Bug 500081 has been marked as a duplicate of this bug. ***
This is fixed now since 2.21. Closing as OBSOLETE, thanks for reporting this bug. Please feel free to report any other bug you find!