Wrong image being shown in the Viewer

Dasym · July 19, 2017, 08:45:35 PM

The thumbnail shows an image but the viewer shows the image of the next file. These are .RAF files. This has happened once before with several files and was fixed when I chose Rebuild from the Cache dialogue. That isn't fixing it this time.

Has anyone any ideas on what causes this and how to fix it?

Jingo · July 19, 2017, 08:57:27 PM

Hi - I've had this exact same problem in the past but was not able to figure out the reason for it. A manual rescan of the files in the folder fixed the problem and I attributed it just to a bad import or something.. mine occurred for standard JPG images.. check this thread.. https://www.photools.com/community/index.php?topic=6527.msg45223#msg45223

Of course... thx to photobucket's new policy - all the image links are dead.. but the general issue is the same yours... the thumbnail does not match the preview image in the database.

Mario · July 20, 2017, 08:00:26 AM

Mhm. Is the wrong image also shown in the Quick View Panel and the Slide Show?

Select the file in the file window and then press <Shift>+<Ctrl>+<F5>. In the dialog choose "Force Update" and see if this solves the problem.

Dasym · July 20, 2017, 10:05:01 AM

Mario, yes wrong image is shown in both.

Force update makes no difference.

Mario · July 20, 2017, 10:22:37 AM

Set IMatch to debug logging (Help > Support). Restart IMatch.
Select the file and perform a forced update via Shift+Ctrl+F5 again.
Then attach the log file to your reply (Help > Support > Copy Log File).

I can then see which image IMatch is using to create the cache file.
Do you use the default "on-demand" cache settings under Edit > Preferences > Cache?

Dasym · July 20, 2017, 10:47:11 AM

I've sent the requested log file to your email address with a link to this thread.

Dasym · July 20, 2017, 08:40:02 PM

It's happening with another file now. This time a .dng created from the .RAF, but it's chosen a different image for the viewer.

Dasym · July 21, 2017, 01:08:27 PM

And happening with yet another file now. The two images were taken of the same scene 10 seconds apart. The thumbnails correctly show slightly different perspectives but the images in the viewer are identical.

It was happening with a fourth file and Force Update fixed it.

Mario · July 21, 2017, 02:27:07 PM

The log file looks normal. IMatch imports the file (2017-07-13_DSF4313.RAF) and also uses this file to create the cache.

But I notice in your screen shots that the files you are working with are master files. Do you perhaps have file version rules in place which make the wrong image a proxy image? This would explain why you see the wrong image in the Viewer. Toggle the display of proxy images (View the context menu in the Viewer or <T>,<X>) and see if this solves the problem.

Dasym · July 21, 2017, 02:43:23 PM

If I toggle the display of proxy images the viewer shows a different image, from another folder, but still the wrong image.

I unticked all (2) the Relations Definitions and refreshed relations, but the viewer still showed the same wrong images as before.

Mario · July 21, 2017, 03:21:07 PM

This is getting curioser and curioser...disabling the proxy shows yet another image? Where does this third image come from?

Please use the VarToy app in the App Panel with this variable:

{File.OID}

This shows you to the internal id of the focused file in the file window.
The corresponding cache image has a file name of the form OID.jpg.
If we can see in the log file which cache file is loaded, maybe there is a hint.

Restart IMatch.
Create a new folder.
Copy one "problem" file into it and add it to your IMatch database.
Take note of the id of this file (VarToy App).
Bring the file into the Viewer (since we have only one file, the Viewer only deals with this file, which makes the log easier to read. Attach the log.

I have no clue as of yet if IMatch is pulling the wrong cache image, or if your cache images are created from arbitrary files. Usually this is pretty straightforward; Load image with id nnn, save cache image under the name nnn.jpg.

Jingo · July 21, 2017, 04:14:55 PM

As mentioned in my other thread - I had the same issue but in my case - it was even more straightforward because a) the images were all JPG's b) no versioning was needed. Cache images existed on disk and the main image files also were good.. but the viewer and previews showed a different image when selected. A cache rebuild fixed the problem but I still don't know if there are other cached images which do not link to the correct GUID in the system.

Dasym · July 21, 2017, 04:44:29 PM

Requested log file sent by email - hope I've followed the instruction properly.

Oops, the id is 15063.

Dasym · July 21, 2017, 07:38:11 PM

Don't know if this is relevant, but I have Use this version set to As Visual and Version STack Visual for a Relation Definition. IMatch correctly generates the thumbnail for a master and the version stack based on the relation but doesn't do so for the image shown in the viewer - for any file, not just the ones showing the wrong image in the viewer.

Mario · July 21, 2017, 07:53:23 PM

The Viewer shows either the visual proxy or the original (master) image.

Dasym · July 21, 2017, 07:59:08 PM

If As Visual is set then even when viewing the master in the viewer it should show the visual proxy? It's not doing that.

Dasym · July 21, 2017, 08:49:10 PM

I've discovered that purging the cache doesn't delete all the cache files; the ones for the files that show the wrong image in the Viewer remain. If I manually delete these then the correct image is displayed in the Viewer when the cache images are re-generated. Could perhaps be a problem with Windows not deleting the files when requested to do so by IMatch? The cache files that were causing the problem needed administrator rights in order to be deleted manually.

There's still the problem with the visual proxy not showing the same as the thumbnail. Should I start a separate thread about that.

Mario · July 22, 2017, 09:28:23 AM

QuoteThe cache files that were causing the problem needed administrator rights in order to be deleted manually.

This sounds as if you have (and whatever point in time) used IMatch under an administrative account. And then Windows creates new files (cache files) with privileges that only allow an Admin to delete them. I did not anticipate that somebody would do this and there is no extended logging or reporting for this in the cache manager in IMatch. I will think about this.

The Viewer shows the proxy instead of the original image when enabled: See the context menu or press <T>,<X> to toggle the display of proxy images.

Dasym · July 22, 2017, 12:25:26 PM

Thanks Mario. Doesn't sound like it's something to worry about. At least if it happens again I'll know how to sort it.

Ah yes, the Viewer is working properly.

bonsai · July 23, 2017, 04:08:10 PM

Mario, are you still working on this?
I also ran into this problem, please see attached screenshot.
The first image has the thumb from the second (next) image, the second from the third, and the last has it's own.
Let me know if you need more information.

Mario · July 23, 2017, 06:23:20 PM

Please check the solution above: Check your proxy settings when you work with versioning. Also check your cache folders to identify images which require Admin privileges to delete.

bonsai · July 23, 2017, 07:13:36 PM

There is no proxy set. Cache for jpg is disabled.
I deleted present data in the cache folder and rebuilt the cache, no change, the thumbs stay wrong.

Mario · July 23, 2017, 07:18:51 PM

Thumbnails are stored in the database. The cache files are only used for the Viewer, Quick View Panel and the Slide Show.
You are working with versioning. The thumbnail is re-created when you force an update of the file using Shift+Ctrl+F5. Did you try that?

bonsai · July 23, 2017, 07:25:43 PM

Yes, without success.

Mario · July 23, 2017, 07:51:20 PM

So, lets recap: You force an update of a file but the thumbnail is wrong in IMatch?

bonsai · July 23, 2017, 08:00:29 PM

Yes, you can see it from the screenshot.

Mario · July 23, 2017, 08:16:57 PM

Does IMatch load the correct file into the Viewer? You can check at the bottom of the log file after you have opened the file in the Viewer.
Sure you are not using visual proxies? Try to press <T>,<X> in the Viewer to toggle proxy on/off.

bonsai · July 23, 2017, 08:37:41 PM

Please have a look at the screenshot. The image displayed in the viewer is correct, the thumb in the filmstrip at the bottom is wrong, it's from the next versioned image. Toggling the proxy doesn't do anything.

bonsai · July 23, 2017, 08:49:03 PM

Just in case it may help.
Here's a screenshot from the first image in this folder.
The image in the viewer is correct, the thumb in the filmstrip is from the second image which you can see in the screenshot before.

Mario · July 24, 2017, 09:00:17 AM

So: The thumbnail is only wrong in the Viewer? But on your other screen shot it looks correct. Is the thumbnail OK when you load only one image into the Viewer?

bonsai · July 24, 2017, 11:10:49 AM

No, it's also wrong in the file window (see SCR05)
Just one image in the viewer is wrong too (see SCR04)
It seems the thumbs are one step ahead...

Mario · July 24, 2017, 01:17:55 PM

Never heard about such a problem. Very mysterious...

Try this:

Close IMatch.
Make a new folder.
Copy only one of the problem images to it.
Restart IMatch and re-index the folder. No version rules should apply and the thumbnail should be correct.

bonsai · July 24, 2017, 04:49:51 PM

Now things have changed.
I removed the whole folder from IMatch, restarted and added the folder again.
Now it works as it should be.
I'm really sorry to bothered you, Mario

But the problem was existent, you saw the screenshots.
Anyway I'll be back if it's happen again...

Mario · July 24, 2017, 06:38:23 PM

I believe that you had this problem. But I have no clue where this came from...

Usually such strange issues are caused by 'forgotten' visual proxies which stuck. Or maybe the proxy settings where changed but the user did not re-apply the current settings to one or more folders.
If you experience the same in another folder, update the file relations for it <F4><R> and see if this solves the issue.