Read one image backward (reverse pre-cache)

Ideas for improvements and requests for new features in XnView Classic

Moderators: XnTriq, helmut, xnview

User avatar
Clo
XnThusiast
Posts: 4441
Joined: Sun Oct 17, 2004 4:57 am
Location: Bordeaux, France
Contact:

Often !

Post by Clo »

:arrow: ccollomb

:) Hello !
…Joke apart I have no idea how often XnView is released…
• Here, for the year 2008 only, I've 28 versions archives folders (among which one for all MP versions).
- So, roughly once every fortnight in the average…

:mrgreen: Kind regards,
Claude
Clo
Old user ON SELECTIVE STRIKE till further notice
ccollomb
Posts: 6
Joined: Sat Dec 27, 2008 8:48 pm
Location: San Francisco

Post by ccollomb »

Super! Merci!

Proves that I was right to be patient :) Ca prouve que j'ai eu raison de ne pas etre impatient! :)
User avatar
helmut
Posts: 8705
Joined: Sun Oct 12, 2003 6:47 pm
Location: Frankfurt, Germany

Post by helmut »

@ccollomb:
Welcome to the forum and congratulations to your daughter, Cedrick! And thank you for registering, now the "child" has a name. ;-)
User avatar
XnTriq
Moderator & Librarian
Posts: 6336
Joined: Sun Sep 25, 2005 3:00 am
Location: Ref Desk

Post by XnTriq »

ccollomb wrote:Apologies about that, I did not bother registering. It is done now :)
Welcome!
ccollomb wrote:I am busy enough with my new born :)
Congratulations!
ccollomb wrote:Have a great holiday! :)
Happy Holidays!
User avatar
xnview
Author of XnView
Posts: 43326
Joined: Mon Oct 13, 2003 7:31 am
Location: France
Contact:

Re: Backward caching is the only XnView weakpoint

Post by xnview »

Olivier_G wrote: So, to make a quick and simple system:
- XnView should notice in which direction the user is moving (forward or backward. For a new selection, use forward as default).
- If going forward, XnView should cache 'next' image, and then 'previous' image.
- If going backward, XnView should cache 'previous' image, and then 'next' image.
(of course, when you move, you only have to cache 1 image, as the other 2 are already in memory)
Right, 'read ahead' must load next (forward) or previous (backward)
Pierre.
User avatar
Olivier_G
XnThusiast
Posts: 1423
Joined: Thu Dec 23, 2004 7:17 pm
Location: Paris, France
Contact:

Re: Backward caching is the only XnView weakpoint

Post by Olivier_G »

xnview wrote:Right, 'read ahead' must load next (forward) or previous (backward)
Cache both, Pierre: there are already many threads asking for that.
(you just have to know which one to cache first based on current direction)
Olivier
User avatar
xnview
Author of XnView
Posts: 43326
Joined: Mon Oct 13, 2003 7:31 am
Location: France
Contact:

Re: Backward caching is the only XnView weakpoint

Post by xnview »

Olivier_G wrote:
xnview wrote:Right, 'read ahead' must load next (forward) or previous (backward)
Cache both, Pierre: there are already many threads asking for that.
(you just have to know which one to cache first based on current direction)
Yes, sorry :-)
Pierre.
ccollomb
Posts: 6
Joined: Sat Dec 27, 2008 8:48 pm
Location: San Francisco

Glad to see things are moving forward (no pun intended) :D

Post by ccollomb »

Example use case.

I have image0.jpg, image1.jpg and image2.jpg in my folder, they are very big and take very long to load (10s for example). The first image that I open is image2.jpg, this is the last picture in the folder. I look at it for t > 10s. Now I want to see image1.jpg which is the one just before. Hitting previous loads the image, shows the progress bar and takes around 10s. Whereas ideally this one picture should have been cached before I hit the previous button.

Thinking about it you seem to have a linear array of names in your code, so if the index of current is i, you need to preload i-1 and i+1. My first message suggested to chose the preload order depending on the viewing direction, I think it is even easier than that now.

Basically you keep 3 images: previous, current, next.

If you move backward: next = current, current = previous, previous = Preload( current - 1 )
If you move forward: previous = current, current = next, next = Preload( next + 1 )

The only case when you need to preload both is when you open a picture for the first time without moving progressively, at this stage appart from being at the first or last image, the chance of right predictions are difficult so loading next first and previous after seems reasonable (although you could over engineer it with a user pattern usage analysis but really I am NOT asking for that :)

Of course you will need to handle the edge cases, but hope that it makes it more clear. In short it should be even easier and quicker to implement and fix, especially when your code already seem to work on a similar pattern (except the weird handling of keeping the current one in cache) :)

Hope this helps,

Cedrick
bugmenot
Posts: 69
Joined: Sun Sep 16, 2007 10:29 pm

Post by bugmenot »

actually for purpose of comparing 3 files, you need to keep 5 files in memory

Files: 1 2 3 4 5

You are compoaring 2,3,4
but preload will get 5 when you see 4, and 1 for 2
which makes it impossible to compare 2,3,4 w/o files loading.

So pls keep the 'last 3 files read' in addition to
preload files
User avatar
Olivier_G
XnThusiast
Posts: 1423
Joined: Thu Dec 23, 2004 7:17 pm
Location: Paris, France
Contact:

Post by Olivier_G »

bugmenot wrote:actually for purpose of comparing 3 files
Why do you want to especially compare 3 files... and not 4... or even 42?

I think the default behaviour should be what has been described so far (ie: 3 files in cache) and should be implemented as soon as possible.

The depth level of cache (ie: compare 3, 4, ... 42) should be discussed for later implementation, IMHO.
Olivier
thibaud
Posts: 274
Joined: Sat Dec 02, 2006 12:41 am
Contact:

Post by thibaud »

I think the default behaviour should be what has been described so far (ie: 3 files in cache) and should be implemented as soon as possible.
Yes. just like the low-res instant preview. which I believe is tightly related to the cache mechanism.
ccollomb
Posts: 6
Joined: Sat Dec 27, 2008 8:48 pm
Location: San Francisco

Keep it simple

Post by ccollomb »

> I think the default behaviour should be what has been described so far (ie: 3 files in cache) and should be implemented as soon as possible.

Agreed, I would qualify this of being a priority P0. This is really the last area where XnView is behind AcdSee or FastStone. With this fixed, there is really no reason for most people not to switch to XnView. In my case I borderline went to FastStone just because of that, and I know some people are using the old AcdSee just because of that.

> The depth level of cache (ie: compare 3, 4, ... 42) should be discussed for later implementation, IMHO.

Agreed as well, this need to be discussed much more in depth, I am not clear with what bugmenot actually wants, it seems he wants more retention in memory which has pros and cons obviously so it will generate a lot of options and will quickly become complex. Not that it is not important but for me it is a priority P2.

Let's not over engineer it for the moment, keep it simple and get the biggest bang for the buck which is simple previous preload.

PS: I am not the one who made the last bugmenot post, even though I previously posted in this thread under that login name
User avatar
xnview
Author of XnView
Posts: 43326
Joined: Mon Oct 13, 2003 7:31 am
Location: France
Contact:

Re: Keep it simple

Post by xnview »

Please try XnView 1.96 beta
Pierre.
obelisk
Posts: 464
Joined: Fri Jan 09, 2009 9:54 am

Post by obelisk »

Olivier_G wrote:
bugmenot wrote:actually for purpose of comparing 3 files
Why do you want to especially compare 3 files... and not 4... or even 42?

I think the default behaviour should be what has been described so far (ie: 3 files in cache) and should be implemented as soon as possible.

The depth level of cache (ie: compare 3, 4, ... 42) should be discussed for later implementation, IMHO.
as said above, with 3 files in cache you only ever use 2 of them. Once you move forward you lose the last one.

why compare 3 files? Ask nikon why they implemented compare 3 files in their software? Because photographers need to compare files quickly and delete the worse of them. This takes 3 files quickly read. If you use RAW files you'll know how slow they load. Sometimes I have 10 frames that look exactly the same, only switching quickly at 80-100% do you see which you can delete.

If you think 3 is arbitrary, so is 2. With the same argument, may as well say cache only current the forward then. Why do you want to move backwards and not wait for it to load? You can't just expand everything to 4,..42 then because 42 is stupid then automatically 3 is stupid.
User avatar
Olivier_G
XnThusiast
Posts: 1423
Joined: Thu Dec 23, 2004 7:17 pm
Location: Paris, France
Contact:

Post by Olivier_G »

The subject of this thread, and the most important by far, is to properly cache images for simple navigation (ie: immediately show the picture when you press the navigation key). The new version deals about that: thank you, Pierre! :P.

I have thousands of pictures from my travels, sometime in series, and know that comparing 2, 3 or more pictures is useful.
Two is handled through the current cache system. To compare more files, you can open those, instead of navigating back and forth.

I agree that a more elaborated cache system would be interesting. But it needs to be discussed further in a separate thread: we already have an issue about the depth; we could add other parameters: amount of memory, direction, managing all open windows or not, etc...

So, this is a different subject that needs more discussion in a separate thread, and it shouldn't be implemented in 1.96, IMO.
Olivier
Post Reply