Speed of High quality zoom, more HQ zoom options?

Ask for help and post your question on how to use XnView Classic.

Moderators: XnTriq, xnview

BreakfastMan

Speed of High quality zoom, more HQ zoom options?

Post by BreakfastMan » Thu Jan 29, 2004 3:26 am

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.

User avatar
xnview
Author of XnView
Posts: 31737
Joined: Mon Oct 13, 2003 7:31 am
Location: France
Contact:

Re: Speed of High quality zoom, more HQ zoom options?

Post by xnview » Tue Feb 17, 2004 8:49 pm

BreakfastMan wrote:... 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.

User avatar
Olivier_G
XnThusiast
Posts: 1423
Joined: Thu Dec 23, 2004 7:17 pm
Location: Paris, France
Contact:

Any update ?

Post by Olivier_G » Tue Mar 29, 2005 11:54 pm

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: :mrgreen:

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...

User avatar
Dreamer
XnThusiast
Posts: 4605
Joined: Sun Jul 25, 2004 9:08 pm
Location: Slovakia

Re: Any update ?

Post by Dreamer » Wed Mar 30, 2005 11:00 pm

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 :)
Olivier_G wrote: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...

User avatar
Olivier_G
XnThusiast
Posts: 1423
Joined: Thu Dec 23, 2004 7:17 pm
Location: Paris, France
Contact:

Re: Any update ?

Post by Olivier_G » Wed Mar 30, 2005 11:53 pm

Dreamer wrote:
Olivier_G wrote: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 :P ).

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

Olivier

User avatar
Olivier_G
XnThusiast
Posts: 1423
Joined: Thu Dec 23, 2004 7:17 pm
Location: Paris, France
Contact:

Re: Any update ?

Post by Olivier_G » Sun Jul 03, 2005 8:14 am

Olivier_G wrote: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
Posts: 1
Joined: Tue Apr 04, 2006 12:38 pm
Location: Darmstadt

Post by X-Byte » Tue Apr 04, 2006 12:49 pm

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!
bye
X-Byte

User avatar
xnview
Author of XnView
Posts: 31737
Joined: Mon Oct 13, 2003 7:31 am
Location: France
Contact:

Post by xnview » Wed Apr 05, 2006 11:18 am

X-Byte wrote: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....
Pierre.

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

Post by JohnFredC » Wed Apr 05, 2006 4:25 pm

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.
John

User avatar
Olivier_G
XnThusiast
Posts: 1423
Joined: Thu Dec 23, 2004 7:17 pm
Location: Paris, France
Contact:

Re: Any update ?

Post by Olivier_G » Tue Jun 27, 2006 3:45 pm

Olivier_G wrote:- 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?
Olivier

User avatar
VuDu
Posts: 179
Joined: Sat Mar 20, 2004 8:27 pm
Location: Estarreja, Portugal

Post by VuDu » Thu Jun 29, 2006 9:04 am

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 :|
Image
Ad decus et ad libertatem nati sumus
Aut haec teneamus aut cum dignitate moriamur

Guest

Post by Guest » Mon Aug 27, 2007 9:53 pm

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.

User avatar
pepemosca
Posts: 31
Joined: Fri Oct 05, 2007 11:17 pm

Re: Any update ?

Post by pepemosca » Sun Nov 18, 2007 10:46 pm

Olivier_G wrote: 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 :)
XnView 1.91.6
Windows Vista Home Premium

moon47usaco
Posts: 2
Joined: Thu Jan 17, 2008 6:36 pm

Post by moon47usaco » Thu Jan 17, 2008 7:18 pm

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... =]

User avatar
xnview
Author of XnView
Posts: 31737
Joined: Mon Oct 13, 2003 7:31 am
Location: France
Contact:

Post by xnview » Thu Jan 17, 2008 8:23 pm

moon47usaco wrote: 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?
Pierre.

Post Reply