Image caching

[derniwi]

Hi,

a single 8 MPixel picture needs about 24 MB of Ram, if it is unpacked. Caching the file from the file system should not be efficient. If a tool should cache, than it should open and decompress the next picture.

Multipage pictures: does IView open and decompress all pages while opening or does it just deocmpress the actual pic?

Maybe this option could also be choosable like the "load custom file types" option.

Greets, Nils.

[j7n]

We are talking about keeping the decompressed data in memory. The system can take care about disk cache very well.

This feature should be made operational with any img size. That's why I proposed additional switches.

[derniwi]

Hi,

the system has a disk cache for files allready opened. But nor for the next image on the hard disk.

So a prefetching is usefull for a lot of files but setting an upper limit should be possible.

Regards, Nils.

[midora]

If you like to prefetch images and to keep the uncompressed data depending on the size than this means you first have to do the uncompression. There is no other chance if you are looking to the current plugin interface. Means you have to load it just to decide to throw it away. Users may not be happy with the reaction time of the application in some situations.

I'm just saying caching is not as easy as some people may think about. ;-)

[derniwi]

Hi,

as far as I know the most picture file formats stores the width and height in seperate fields so a decompression is not needed, and also it is not necessarry to load the whole file. And if I know the file type and the dimension I can calculate the amount of RAM needed for opening and decompressing the file.

I'm not saying that this job is an easy one. And it seemd to be a good job for multithread programming, so it should be possible to turn around the actual picture while the next file is still being loaded.

Regards, Nils.

[midora]

Be realistic, who will change the interface to all existing file format plugins provided from different people? (so that the main application gets this width and height information w/o getting the whole image from the plugins).

[Vizitator]

Feature already requested

The feature requested by ElfQrin was already asked for many month by Vizitator in the thread: "Preload the next image in memory". Please read also this thread. I also salute the ElfQrin's request, as this makes my request stronger, being asked by a larger number of people.

[e99plant]

I don't think the responsiveness issue is that great - ACDsee seems to handle it fine, even the 10MB files.

You could have the image pre-loading in another low-priority thread.

[j7n]

The threshold of what a "big" file is depends on how powerful is the computer in question.

[Bhikkhu Pesala]

In thumbnails mode, the display of images (around 2 MB each) is very slow: I see the drawing of each image one after the other, row after row. For 500 photos (jpeg), it takes about 25 seconds

With the photo gallery of Windows Vista, for the same folder, it's practically instantaneous (less than 1 second).

This is not a bug. 500 photos could mean 250 Mbytes of images so 25 seconds would be about right to generate thumbnails. I find that one directory of large images (total 90 Mbytes) takes about 5 seconds. The reason that Windows Vista and XP take only 1 second is because they cache the thumbnails in a hidden Thumbs.db for each folder. They therefore need to load only 121 Kbytes Thumbs.db instead of 90 Mbytes of images, and there is no need to resample each image either, as it has already been done once before.

This feature request for Image Caching has already been made several times. Personally, I do not see what harm there is in this, but it should be an option that one can turn off (as one can in Windows Explorer, Folder Options). For an image viewer, I would say that it is an essential feature.

[Bhikkhu Pesala]

Added to Project List

[Bhikkhu Pesala]

Request for Image Caching Added to Project List

[schmirk]

Tweakable Thumbnail Caching

Thank you for irfanview,
I use the thumbnail viewer often with directories of many 30MB tiff images. It is agony waiting for the thumbnails to display. In days gone by aseedsee, with its thumbnail cache, would whip open these directories. Now that I use irfanview instead (im stubborn and wont switch away from a supperior tool) I have to suffer since browsing via thumbnails is my most used feature. I would really, really like to be able to cache them puppies in a directory of my choice (fragmentation containment partition). This would make me very happy and save me from the torment wondering if I need to migrate to some other viewer just because I need a feature that should have been included in version 0.0.1 of the Thumbnail viewer.

Brandon

[DarkCless]

It could be useful for some and more options the better for sure ; but there should definitely be an option for it and preferably disabled as default.

I remember using Xnview years ago and was a bad shock to see the program folder became 200 mb in a few days; storing a copy of each image i viewed

[schmirk]

RE: Request for Image Caching Added to Project List

1. Cache the next image in the directory
2. Retain the previous image in the cache
3. Option for don't cache images larger than xxx kbytes
-----------------------------------------------------
It doesn't sound like this addresses the particulars I suffer from. I do not need the actual image cached for viewing after the current image... What I want is the generated thumbnail files, when using thumbnail viewer, to be saved in a permanent cache on the hard drive in a directory of my choice. So when I return later, Thumbnail Viewer does not have to process 100 30MB files into thumbnails again.

If the above is stating that this will be fixed then I apologize for my lack of ability to decipher that.

Brandon