Image caching

[rocsen]

Here's what Irfan wrote back in 1996 when he released IrfanView version 1.99:

Version 1.99
- New fast directory view ! This part is now totally rewritten;
no more lost files and incomplete lists. Files are shown in the
order how they stay in FAT, that means unsorted.
Coming in next release:
- Sorting files in alphabetical order.
- Fixed bugs with some ICOs, and compressed BMPs
"Read ahead" - processing next image in the background is not implemented. It doesn't bring wished effects, especially on faster machines (Pentiums).
Why? Because the background processing of the next image slows down showing of the previous (even on faster computers, even with faster graphic cards).

Maybe this was the case back in 96. Times have moved on and I've not noticed any issues in other viewers that do use the read ahead caching.

With that, here is one more vote to add the feature. Until it's implemented I'll stick with Picasa.

[boarder's paradise]

It doesn't bring wished effects, especially on faster machines (pentiums).
Why?
Because the background processing of the next image slows down showing
of the previous (even on faster computers, even with faster graphic cards).

Sorry, but this is complete nonsense. No matter when it was said, because the problem described is unrelated to hardware performance. Prefetching - when properly implemented - should only use resources when the application (or optionally the system) is idle. So there can't be negative impacts on the user.

E.g., when the application receives a command (via user input) to display another picture, prefetching should halt and continue only once the requested image is displayed entirely.

[derniwi]

I think it would be better first to have a multithreading program, which will use multiple cores if they exists. I'm not really good programmer for graphical tools but as far as I know is JPEG block based, so this might have a benefit with multiple cores. Other graphic formats may be processed as slow as a single processor could.

But yes, prefetching would be nice, customizeable which file types and which file size.

[MItaly]

It would be enough to start a separate prefetching thread with the lowest priority.

[Driber]

caching/read-ahead

I would like to see a read-ahead (decode next image in advance) so that when you're going through a bunch of large images (4MB or larger) there won't be a delay every time you press next.

Similarly, a cache behind (keep previous image in memory) would also be very useful for example when you switch back and forth between 2 images to see the difference.

I've been using ACDSee for years and I would like to switch to IrfanView, but the lack of caching keeps me from doing so because browsing images full screen just doesn't go very smoothly without it.

[WellOiledPC]

IrfanView's purpose it to be small (under 1.5 MB without the Plug-ins), fast and consume minimum memory as well. I am not a programmer so I do not know whether implementing Cache/ Prefetching would increase the memory requirement to run the program. It is for this reason that IrfanView has implemented a Single Level of Undo alone, vis-a-vis the Multiple Undo feature that you find in other programs.

IrfanView's purpose has not changed ever. So if this requires a lot more memory, increases the program size and/ or generally slows down operations, it is unlikely to be implemented, in my opinion.

[400D]

I converted to Irfanview today on recommendation.
What a nice tool, thank you

Just to add my support to those asking for read ahead. This is the only feature of Windows Picture and Fax Viewer that I miss! Pause for long enough (a couple of seconds or more) on a photo in that tool and the next one will display the instant that the Next Image button is pressed. That there is no "read behind" feature (in case you press Previous Image) doesn't matter so much IMO.

To add further support, I was so convinced that Irfanview would have such an obvious feature as read ahead that I spend an hour looking for where it was hidden...

[Driber]

IrfanView's purpose it to be small (under 1.5 MB without the Plug-ins), fast and consume minimum memory as well. I am not a programmer so I do not know whether implementing Cache/ Prefetching would increase the memory requirement to run the program. It is for this reason that IrfanView has implemented a Single Level of Undo alone, vis-a-vis the Multiple Undo feature that you find in other programs.

IrfanView's purpose has not changed ever. So if this requires a lot more memory, increases the program size and/ or generally slows down operations, it is unlikely to be implemented, in my opinion.

pre-loading the next image wouldn't consume much RAM if done properly. ACDSee does it quite well with little memory resources used.

and IrfanView isn't so light weight anyway. when I browse my digital camera pictures full screen with IrfanView it uses about 45 MB of RAM when idle whereas ACDSee uses just 14 MB when idle when going through the same pictures!

so it's perfectly possible to implement a read-ahead with minimum RAM increase

[host666]

waiting for this feature for 3 years. can anybody help me to find another tiny prog with this feature and RAW-files reading feature?

[mhe]

waiting for this feature for 3 years. can anybody help me to find another tiny prog with this feature and RAW-files reading feature?

I'd settle for even a response why this is not even up for discussion, as for now, XnView does it for me.

[host666]

just tried XnView - same speed with Irfan. Seems like caching gives nothing for Xn

[sukidayo]

Improve Performance

1. I can go to previous/next 5th file using Ctrl+PgUp/PgDn or arrows. It would be nice if Alt key would allow to go to 10th file and Ctrl+Alt to 20th file.
   
   
2. On 4K monitor upscaling to full screen is very slow. It takes about 150 ms. It is very big lag that makes skipping files significantly slower. For example, to skip 40 files I need about 8 seconds! I have looked how it works — all core of CPU is loaded to 50% but GPU is not used. Maybe you can:
   • Process it in GPU. Number of cores increases with time but resolutions increase too. GPU is much faster and can solve the problem (but I do not about latency).
     
   • Add an option to let users choose scale method. I do not want disable upscaling but I would prefer bilinear interpolation instead of bicubic interpolation. Or do you already use bilinear interpolation?
     
   • Preload some count of next and previous files:
     1. User should have ability to change number of preloading files and also choose how much files keep in memory until exit (for example, preload 4 files but keep in memory 100 files).
        
     2. Files should be already upscaled to current mode (fullscreen or windowed). If user change the mode then, for example, 4 files will be reupscaled (but old version will not be deleted from memory so there can be 2 or 3 versions in memory).
        
     
     
   
   
3. Image decoding is slow too.
   • PNG 3771x1860 (1.2x less then 4K) without scaling is decoded for ~210 ms. I need 9 seconds to skip 40 files. ~3 threads are used.
     
   • JPG 3771x1860: 190 ms. ~2 threads are used.
     
   • Webp 3771x1860: 220 ms. ~3 threads are used.
     
   
   I do not know can it be speeded up but maybe preloading can help.

Also I tried decoding and upscaling at the same time:

• Webp 1.10 MB 3771x1860 with upscaling to 3840x2160: 310 ms (12 sec total).
  
• Webp 2.23 MB 5676x3132 with scaling to 3840x2160: 1025 ms (41 sec total).

As you see at the end I needed to wait 41 sec to skip 40 files 40 files is not much.
So my question: can it all be speeded up?

PS. Normal latency for me is up to 100-150 ms. 60 ms is very fast. But usually I get 400 ms. And this despite the fact that I try to use lower resolutions because of big latency. Even 230 ms is definitely slow but I get 400 ms
PS. If you will start use GPU then preloading will become even nicer because the program can upscale previous file while decoding next file so GPU and CPU can be used at the same time.

[sukidayo]

PS. I would start from upscaling. For example if 390 ms decrease to 260 ms it would be slow but much faster. Very much. Also someday there will be 8K monitors so users will get 500-600 ms at only upscaling stage. If it will be on GPU then resolution will mean nothing. I guess upscaling on simplest Intel GPU probably may take about 5-10 ms but I am not sure.

[Bhikkhu Pesala]

Disable resampling completely.

[sukidayo]

No, images look very bad without resampling.