Speed of High quality zoom, more HQ zoom options?

[BreakfastMan]

Here is a quote from something I wrote online:

XnView is a very polished and professional looking program.
But, I have one big complaint with it. Images sized to fit the screen
look really bad unless "High zoom quality" is turned on, but if High
zoom quality is on program is slower than molasses.

Here is my suggestion. Irfanview has about 6 different methods available for resampling an image to full screen size (hermite, triangle, mitchell, bell, b-spline, lanczos)... some of these are faster than others, but even the fast ones are good enough quality for me. Also, Slowview's high quality zoom full screen view is fast, and of good enough quality for me.
I don't know what methods they use, but maybe you could make two options for high zoom quality- one that does the method you use now, and one that is faster, but better quality than your current low quality fast zoom. Your current fast zoom is pretty rough, and I have heard this is the reason why some people do not use XnView.

I do love how polished, professional looking, and bugfree XnView is though.
Thanks very much.

[xnview]

... Images sized to fit the screen look really bad unless "High zoom quality" is turned on, but if High zoom quality is on program is slower than molasses. ... Here is my suggestion....

Yes, i know this problem. I'll work to improve it!
Pierre.

[Olivier_G]

I update this thread and make a list of various usefull requests about this 'High Zoom Quality' issue:

- Use 2 passes (Normal quality first, then Higher quality in the background)
- User's actions should start immediately (and interrupt background processes if required).

Now, my turn:

I noticed that when using normal zoom quality, there is no impact on memory and the image is immediately resized by using 'Nearest Neighbour' (which just increases the size of the pixels. It's fast, but looks terrible for normal use).
When using "High Quality Zoom", it takes some time and requires more memory: it looks as if XnView was resizing the whole image in memory first in order to show it!

Here are my suggestions:
- Calculate only the area that is really showed in the window.
- When moving/scrolling the area or resizing the window, calculate only the new parts.
- You should be able to choose the calculation method for both 'Enlarge' and 'Reduce' (+Thumbnails) through drop lists [nearest neighbour, bilinear, bicubic, lanczos... with an additionnal sharpening factor - a commonly used option].

If this method is still too slow: take into account the 2 previous suggestions (Priority of User's action + 2 Passes).

Olivier
PS: the Priority of User's action over background processes should be the norm everywhere in XnView...

[Dreamer]

I have heard this is the reason why some people do not use XnView.

I know users who don't use xnview because it's slow for them (start, zoom...) or use xnview for editing, converting only and other (faster) viewer for viewing

I know Pierre is working on these "speed" problems and I trust that he will solve it

Here are my suggestions:
- Calculate only the area that is really showed in the window.
- When moving/scrolling the area or resizing the window, calculate only the new parts.

I'm not sure if some problems couldn't occur on slower computers when moving an image...

[Olivier_G]

Here are my suggestions:
- Calculate only the area that is really showed in the window.
- When moving/scrolling the area or resizing the window, calculate only the new parts.

I'm not sure if some problems couldn't occur on slower computers when moving an image...

I just tried IrfanView (worst situation => lot's of RAM needed in HQ), Brennig/SlowView (no HQ in zooming >100%) and ACDSee...

ACDSee is not using any additionnal memory when zooming beyond 100% and always feel very responsive (even with a 48 bits 60MB image on my AMD Athlon 2500+). I suppose that they use this kind of solution (well... I can't come with a better one... so I suppose so ).

It looks like ACDSee is the one to beat. Could be worth trying...

Olivier

[Olivier_G]

Here are my suggestions:
- Calculate only the area that is really showed in the window.
- When moving/scrolling the area or resizing the window, calculate only the new parts.
[snip]
PS: the Priority of User's action over background processes should be the norm everywhere in XnView...

This suggestion hasn't been implemented in 1.80. It might be worth trying/testing in a future version.
(I believe that we can expect a drastic improvement in performance from this...)

Olivier

[X-Byte]

This request ist more than two years old right now.
And it's still the major reason that keeps me (and i guess many others) from switching to XnView as my main Imageviewer.

Zooming in with a decent (high!) quality is a real pain in the ass using XnView, as mentioned many times in many threads before.

The reference for fast quality zooming is ACDSee, as pointed out by others before. I'm not sure but I think ACDSee makes use of some DirectX functions for zooming.

Can we have a word from the author if there are any plans to investigate the zoom issue anymore?

Besides that, XnView rocks!

[xnview]

This request ist more than two years old right now.
And it's still the major reason that keeps me (and i guess many others) from switching to XnView as my main Imageviewer.

Zooming in with a decent (high!) quality is a real pain in the ass using XnView, as mentioned many times in many threads before.

The reference for fast quality zooming is ACDSee, as pointed out by others before. I'm not sure but I think ACDSee makes use of some DirectX functions for zooming.

Can we have a word from the author if there are any plans to investigate the zoom issue anymore?

No i don't think that ACDsee use DirectX, and one thing there is many developers for ACDsee, for XnView i'm alone.
I'll try to make this request....

[JohnFredC]

I have thought about this topic quite a bit... what strategy would be best?

For zooming in:

Obviously, on initial zoom-in or mouse navigate, hesitate (wait for another immediate zoom-in), then after the hesitation interval (perhaps a value set in the ini, or calculated from the pixel size of the image vs. the zoom ratio), enhance the centered field of view first. Also, perhaps, calculate one scroll-size/distance in pixels and enhance all of the centered field plus 1 "scroll" field in each direction in that first pass.

By scroll-size I mean a single keyboard (up arrow, down arrow, etc.) scroll. Hard to know what to do if the user is scrolling with the mouse. If mouse movement is detected, start over with the hesitation and wait for mouse movement to cease.

After that I would start enhancing "scroll-sized" fields outward in a clockwise sequence around the centered field, all the time watching for a scroll request or mouse movement.

Other strategies might include priorities for fields at the perimeter of the image in case the user navigates straight to a corner (for instance). Perhaps separate threads with differing processor priorities would work, the thread enhancing fields around the centered field having precedent over the thread(s) working on the periphery.

I could flow-diagram this stuff, but know nothing of the math/convolution/bitblock transfers coding that would be required.

Perhaps it would be a benefit to assess how much processor was available for all of this. For instance, when installing XNView (or during startup) run a tiny "hidden" benchmark and store a value that would select from different enhancement strategies based on the result.

[Olivier_G]

- Calculate only the area that is really showed in the window.
- When moving/scrolling the area or resizing the window, calculate only the new parts.

I believe a bilinear resizing for just a 1280x1024 display area should be quite fast. Any update on this for the next version?

[VuDu]

I'm really looking foward for news in this area, because when you set the mouse wheel to zoom and by mistake you give it a couple of spins, if the go in the wrong direction (and by wrong I mean, making it Zoom In) the only way to stop XnView is Ctrl+Alt+Del'ing

[Guest]

I recently tried the programs Inzomia and Zoom Studio, and I found that I could execute smooth pans and zooms in real time. That is, the zooms are not stepwise, they are smooth, as with a movie camera. They were completely smooth on my old 733 MHz machine. My guess is the program is using features of the graphics card to achieve this effect. My graphics card is not at all new or fancy, but it had no trouble executing these effects.

So it is possible to achieve amazingly smooth zooms without overtaxing the CPU. Perhaps shifting these operations to the graphics card is the answer.

Anyway, I'd love to see similar smooth zooms and pans in XnView.

[pepemosca]

Here are my suggestions:
- Calculate only the area that is really showed in the window.
- When moving/scrolling the area or resizing the window, calculate only the new parts.
- You should be able to choose the calculation method for both 'Enlarge' and 'Reduce' (+Thumbnails) through drop lists [nearest neighbour, bilinear, bicubic, lanczos... with an additionnal sharpening factor - a commonly used option].

My vote to this suggestion

[moon47usaco]

I tend to work with LARGE images and i really love XnView... I will not use any other image viewer on Windows...

The slow drawing while using reduce in High Quality Zoom is my ONLY complaint with XnView...

And by large, the drawings i am currently working with today are 16800 x 12004 at 400x400 pixel per inch and a printing area of 42.00 x 30.01 inches...

With reduce on i can clearly see and make out any part of the drawing (architectural) but if i want to zoom i have to wait about 3 seconds per scroll wheel click... Rather slow when i am trying to thumb through architectural to determine a certain detail within the drawings...

This usually leads me to turning off the HQ zoom reduce but anything at or below 20% zoom becomes unreadable and in most cases i just can not make anything out without HQ zoom reduce on unless i am at about 50% zoom...

There are plenty of other image viewers that can handle the zooming and scaling but none offer the ease of use, browsing capabilities ,tabs are a common missing feature along with other browsing enhancements XnView offers, getting side tracked here... The point is that i love XnView and if it could handle the resizing/zooming of images in real time better there is just about nothing i could think of improving on...

I would have to go with passing calculations to the graphics card as well but i am no programmer and the little code i do know has nothing to do with graphic manipulation so good luck xnview... And thank you for the work so far... =]

and one thing there is many developers for ACDsee, for XnView i'm alone.
I'll try to make this request....

oh did i mention XnView is STILL free... =]

[xnview]

There are plenty of other image viewers that can handle the zooming and scaling but none offer the ease of use, browsing capabilities ,tabs are a common missing feature along with other browsing enhancements XnView offers, getting side tracked here... The point is that i love XnView and if it could handle the resizing/zooming of images in real time better there is just about nothing i could think of improving on...

Do you have some name of other software that handle zoom correctly?