IMatch 2023 - IM Autotagger film strip?

[ubacher]

I could not establish a pattern between jpgs that show and those that don't. I send 3 jpgs of each
zipped to support.

(the pdf and psd files I tried showed OK!)

[Mario]

@ubacher: Thanks for sending the files.

Note: See the end of this post for a possible solution. You can ignore the details and just follow the instructions to install some patches.


I've tested them on my development system, and all six files (from the show/no show folders) show in AutoTagger.

I then created a new Windows installation in a VM and installed 2023.1.14.
Created a new database and added the folder with your images.
Selected all 6 files and started the AutoTagger. And NO files were shown. Yesss...

Opened my web browser to run AutoTagger and to see what's going on.
All images showed :-(

Closed the browser and repeated the test in IMatch AutoTagger. All images showed.

Closed IMatch. Cleared the browser cache. Reopened IMatch and ran AutoTagger for the 6 files. All images showed.

So I reset Windows again and install IMatch again and create a database again and add the 6 files.
This time I've connected the debugger to IMatch before launching AutoTagger.
And then configured the IMatch AI and clicked on "Lookup and Review...".
Again, no thumbnails were showing! Yesss...

Looking at the console revealed no errors. Neither in the network tab.
Looking at the generated source code showed that instead of thumbnails, the film strip had loaded SVG files, which are used as placeholders when there is no thumbnail for a file (IMWS did not deliver one).
But that made no sense. The correct image was requested according to the image URL. So why the placeholders?
At this time, I still have no clue.

@the two affected users

Can you open the settings in the Auto Tagger (Gear Icon in the toolbar) and then enable the expert mode and enable the "square thumbnails" option and save the changes by clicking OK.

Does that make a difference?
If so, disable the option again. Images still showing?

Update

20 Windows restores / re-installs / re-runs later...

I think this is a timing issue...?!

The film strip loads images on-demand, when they are needed / are scrolled into view.
It is designed to handle hundreds or thousands of images, so this on-demand is paramount for performance.

In the one situation (AutoTagger running for the first time after a fresh IMatch installation on a clean Windows 11) I noticed in the browser that the images in the film strip existed as HTML code, and all used the correct src="" attribute which fetches the actual image from IMatch.

But the image was not loaded (no thumbnail) and neither the placeholder. There were no requests sent to IMWS in IMatch to deliver the images.

I then tracked that down to the on-demand mechanism. Which was under the assumption that none of the images were currently in the view (no intersection). And this lead me to the thought that, maybe, this is a timing issue and the HTML has not been rendered completely by the browser, causing the film strip to have a width/height of 0 and hence, no image is visible by default. Or something like this.

So I made a code change. Restored Windows. Reinstalled IMatch. Applied the code change to the AutoTagger. Ran it and - no images :-(

Made other changes, same steps, and finally, images are shown. YAY!!


@ the affected users, please test this:

Close IMatch.

1. download the attached ZIP file and extract the contained files.
2. Copy the files to "c:\ProgramData\photools.com\IMatch6\webroot\system\ptc-vue\fw", replacing the existing files.
3. Delete this folder: "V:\develop\IMatch5\ProgramData\photools.com\IMatch6\browser"

Retry AutoTagger.

[jch2103]

1.  Looking at the generated source code showed that instead of thumbnails, the film strip had loaded SVG files, which are used as placeholders when there is no thumbnail for a file (IMWS did not deliver one).

But that made no sense. The correct image was requested according to the image URL. So why the placeholders?
At this time, I still have no clue.


2. Can you open the settings in the Auto Tagger (Gear Icon in the toolbar) and then enable the expert mode and enable the "square thumbnails" option and save the changes by clicking OK.

Does that make a difference?
If so, disable the option again. Images still showing?


3. @ the affected users, please test this:
Close IMatch.
1. download the attached ZIP file and extract the contained files.
2. Copy the files to "c:\ProgramData\photools.com\IMatch6\webroot\system\ptc-vue\fw", replacing the existing files.
3. Delete this folder: "V:\develop\IMatch5\ProgramData\photools.com\IMatch6\browser"
Retry AutoTagger.

Thank you for looking into this, Mario, and your exhaustive digging/testing!!

Unfortunately, my issue continues (e.g., my 'developed' JPG images don't appear in the Autotagger filmstrip).

Re #1 above: Very interesting! At least that points to something specific going awry.

Re #2 above: Setting Expert mode and changing to Square thumbnails didn't change anything. This is true whether Autotagger is run in a browser window or not.

Re #3 above: I tried this with some new images after running the above steps: NEF appeared in filmstrip but not the 'developed' JPG. I then tried shooting a sample NEF+JPG Fine (set in the camera image quality menu setting); same thing happened.  Oddly, changing the camera menu to JPG Fine (only) yields JPG images that do appear in the filmstrip. Here's a link to these two JPGs https://1drv.ms/u/s!AtlBwiIf8wQzgZc6jjGdxjdnbOCYfg?e=CeUJru although I suspect you won't see a difference (there are some minor metadata differences due to the fact that the JPG-only image was in shutter priority while the NEF+JPG JPG was in aperture priority.)

To add to the puzzle, JPG images from my phone do show up properly in the Autotagger filmstrip.

EDIT: Based on Mario's suspicion of a timing issue, I copied the two JPGs referenced above plus another 'processed' JPG into a new folder with no NEFs or other files present (these were the same JPGs that didn't show up in the filmstrip as described above).

Result: All three JPG images appear in the filmstrip!! I then copied the NEF that was part of the NEF+JPG pair reference above; result: the JPG part of the 'pair' no longer appears in the filmstrip but the NEF does...(??) And when I copied the NEF of the 'processed' JPG from another image already in the folder, the corresponding JPG not longer appeared in the filmstrip... (If it matters, the NEF/JPG pairs have the same name except that the JPGs have '_DxO' appended to the name.)

Preliminary conclusion: If a NEF/JPG pair is in the same folder, only the JPG appears in the Autotagger filmstrip (at least on my computer - I always keep the NEF & JPG pairs in the same folder, unlike some other users). This relationship holds up as I add more images to my test folder... Perhaps this helps diagnose the issue?

[jch2103]

Here's a link to some of the NEF/JPG pairs and a standalone JPG from my above post: https://1drv.ms/u/s!AtlBwiIf8wQzgZc7VkGwST2oaS82ZQ?e=Ild0dt

[Mario]

Preliminary conclusion: If a NEF/JPG pair is in the same folder, only the JPG appears in the Autotagger filmstrip (at least on my computer - I always keep the NEF & JPG pairs in the same folder, unlike some other users). This relationship holds up as I add more images to my test folder... Perhaps this helps diagnose the issue?

I assume you are using versioning for the NEF/JPG and the JPEG is a visual proxy and buddy file?

[thrinn]

Preliminary conclusion: If a NEF/JPG pair is in the same folder, only the JPG appears in the Autotagger filmstrip (at least on my computer - I always keep the NEF & JPG pairs in the same folder, unlike some other users). This relationship holds up as I add more images to my test folder... Perhaps this helps diagnose the issue?

But you are sure that there is no File Relation rule / Visual Proxy coming into play here? I tested the two JPGs you provided via OneDrive in my DB, but they show up properly. Of course, I do not have the NEFs.

[Mario]

Found it!
Replace the file

"C:\ProgramData\photools.com\IMatch6\webroot\imatch\apps\auto-tagger\src\app.js"

with the "app.js" from the attached ZIP.
After opening the AutoTagger, click into it and press <Ctrl>+<F5> a few times to force a reload.
If this does not help, close IMatch and delete the cache folder as explained above.

The problem was caused by an existing version stack and the way AutoTagger initialized the File Window.
Stacked files were hidden, which makes no sense in this context.

[ubacher]

This fixed it! Hurray!

[thrinn]

This bug was really a heavy one!

[Mario]

This bug was really a heavy one!

The bug was fixed in 5 minutes, after I could reproduce it reliably.
That's always the tricky part.

I still think there was also a timing issue, since I could repro it once on a fresh Windows and with a fresh IMatch install for a folder without any versions.

[jch2103]

Fabulous! That fixed it. Great detective work! Many thanks.

[Mario]

Good result. Tricky to figure out.
But that one would have affected many more users over time, so I'm happy to have it fixed.
Should've found this easier, my brain is just a bit mushy after the past two weeks

Another bug bites the dust
(To the melody of another one bits the dust by Queen)