Progressive display

Ideas for improvements and requests for new features in XnView Classic

Moderators: XnTriq, xnview

Post Reply
thany
Posts: 8
Joined: Sat Nov 08, 2008 7:44 pm

Progressive display

Post by thany » Sat Nov 08, 2008 7:55 pm

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.

User avatar
RGBA
Posts: 45
Joined: Fri Jul 18, 2008 10:41 am

Post by RGBA » Sun Nov 09, 2008 3:29 pm

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?
XnView 1.95.3 de | XP Prof. SP3

thany
Posts: 8
Joined: Sat Nov 08, 2008 7:44 pm

Post by thany » Sun Nov 09, 2008 9:18 pm

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.

User avatar
JohnFredC
XnThusiast
Posts: 2010
Joined: Wed Mar 17, 2004 8:33 pm
Location: Sarasota Florida

Post by JohnFredC » Mon Nov 10, 2008 7:15 pm

*feels* faster because images display as they're being loaded, just like a web browser
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.
John

User avatar
RGBA
Posts: 45
Joined: Fri Jul 18, 2008 10:41 am

Post by RGBA » Mon Nov 10, 2008 7:36 pm

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!
XnView 1.95.3 de | XP Prof. SP3

User avatar
Troken
Posts: 698
Joined: Thu Feb 09, 2006 10:18 am
Location: Sweden

Post by Troken » Tue Nov 11, 2008 12:15 pm

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.

thibaud
Posts: 269
Joined: Sat Dec 02, 2006 12:41 am
Contact:

Post by thibaud » Tue Nov 11, 2008 3:31 pm

(Times are not respresentative of reality)
Indeed, everybody is aware that acdsee will complete the whole process in less time actually. :wink:
but ACDSee *feels* faster because images display as they're being loaded
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!
this topiccovers just about the same issue.
Last edited by thibaud on Thu Nov 13, 2008 10:43 am, edited 1 time in total.

thany
Posts: 8
Joined: Sat Nov 08, 2008 7:44 pm

Post by thany » Wed Nov 12, 2008 6:39 pm

thibaud 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!
Thanks :)
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.
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.
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)

User avatar
JohnFredC
XnThusiast
Posts: 2010
Joined: Wed Mar 17, 2004 8:33 pm
Location: Sarasota Florida

Post by JohnFredC » Wed Nov 12, 2008 7:34 pm

No sarcasm intended!
John

Post Reply