XnView Software

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…

Kind regards,
Claude
Clo

Super! Merci!

Proves that I was right to be patient Ca prouve que j'ai eu raison de ne pas etre impatient!

@ccollomb:
Welcome to the forum and congratulations to your daughter, Cedrick! And thank you for registering, now the "child" has a name.

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!

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)

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

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

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

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.

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.

> 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

Please try XnView 1.96 beta

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.

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

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.