Created attachment 34491 [details]
The .tif file

confirmed

TIFF seems to be a very significant problem for both of the major free software desktops.

As an example, I have a CD of telecommunications cable plans, which are mainly high resolution TIFF images. If you try to open the CD in Nautilus (or Gthumb, or Konqueror or Gwenview etc.) it loads up the list of files fine, however when it tries to generate thumbnails, it attempts to allocate a huge amount of memory (at a guess around a few hundred MB) per image.

I have a feeling this is because it tried to load the original high-res TIFF into a pixel buffer before scaling it to a thumbnail.

Certainly a better method for dealing with TIFF images would be to use a tile based or strip based read method, then scale that strip and put it into the thumbnail buffer.

The same problems occur when trying to view these images with "generic" image viewers - they attempt to load the entire image into a pixel buffer and manipulate that, rather than just reading the appropriate parts of the original TIFF image.

(I understand that by doing it that way, it is easier to code for the large number of cases where loading it into a pixel buffer is sufficient, but maybe that is a fundamental problem with the image viewing parts of the library)

The issue is not a leak, it's caused by the preloader. The preloader loads some images when it has enough time. So, even if you only want to see the thumbnails, the program loads some images anyway in the background. It's easy to test, just comment the call to gthumb_preloader_start at gth-browser.c and then the problem disappears (but you won't be able to see the full image if you press the Image button in the toolbar).

I don't think that this issue could be fixed without some changes in the design. The first solution could be remove the preloader. The other possible fix could be not to preload big images, but it'll imply design changes IMHO, because we need to read the images first in order to get the amount of bytes that they'll occupie in memory (in a similar way like gdk-pixbuf for example with one factory and some loader modules).

The image is so huge that it occupies more than 200MB into memory (IMHO we shouldn't preload it). But the situation becomes worst when there is no previous thumbnail for the image, then the image is loaded twice, that's why the total amount is more or less 450 MB.

There are some bugs in this process:

1) if the thumbnail does not exists, then the application creates it and preloads the image, but if the thumbnail exist the application does not preload the image (non-consistent behavior)
2) the image is loaded twice when there is no previous thumbnail, because it is not detected correctly whether the image was loaded before or not. The is because the program checks if any preloader has loaded the image before, but if the thumbnail does not exist then the image is loaded without a preloader so nobody knows if it's already loaded.

See also the related gtk+ bug 142428.

As mentioned in the original comment, EOG doesn't have a problem loading this image, but gThumb does.  What is the difference in how they load TIFF files?

As far as thumbnailing goes, can't the Nautilus thumbnailer be changed to use something like the command listed in bug 142428 comment 7:

tifftopnm $1 | pnmscale -width 128 -height 128 | pnmtopng > $2

I've committed a patch in svn trunk to use something like:

tifftopnm -byrow infile | pamscale -xyfit 128 128 > outfile

when generating tiff thumbnails. Now, memory consumption jumps ~220 MB instead of ~440 MB when using the sample image above. This hack can be removed if/when gdk-pixbuf is improved (bug 142428).

The preloader issue remains.

- Mike

I think a preloader dimension sanity check could be added in src/gthumb-preloader.c:set_paths__step2, right after 

if (path == NULL)
    continue;

This would stop "background" preloaders (called by gthumb_preloader_start), but not "foreground" loaders (called by gthumb_preloader_new) - I think.

- Mike

Actually, the sanity checks should augment the ones already in src/gth-browser.c:get_image_to_preload.

Is there a quick method to get the dimensions of an image file, without loading it entirely?


- Mike

This problem has been fixed in the development version (svn rev . The fix will be available in the next major software release. Thank you for your bug report.