This is one of the biggest features that I miss in comparison to my old image viewer. I want to use XnView to browse through large amounts of medium to large pictures, that could be on relatively slow (networked) drives. Fast or slow, browsing "feels" slow because it takes at least half a second to display an image in the preview. Say my images are on USB sticks or memory cards and they are multi-megapixel. Believe me, waiting 10 seconds for a poto is not cool.
My old image viewer - ACDSee Classic 2.43 - can show images progressively. This would work with PNG, JPEG, BMP, GIF (unless animated) and other, less frequently used formats. It works beautifully on those slower mediums. You would see the image building up as it loads. It feels quickly because after selecting an image, something starts to display right away, instead of on a several-seconds delay.
NOTE that I'm NOT talking about the phenomon knows as "progressive jpegs". I'm talking about displaying an image while loading. ANY jpeg, ANY png, ANY bmp and ANY nonanimated GIF can do this. ACDSee would display them like a browser: they load from top to bottom. Interlaced pictures load even lines, then odd lines. BMP's load from bottom to top.
I hope I'm making myself clear, because I've been down this road where "progressively saved images" was horribly confused with "progressive display like a browser".
Sorry to be so frank with my very first post
I hope this will be in some next version.
Progressive display
Moderators: XnTriq, helmut, xnview
Is your opinion only viewer thumbnails are too slow?
- There are several options, which can have effect to the load sequance
like preprocessor settings, for example (extra) sharpen, no usage of embedded thumbnails and so on..
also: is 'use high quality' on?
ACDSee Classic 2.43 loads it maybe faster, because it may set to load in lower quality?
- There are several options, which can have effect to the load sequance
like preprocessor settings, for example (extra) sharpen, no usage of embedded thumbnails and so on..
also: is 'use high quality' on?
ACDSee Classic 2.43 loads it maybe faster, because it may set to load in lower quality?
XnView 1.95.3 de | XP Prof. SP3
I'm talking about the previewer and the fullscreen viewer. Whereever an image is shown at maximum size. No thumnails, I don't even use them.
Let me try and clarify. XnView is not too slow. Not at all, it may even be faster than ACDSee, but ACDSee *feels* faster because images display as they're being loaded, just like a web browser. It has nothing to do with quality.
To clarify even more:
ACDSee (and some others):
at 0ms: user selects image (on USB stick, image is JPEG 4000x3000, 12MB)
at 1ms: previewer knows dimensions of image and creates a border
at 5ms: image starts to display, the top few lines already appear
at 10ms: another few lines have appeared
...
at 5,000ms: about half the image is loaded, and half of it is displayed
...
at 10,0000ms: done loading&displaying
XnView:
at 0ms: user selects image (on USB stick, image is JPEG 4000x3000, 12MB)
at 1ms: application starts loading & decoding
...
at 8,000ms: done decoding, start resizing (if neccesary)
at 8,500ms: done loading, image will now be shown
(Times are not respresentative of reality)
You can see that ACDSee might be slower, but because something starts to show right after selecting an image, it *feels* quicker. Only in ACDSee I can decide to skip to the next image if the selected one is not the one I need, because I can already see a part of it.
Let me try and clarify. XnView is not too slow. Not at all, it may even be faster than ACDSee, but ACDSee *feels* faster because images display as they're being loaded, just like a web browser. It has nothing to do with quality.
To clarify even more:
ACDSee (and some others):
at 0ms: user selects image (on USB stick, image is JPEG 4000x3000, 12MB)
at 1ms: previewer knows dimensions of image and creates a border
at 5ms: image starts to display, the top few lines already appear
at 10ms: another few lines have appeared
...
at 5,000ms: about half the image is loaded, and half of it is displayed
...
at 10,0000ms: done loading&displaying
XnView:
at 0ms: user selects image (on USB stick, image is JPEG 4000x3000, 12MB)
at 1ms: application starts loading & decoding
...
at 8,000ms: done decoding, start resizing (if neccesary)
at 8,500ms: done loading, image will now be shown
(Times are not respresentative of reality)
You can see that ACDSee might be slower, but because something starts to show right after selecting an image, it *feels* quicker. Only in ACDSee I can decide to skip to the next image if the selected one is not the one I need, because I can already see a part of it.
I've not seen ACDSee supports any Tag-Infos (MetaTags),
maybe this speeds up the loading time, but don't let you edit it,
if you need and work with them.
Also please check your settings here in XnView:
Options - View - Misc
Cache
[] Read one image ahead
[] Keep current image in cache
Options - View Fullscreen
[] Use delayed high quality.. (..affects preview)
Some settings affected to better quality can reduce the runtime notable!
maybe this speeds up the loading time, but don't let you edit it,
if you need and work with them.
Also please check your settings here in XnView:
Options - View - Misc
Cache
[] Read one image ahead
[] Keep current image in cache
Options - View Fullscreen
[] Use delayed high quality.. (..affects preview)
Some settings affected to better quality can reduce the runtime notable!
XnView 1.95.3 de | XP Prof. SP3
It is a thing I been thinking about many times, XnView is not very good at giving response to the user while processing a big task. It could be building thumbnails, processing a filter, opening a large image.
I think it has been discussed at other threads. An hourglass, progressbar or something similar would be nice, and perhaps speed up the experience of using the program. Its not fun when you don't know if XnView is working or simply has crashed.
I think it has been discussed at other threads. An hourglass, progressbar or something similar would be nice, and perhaps speed up the experience of using the program. Its not fun when you don't know if XnView is working or simply has crashed.
Indeed, everybody is aware that acdsee will complete the whole process in less time actually.(Times are not respresentative of reality)
I'd say this is actually much much more than a feeling:but ACDSee *feels* faster because images display as they're being loaded
being able to preview an image while it's not finished loading in the viewer does TREMENDOUSLY speed up your workflow!
this topiccovers just about the same issue.
Last edited by thibaud on Thu Nov 13, 2008 10:43 am, edited 1 time in total.
Thanksthibaud wrote:I'd say this is actually much much more than a feeling:
being able to preview an image while it's not finished loading in the viewer does TREMENDOUSLY speed up your workflow!
And yes, you are right, we use a browser to view images similarly. If you're looking for an image on the web, you can load the fullsize image one by one, but since images display while they load, you can decide to stop loading and go back prematurely.
So even if it does slow down an application by a few milliseconds... Who gives a bleep if the workflow (even if it's not work) is twice as efficient? However, an hourglass or progress bar would not be preferrable, because they don't provide visual feedback, they only provide technical feedback. It's a usability thing.
I'm not sure if you're being sarcastic, but even if you are, you're still hitting the nail on its head. Like I said, it's a usability thing. The blink of an eye is, for certain operations, a long time. What if every one of your keystroke would produce a 100ms delay? (that's faster than the blink of an eye)JohnFredC wrote:I have to agree whole-heartedly with this point. Manipulating a user's subliminal psychology by providing feedback during operations which take longer than the blink-of-an-eye is important.