iMath 5.5 Viewer and QuickView

[ben]

Hi,

the new zoom capabilities are perfect for the quickview and the viewer. 
And it really feels much faster.

Regarding the viewer i'd like to give the following feedback:



• The filmstrip used to have the small green bubbles, which indicated which files have been preloaded. It seems they have vanished. I think they were a very good indication and should come back.
• The info "loading.." on black background with white font is quite disturbing for the eyes. I can see it pop up quite often for a few milliseconds when switching to the next image. I guess it's related to my RAM (only 4GB), so the images cannot always be preloaded. My database and all the pics are saved on a samsung ssd, though. I thinks there are several solutions, e.g. showing the info "loading..." only after 100ms...
• Depending on the zoom level, you can see aliasing (e.g. on a shirt with stripes) which is reduced when you zoom into the image.
  I think that was different in iMatch 5.4.x. Was there some kind of anti-aliasing functionality, that now has been removed or "passed to the graphics driver"?
  Maybe it's just a "feeling" but i got the impression, right after first opening imatch 5.5.4. I first realized it when using the quickview panel "fit to window" (the panel is always quite small in my layout). And it's the same with the viewer.

Ben

Ben

[Mario]

1. No longer needed or supported.

2. Feature Request.

3. IMatch uses the high-end aliasing technology implemented in your graphic card. Check the settings in your graphic driver and the documentation included by your graphic card vendor to see how various options affect options like anti-aliasing, aliasing samples, the used method, morphological filtering and all that.

[ben]

1) I disagree, i think it is quite usefull, e.g. when you don't have lot's of RAM like i do. It was a good visual indication
2) Ok, i will write a feature request, no problem.


3) Ok, this will become the tricky one.

Check the settings in your graphic driver and the documentation included by your graphic card vendor to see how various options affect options like anti-aliasing, aliasing samples, the used method, morphological filtering and all that.

I've got a DELL laptop which is not supported for Win7 any more (DELL dropped support right after i bought it, when Win7 was new -> great)
It has a built in ATI radeon hd 3400 grafic chip. I downloaded the newest "catalyst control center" which includes the last available driver.

But, it has only very few settings i can choose from. I tried all, but it makes no difference.
Which functions do you use, maybe i can search for that? Are these 2D or 3D operations, or does it not matter? I don't know too much about this topic.

Does this mean, if the few graphic settings have no effect, i am stuck with this?

Ben

[Mario]

1. The pre-loader in IMatch 5.5 works totally different. And it much faster. The typical load time for a 24 MP JPEG file is about one second - this means cache files as well. IMatch does not pre-load that many files, does not need to reload files again when you change zoom, performs color management at load time etc. Unless you have a very slow system or a system with awfully little RAM in combination with rather large images you would see the green dots light up within a few seconds and stay.

2. 4 GB RAM should be more than sufficient. IMatch automatically adapts and the images are held in the RAM on your graphic card, not the system memory. Unless you use a low-end on-board graphic card which has no own memory. The "Loading..." is only displayed when the image currently about to be viewed is actually still loading in the background. The typical reasons for this are:

1. You are switching between files faster than Windows/DirectX can load them. Usually it helps to wait two seconds and give the pre-loader a chance to catch up.
2. You jump back and forth in unpredictable ways., This causes a invalidation of the cache and forces it to reload files
3. Cache images are set to on-demand and don't exist. They then have to be created while you wait for the image to load. But that happens only once.

I will reduce the opacity of the text a bit, making it less bright for the 5.5.6.

3. IMatch uses Direct X or D2D to render your files on screen, at the best possible quality. I have no control over how the graphic card resamples pixel when you look at files at zoom ratios different than 1:1 - the graphic cards today use super-fancy algorithms for that which exceeds what I could do in software before.

[loweskid]

I downloaded the newest "catalyst control center" which includes the last available driver.

A bit off topic but just for your info - I installed the latest Catalyst Control Center a few weeks ago and then found Photoshop wouldn't open any files with Camera Raw Converter (just froze) and Nero Video wouldn't run at all - wouldn't even open the program.  Lots of complaints on the net.  I 'rolled back' to the previous version and all was well again.

[Mario]

I have one system with AMD Radeon graphic card (~80€, mid-range) and I don't have seen this effect. As usual, it depend on many factors. Unless you run the latest computer games, it's usually sufficient to install the "stable" catalyst versions and then don't touch them for months 

[ben]

I am stuck, don't know what else to try.
I think the image quality in the new quickviewer and viewer in my "normal iMatch layout" (laptop screen) are worse than with 5.4.x.

I attached two screenshots of the same test picture in the quickviewer.
One "fit to panel" and one "zoom 50%".
You can clearly see the "step pattern" (aliasing) of the black stripe. When zoomed to different levels it stays or dissappears.

My laptop graphics card is soldered onto the mainboard (ati radeon hd3400 mobility), so i cannot simply buy a new graphics card.
There are only very few settings in my ATI driver. Those that come close to image Quality (filter, aliasing) are only on the tab 3D. I have no idea if those should change the image quality for iMatch or not. I simply tried different combinations, with no effect.

Ben

[attachment deleted by admin]

[Mario]

The screen shots are quite small (I use a 4K monitor) and I can't tell much from them, sorry.
IMatch renders images via DirectX directly on the graphic card. There is nothing I can influence here.
IMatch loads the file, hands it over to the graphic card, creates a surface (aka window) for the graphic card to render on and then just tells the graphic card "display this image at this position and at this scale"). The graphic card then works its magic. Modern graphic cards have superior resampling algorithms implemented directly in their hardware, which makes them also very, very fast. I tested all the code with 30€ graphic cards up to high-end 600€ gamer cards, from 1300 pixel monitors (tablet) to 3840 pixel 4K monitors, from Windows 7 to Windows 10 monitors with superb results. My local tester group and selected IMatch users worked with prototypes of the new render engine and a test application for weeks, giving feedback and reporting issues. This was all really well tested before IMatch 5.5 was released.

Do you display original images (JPG) or RAW files, for which IMatch created cache images? Do you use the default cache settings in IMatch?
How do the images look at 100%?

[ben]

The screen shots are quite small (I use a 4K monitor) and I can't tell much from them, sorry.

I know, but that's how it looks like on a 15 inch laptop (not 4k)

My local tester group and selected IMatch users worked with prototypes of the new render engine and a test application for weeks, giving feedback and reporting issues. This was all really well tested before IMatch 5.5 was released.

I believe, you worked a very long time on this, before releasing it. I also think it's the right direction to move on with iMatch.
But at the moment it seems like, that some graphic chips don't have these fancy scaling algorithms and thus produce worse picture quality than the old iMatch functions.

I guess a new 30€ graphics card is still better than the onboard graphic solutions (not cpu internal solutions, they might even be worse).

Do you display original images (JPG) or RAW files, for which IMatch created cache images? Do you use the default cache settings in IMatch?
How do the images look at 100%?

I only use JPG Images as my camera produces them.
At least i think i never changed the cache settings. I attached a screenshot of the settings.
At 100% the images look like they should (too much of jpg compression though, but that's my camera's fault).

I uploaded another screenshot of the last image. This time taken in the viewer with "fit to panel".
The steps on the black stripe are still there, of course less dramatic.

So, this seems to me, that the new gpu rendering is great for new hardware. In terms of speed the new version is much better for me as well.
But in terms of picture quality, the old iMatch functions were much better on my hardware.


Is there any chance, both solutions could be combined?
Or maybe both solutions are part of iMatch and i can choose myself which one to use.


[attachment deleted by admin]

[Mario]

I use a 5 year old ATI card, and I can assure you that everything soldered on motherboards in the past two or three years is much better.

When you display an image at non 100% scales, the graphic card must remove pixels or invent them on-the-fly. Steps on hard contrast edges are caused by the interpolation algorithm implemented in the hardware and usually affected by anti-aliasing settings in the driver. IMatch does not attempt to set specific modes or anything. It uses the stock "high quality" settings when it starts up DirectX internally, because it's fast enough anyway. IMatch is no computer game and does not need 60 FPS. IMatch is not involved in sizing, interpolation, anti-aliasing. That's all done between the graphic card and DirectX. If you are not satisfied with how the images are interpolated by your graphic card, there is nothing I can do from my side. At least I cannot find anything in the docs.

[ben]

If you are not satisfied with how the images are interpolated by your graphic card, there is nothing I can do from my side. At least I cannot find anything in the docs.

Ok, i do understand the concept (graphic card + directx).

So, is there any chance, both solutions could be combined (old iMatch functions and the new ones)?
Or maybe both solutions are part of iMatch and i can choose myself which one to use.

[Mario]

IMatch will only render in hardware from now on. I have removed the old GDI code for good.
I cannot fetch the image from DirectX, apply some "blur" to soften whatever artifacts you see on hard contrast step edges and then push the image back. Or whatever you have in mind. Such operations are not supported or needed. What graphic card can do real good is to display, scale, resize, rotate and render pixels. And IMatch uses that.

Maybe hard contact edges in your files are exaggerated because of a previous too hard sharpening applied to the JPEG file, or compression artifacts which become exaggerated when DirectX scales the images.

[twe]

I think that was different in iMatch 5.4.x. Was there some kind of anti-aliasing functionality, that now has been removed or "passed to the graphics driver"?
Maybe it's just a "feeling" but i got the impression, right after first opening imatch 5.5.4. I first realized it when using the quickview panel "fit to window" (the panel is always quite small in my layout). And it's the same with the viewer. [/li]

I have Win10 and Imatch 5.5 and the display in Quick View and Viewer is definitely worse now. I also think it looks like there is no anti-aliasing anymore and photos appear very over-sharpened or with lots of jaggies. Especially low-light and  high iso images are really bad in Quick-Viewer. When I view the same jpegs in FastStone Image Viewer the images look much better, probably because of anti-aliasing. So the question is what does for example Faststone Image Viewer do different than Imatch ? Images look fine in Lightroom and FastStone...so I guess there must be something to be added og fixed in Imatch ?[/list]

[ben]

Maybe hard contact edges in your files are exaggerated because of a previous too hard sharpening applied to the JPEG file, or compression artifacts which become exaggerated when DirectX scales the images.

@Mario:
Can you please send me a sample jpg file, which contains some kind of chess patterns and stripes. So i can try if this problem is related to my own jpgs.
Can you also send me a screenshot of your ATI settings (catalys center). Do the options make any difference on your computer?


@twe:
Does it only happen in the quickviewer or also in the viewer?

[twe]

@twe:
Does it only happen in the quickviewer or also in the viewer?


It's the same in the Viewer. Good quality daylight images are ok in the viewer, but for low light high iso images...it's really bad (more noticeable). In Quick-Viewer, when scaled down to only a small window...every photo looks like sandpaper It must have something to do with ani-aliasing and resampling algorithm.

[Mario]

Send me a sample file which exhibits this problem.

[twe]

Send me a sample file which exhibits this problem.

Mail sent

[Mario]

I worked on this a bit over the past two days, using four different computers with different levels of hardware (small notebook, tablet, PC with ATI card, PC widh nVidea card) on Windows 7 with PU 1 and later....

Direct3D is a complex beast. You lookup how a function works, and it has 10 parameters. Most parameters are structures made from other parameters. These parameters have sets of possible values, each more or less well explained. Then then you start Google searches on what the meaning of the parameter is, how to use it, on which hardware it is supported and with which DirectX version etc.... 25 open browser windows, dozens of pages of text...

In short, it can be really confusing and hard to figure out

a) something that works,
b) also works on old Windows 7 PCs,
c) on all graphic cards, from on-board Intel low-end hardware to end-of-the-line nVidea and ATI cards
d) does not ruin performance

When I got the first post about this (in some other thread, a couple of days ago) I started looking into this. Problems with certain patterns when scaling, it has to be something with anti-aliasing. But not always, not with all images, not with all hardware.

I could repro the effect on one PC with one of my standard sharpness test images. And from there I worked back and found a workable solution.

The following image is a crop of a quite large file fit into a maybe 1000 x 1000 pixel window:



As you can see, it shows a lot of artifacts, caused by insufficient or 'wrong' anti-aliasing. The new mode produces this:



which is obviously a lot better.

[attachment deleted by admin]

[Mario]

I would have expected some comment on this...

[ben]

I would have expected some comment on this...

Hehe, i got interrupted using iMatch by my job and my young son. My boss somehow doesn't understand, that i need more time for working on my private pictures. 

Great news, i am glad you could reproduce this problem and also found a fix. Can't wait for to the next iMatch update.

I am curious about the technical details, do you mind sharing them?
Do these "new" directx parameters work as expected or is the result kind of random? Will you need different parameters for different hardware?
Is this new solution a trade off between compatibility and better performance?
Are there now more options that you might use in the future to improve the gpu handling even more?
Do the settings of your graphic cards have any influence on the picture quality?
...

Thanks for working on this problem 
Ben

[Mario]

It's basically learning more about DirectX (more than I ever wanted, I'm no game programmer), calling methods to figure out the capabilities of the graphic card, initializing the surfaces according to what was found out, changed aliasing parameters etc. A lot of digging via Google, developer forums etc.

DirectX is a very complicated technology. Game programmers are specialists, and among these are even more specialized people who create the DirectX code. And when you read that some games require you to have one of a set of maybe six graphic cards or else the game will not run (or lousy) you can figure that a lot of this stuff is very hardware dependent. And poor Mario only digs into this to give his users a better and faster view performance. The results are definitely worth it, but I had to spend a lot more time than anticipated to make it work

My aim was to make IMatch 5.5. work on Windows 7 with platform update 1 and later. So I use only basic functions, skipping some of the cool stuff that was introduced in W8, 8.1 or W10. I will get back to that later, after W7 has phased out.

The current IMatch render engine is as good as it gets. On oven moderate GPUs you have smooth zooms (I really dig the <Alt>+left-click + mouse zoom in IMatch 5.5), super-fast pans and now (hopefully) across the board and hardware superior anti-aliasing on all zoom levels. Always improving. And then people complain about upgrade cost 

[ben]

Hehe, i got interrupted using iMatch by my job and my young son.

Actually I thought that was quite funny... 

My aim was to make IMatch 5.5. work on Windows 7 with platform update 1 and later. So I use only basic functions, skipping some of the cool stuff that was introduced in W8, 8.1 or W10. I will get back to that later, after W7 has phased out.

Let us know, when we have to upgrade to W10.
Fancy stuff is always welcome.

And then people complain about upgrade cost

Yeah, i totally understand both sides.
Personally, i know i pay for the fast update and bugfix release cycles and of course the forum help.

Waiting for 5.5.8 

[Mees Dekker]

The new pictures look much better than the old. It would make a huge improvement and bring us back up to the old standard of 5.4.18

Can't wait for this to be released.

[twe]

Very nice release today ! Image display is great, and problem is solved. Thanks for a fast fix and quick release.

[ben]

v5.5.8
Much better 

[Mees Dekker]

Same here: viewer is much, much better. Many thanks to Mario for fixing this.

Although I did not take any time-measuring, the viewer also feels much faster and responsive now. It was not bad, but it is even better now. Could this be a side-effect of this anti-aliasing action?

[Mario]

Although I did not take any time-measuring, the viewer also feels much faster and responsive now. It was not bad, but it is even better now. Could this be a side-effect of this anti-aliasing action?

Interesting. Actually the additional efforts for the better anti-aliasing should slow down the rendering bit. But since this runs in hardware, it's unnoticeable. Load speed or similar are not affected. That it feels faster must have another reason. Or maybe your graphic card is more happy with the new options - which can be - DirectX and graphic hardware are notorious for such effects.

[markkums]

The following image is a crop of a quite large file fit into a maybe 1000 x 1000 pixel window:



As you can see, it shows a lot of artifacts, caused by insufficient or 'wrong' anti-aliasing. The new mode produces this:



which is obviously a lot better.

Hi,

I am curious about those sample images that I can see (Image1 and Image2). What I can see is that in Image1 there are some structures in small (numbered) areas. But in Image2 these areas are grey, no structure at all. Is this  what I can see only in my own system or are those areas in Image1 artifacts or is there less contrast and resolution in Image2?

B.r: Markku

[Mario]

These are artifacts in image 1, caused by the non-optimal or even disabled anti-aliasing on some graphic adapters. I explicitly use this kind of test image to test for and reveal such issues. This problem has been fixed in the current version of IMatch 5.5, which now uses proper adaptive sub-sampling across all graphic cards supporting DirectX (W7 with platform update 1 and later versions).

[supam.viennot]

Still sad not to get the green dots on the Film Strip.

The loading speed of pictures does depend on processes that are not visible to users. The presence of the green dots did help. When a picture did not load instantly, we had the impression to know why. Also, whenever we had the option to start looking at similar pictures, we always had the possibility to start with the ones that had the green dot. We are now exposed to a frustration  that is of course not random but appears random to users...

Please please please, give it back to us...

[Mario]

Please attach a log file.
The typical load time for an image is less than one second, and the green dots would light up very quickly.
Adding the green dots would be a lot of effort. I have no plans to touch all this code, which seems to run very smooth.

[supam.viennot]

Mario,
here is the log file. To focus its content, I did nothing but open the base, launch viewer and start browsing.

I use the viewer with 4 or 8 files layout.

Overall and regardless of the green dot, fluidity seems to have gone down significantly compared to versions before 5.5. I used to navigate without any lag. I now have to wait sometimes several seconds before the file I am looking for opens. It seems Imatch has to reopen each of the other 7 files present when I just want the next one.
Also, it randomly states that some files cannot be read but will actually display the file when when I just browse to the next.

Fluidity in navigation was outstanding in previous version and one of my key criteria in being a fan of IMatch. I would love to help back in that direction.

32gb memory, i7 5820K, GTX970

[attachment deleted by admin]

[supam.viennot]

I forgot to add : database on SSD500Gb and photos on raid1 with modern 7200 disks

[Mario]

Caching an image on your system takes between 0.3 and almost 3 seconds.
Search the log for ] CIMCacheManager::CreateCacheImage to see the times for your various files, and which files are slow and which are fast.

IMatch always loads multiple images in the background and this cannot be aborted. If you navigate faster than IMatch can load the files, you will have to wait until another "load slot" becomes available and IMatch can load the missing file.

No changes were done to this between the 5.5.x and the 5.6 releases so there should be no difference.

[supam.viennot]

Indeed, I have seen no behavior change between 5.5 and 5.6 although I was kind of hoping for it. The behavior change happened between 5.3 and 5.5. I have started to analyse it better and, because it actually has nothing to do with green dots or loading time, posted it separately.

[Mario]

5.3 used a software-based rendering.
One of the major improvements in IMatch 5.5 the new super-fast hardware-based rendering using DirectX.

[supam.viennot]

Sure. NO question about the fantastic rendering of 5.5.

The viewer yet remains much much slower overall than 5.3. Some of it is absolutely instaneous. Some of it newly very slow. I believe this is linked to the way preloading works.

Cordialement
Ph

[jch2103]

Sure. NO question about the fantastic rendering of 5.5.

The viewer yet remains much much slower overall than 5.3. Some of it is absolutely instaneous. Some of it newly very slow. I believe this is linked to the way preloading works.

I expect performance depends on hardware/software systems being used, but in my case the Viewer is much faster in 5.5 (5.6) than it was in 5.3, although I don't have any benchmarks to prove it. It's even very quick with ~66 MB scanned files or 24 megapixel NEF files. I have to hit the right cursor key very fast for quite a while before I (briefly) see  "loading...". However, I did upgrade to a GeForce 950 video card in October, which I'm sure makes a significant difference!

[supam.viennot]

Thanks John. You are bringing hope here. I have a 970 that should be good enough too.
If you load 66Mb files that fast, then not only your graphic card is involved but also your hard drives,preloading, and maybe other features as well. In my case, viewer is easily brought to very unconvenient limits.  I have just tried with files on a SSD and it remains similarly slow... I run a modern computer with 32Gb memory, i7 5820K, 970 graphic and SSD. How can the viewer it be that slow???
Any idea?

[supam.viennot]

One more question : what happens if you hit the right arrow 20 times real fast. Do you, as I do, get a "loading" messages for seconds and then get such messagez again and again if you trying moving left or right?

[jch2103]

There's a significant difference between my desktop (i7-3770K, 16 GB, 256 GB Samsung 830 SSD, 2 TB WD HD, GeForce 950) and my Sony Vaio Z1 laptop (~5 years old, i5, integrated Intel GPU, 8GB, 256Gb SSD). I described the desktop above; I have to press the cursor pretty fast (multiple times per  second) to get the 'loading...' message (24 megapixel NEF & JPG images) and it goes away in less than a second (no stopwatch, though). The laptop shows the 'loading...' message much sooner (all NEF, same image size), e.g., one cursor press per second will start to show the message briefly after ~10 keystrokes. (See attached log file for individual image load times from the cache, e.g., 'CIMDXWnd::LoadFile'.)

So performance definitely varies depending on hardware.


[attachment deleted by admin]

[Mario]

So performance definitely varies depending on hardware.

Naturally. IMatch cannot display files faster than Windows WIC can load them.

IMatch loads images in advance, guessing which files will be needed from the direction in which the user changes the focused file in the file window (Quick Preview Panel) or the Viewer. IMatch loads several files simultaneously, so the performance also depends on how many processors are available. The performance also depends on the file format, the dimensions of the images, whether or not IMatch also needs to create a cache file, how fast color management can be performed (depends on CPU speed and Windows version) etc.

If you don't move around in the Viewer faster than IMatch can load files, you will never see "Loading...". If you try to force it, 'jump' around a lot or you use older hardware, you will see "Loading..." much more often. IMatch may need a few seconds to catch up, and it will have toi wait until other images currently being processed are completed until it can start loading a new file.

[supam.viennot]

Well, all this is understood. However, 5.3 did cope with whatever slower processes of the system in a way that made them much less visible/painful to me. Imatch was bringing an improvement on picture availability compared to WIC. I understand 5.6 does not anymore or at least in a reduced way. It loads faster but much less in advance. This is especially sensitive on 4 or 8 pictures layout in the Viewer.

If there is not something I can tune in my current Imatch 5.6, I will revert to 5.3  . Before I do so, I would be happy to further contribute with some tests if there is any interest at all. As a minimum, I will post performances when I am back in 5.3. This will help understand if there is any recent hardware issue on my side .

Thanks for the direct and rapid support anyway

Ph

[Mario]

Reverting back to 5.3 is nonsense.
5.4.18 is a much better version and does also use the slow software-based rendering, which seems to be faster than hardware-based rendering on your machine. But apparently on your machine only.

I've invested a lot of time to make IMatch 5.5 use modern hardware-based image rendering. And to implement a much faster pre-loading and ICC managemend.
I'm not sure yet why this can be slower on your computer than the software-only approach in IMatch 5.4 - my tests show that not only IMatch loads JPEG files much faster (from the original file or the cache using the installed WIC codec, but also performs color-management in about 10% of the time used in earlier versions). And of course you get the immediate dive-zoom, smooth zoom between 10% and 800% etc.

Do you also experience these problems when you use the Viewer in the "one file" layout (showing only one file at once)?
Because when you use 4 or 8 images, IMatch not only has to load all these images, but may run out of memory and thus cannot pre-load much - because all the memory is needed to keep the images you currently see in memory. And when you then navigate, IMatch has to remove one or more files from memory to make room for the next files.And since it cannot preload, it will show the "Loading..." message and load the file while you wait.

In your log file, IMatch maxes out the memory it can use at a whooping 2.8 GB. This means that there is probably not enough memory for it to preload - you're maxing it out.
IMatch 5.5 always loads full-size images so it is much faster for dive-zoom but needs more memory. Depending on the available RAM, the size of the database etc. it may not be possible to pre-load files when you display 4 or 8 images at once in the Viewer.

[supam.viennot]

Implemented 5.4.18 today and let it reconstruct the database fully.

I have just ran some quick test with same pictures as with 5.6. This older 5.4 versoin is much much faster in my case. I hardly can trick the preloading at all and navigate with fluidity as I used to. Not only does each individual loading happen much faster (fractions of seconds compared to seconds in 5.6) but also the prelaoding soon sends green dots everywhere. Log file attached.

Viewer in single file display mode
I did experience problems with a single file in the 5.6 viewer. Two things happen : 1) I do get the "loading message" anytime I try to load an image that is more than 10 pictures away and it may stay for seconds 2) I randomly get a "cannot read this file" and no picture at all. This also happens in other layouts (eg 4 pictures). When moving to the next picture, the one that could previously not be read suddenly appears on the screen.

Memory
There is no reason I can understand that would limit memory available to IMatch to 2.8Gb. I have 32Gb on my computer, nothing else is running + the performance monitor does show most of it not being used. IMatch could use some 27Gb more if it wanted to.

As you understand, I have now the 5.4 running. I am satisfied with it. I am yet happy to run a new instal of 5.6 and run any test that you think could be useful to help.

[attachment deleted by admin]

[supam.viennot]

btw, the quick viewer is also faster on my 5.4 than on 5.6.

[Mario]

There is no reason I can understand that would limit memory available to IMatch to 2.8Gb. I

IMatch is a 32-bit application and can use up to 3.5 GB.

The problems you're facing are not caused by the RAM IMatch allocates, it's the RAM IMatch needs to allocate on your graphic card.

When you jump 10 images, you are breaking out of the preload sequence. IMatch then has to remove already loaded files, and start loading with the image you have been moved to. This is the worst case. If you regularly work that way, try using the Quick View Panel.

But since you reverted to the old 5.4 version with slow software rendering all this is futile. Let me know when you're back on the 5.6 track again and then we can continue to look into your problem.

[supam.viennot]

understood (mostly). I am interested by the side by side comparison that I find in the Viewer and not the quick view panel. Anyway, the quick view is faster in 5.4 for me.

I ll stay with the 5.4 version that is actually my fastest in every use and wait for future versions to catch up in effective overall/perceived speed for my own usage. I am sure that will come.

Ph

btw, No regrets for my 5.6 license although I am in the end staying with the older version, I know I am funding continued and continous support and glad to do so.

[StanRohrer]

Would cache settings make a difference for the slow viewer issues?

[Mario]

Would cache settings make a difference for the slow viewer issues?

No.

IMatch 5.5+ loads the file in 100% size (whatever 100% means for your cache settings), manages colors and then hands over the image to the graphic card (GPU). The graphic card then can render. and zoom the images very, very fast.

IMatch pre-loads images in the background (how many depends on how many files are displayed at once the Viewer, how large the files are, how quickly the graphic card memory fills up etc). IMatch pre-loads in the direction of the last 'move', só if you move 'to the right' in the Viewer (or the file window, for the Quick View Panel) IMatch pre-loads files in that direction, else in the other direction.

Under normal conditions and a fairly capable graphic card, this means you can navigate very fast in the Viewer, with image-to-image step times less than 0.1 seconds.

If you jump over larger distances (e.g. you click on a file 10 files away from the last file you have viewed) you access a file which has not been pre-loaded. In that case, IMatch has to stop pre-loading, readjust to the new position and start loading the image you just clicked (and some of the next images). If IMatch needs, say, 1-3 seconds to load the image, color-manage it and move it to the graphic card, you will have to wait 1-4 seconds in that case before the image can be displayed. The next images will be fast again, because loads them while you still look at the image you clicked. Unless you scroll faster than IMatch can pre-load the files, navigation is smooth again.