I recently switched over from XnView to give DOpus standalone viewer in fullscreen mode a try.
Unfortunately I can not find an option to enable an auto-prefetch mechanism of the next images. I know these kind of prefetching from other viewers like ACDsee or XnView and it significantly increases the navigation speed since the next image(s) are already decoded when the user press Page-Down. On the other side the last images are kept in memory to provide a quick navigation in reverse direction too.
Is there any option to enable such caching/prefetching mechanism?
+1 if this is going in the idea box
Are you viewing large image files over a slow network connection or or slow flash stick or similar?
That's the only time I can think of when pre-fetching would make a real difference on modern hardware. (It would've been nice back when decoding and resizing a large image took a second or two but these days that's almost instant. Viewing files on slow media would still benefit, though.)
For me, I have some very large images and sometimes they are on the network. 20-80MB png or psd and i'm waiting 2-20seconds when changing images. Accessing images that large is rare. Most of the time, they aren't over 2MB and local so they are fast. Just thought it would be nice on those rare occasions it would work fast (cached) and I wouldn't even know why
Not that big of a deal though. Like I said, it is rare
Adding to my previous post.
When switching back and forth to compare a couple of images, that's when it starts to get a little to slow and hard to compare.
Some kind of preloading like ACDSee does would make sense, as it is definetely faster also on "normal" sized pictures. Especially when searching fast with mousewheel other viewers are faster, also on modern hardware with SSD 6GB/s, 16GB RAM and i7 at 3,9GHz!
Another missing feature is an option to setup viewer as default one systemwide.
We maintain all of our images on a NAS in the network. There is a public reachable "incoming" folder where anybody can put new images, scans, photos into.
All work with these images are done on a Windows desktop using DOpus accessing the network share. Unfortunately browsing these images using the viewer-pane is far away from instant (takes 2-5 seconds to load the previous/next high-res image).
Most time is spent to search the best photo from each series of 5 or more shots of the same motif. In this use-case you magnify an important area of the photo and quickly navigates through the series back and forward many times to decide which photo is appropriate.
For this common use-case it is vitally important to use a viewer that provides a caching/prefetching mechanism of images to allow instant navigation.
There are some basic features that are needed to let DOpus provide a quick and convenient workflow for large image collections placed on a network drive.
[li] Caching / Prefetching images for the standalone viewer pane[/li]
[li] Automatically load all thumbnails of the current folder in tiles mode (already there for thumbnails mode)[/li]
[li] A resolution slider for the toolbar to dynamically adjust the tiles size (already there for thumbnails mode)[/li]
[li] Toggle button to pin the viewport magnification to be constant during image navigation (use the same magnified viewport for different images to directly compare details in 100% view when switching back/forward in a series of multiple photos of the same motif)[/li][/ul]
I agree that image caching would add to image browsing experience.
Afaik ACDSee's swiftness is coming from hand-crafted assembler jpeg decoding/image display routines.
Pre-fetching the image itself, for slow media, makes sense.
But JPEG decoding is so fast these days that moving to custom assembler for it just doesn't seem worth the development and maintenance time nor compatibility worries. Maybe it did 10-15 years ago but not now.
The largest JPEG I could find (5120x1600) loads, decodes and is on the screen in a fifth of a second on my main machine, and half a second on my very underpowered HTPC. (And, with that as an upper-bound, most images files are much smaller and several times faster to load, while people regularly dealing with such large files would almost always do so on high-spec machines.)
@Leo: When scrolling from pic to pic you're right, but when scrolling fast trough pics (e.g. when searching) the viewer is slower compared to ACDSee - not much, but it is (on high-end hardware and a bit more on my slower Slate with i5 and SSD)!
Agree... this is where I notice a load delay the most, and where a read-ahead would certainly help.
Leo, it would be fantastic if the thumbnails of all images in a folder are automatically loaded in tiles mode (as it is done in thumbnail mode).
Maybe the thumbnails related settings of the thumbnails-mode should apply to the tiles-mode also if thumbnails are enabled for tiles-mode?
There's no need to ask for the same thing in several different threads.
I just wanted to post my idea of applying the thumbnails settings to tiles-mode also because I was curious what you think about that!?
Obviously I was not aware that I have had posted this idea before. Sorry for that.
It was only three days ago, in Configuring fields for thumbnail mode.
Anyway, it's unrelated to Prefetching images in standalone viewer.
(BTW, I agree that it'd make sense for some of the thumbnail options to be added to tiles mode. I'm a bit grumpy at the moment due to a nasty ear infection.)
Ah now I see. You misunderstood me.
My first idea was to introduce the thumbnail settings to the tiles mode also. But my new idea (as mentioned in this thread) was to apply the same settings of the thumbnails mode to the tiles mode if the latter is in thumbnails mode.
In other words instead of duplicating the options from thumbnails to tiles you can provide a single button to use thumbnails configuration / rendering in tiles-mode also. But maybe the duplication of the settings is more obvious.
Anyway, the settings are heavily needed but offtopic in this thread.
Get well soon!
Want to push this one..
I like that image prefetch/caching idea and "suffer" from rather slow image loading/switching as well.
I upgraded my camera these days and now that there are some megapixels more to work with, times raise as well, when switching between images back and forth to find the sweetest/sharpest of a series e.g.
I'm on a 2.8ghz Quadcore / 8GB Ram, not the slowest machine out there, but nowhere high end either.
It makes no difference if images were accessed from (slower) sd-card or from hardisdk, so any delay is decoding related, as it seems.