[NR] Wrong positioning in the Viewer after deleting ALL picture in the set

mastodon · November 19, 2022, 06:05:47 PM

I have a found a strange feature in the Viewer. I am using the Viewer for culling, so I delete pictures there. Sometimes I only choose just a set of pictures to compare them. I found, if I delete even the last one in that set, after that IMatch get back to the first picture in the selection. eg. if I start from the Timeline, and from the pictures of 2022, than IMatch returns to the first picture in 2022. So I have the scroll bakc to that place, where I have finished. (the place/date I have deleted pictures)
Would it be possible to return after deleting the last picture in the Viewer to the place, where that picture was, that I deleted at last?

Mario · November 19, 2022, 07:39:42 PM

When you open the Viewer with a selection, then mark all files in that selection for deletion, acknowledge the dialog with "delete", one of the files in the initial selection will exist anymore. By design, the File Window selects the file after the last selected file.

I've made a few quick tests and this was always the case. The file after the last selected file was selected when the Viewer returned and the files were deleted. The focus did not jump to the first file in the scope. I tried folders, categories and the timeline.

Do you have specific steps that cause this behavior?
Please be as detailed as possible. Every detail may matter. Including the order in which the files were selected, what the focused file was (!) (the last selected file) etc.

IMatch always tries to do the smart thing, but it might not be always able to.

mastodon · November 19, 2022, 10:54:08 PM

Aha, your right, it is not so easy to catch this. A had that many times in last months, even today, but I now can not reproduce it. I will be more accurate next. Thank you!

mastodon · November 19, 2022, 11:10:23 PM

Now I got it. So. I am in the Timeline view, selected year 2022. Pictures are in date order and the first one is selected. Then I scroll down and double click on a file to open it in Viewer. Then I delete it (or anyone) and press escape. Select Delete to delete that picture. (So, you does not have to load a selection of picture, and does not have delete all pictures.) And now I am at the first picture again.

Mario · November 20, 2022, 11:24:55 AM

Tried that here, following your instructions, with a variety of selections and states.
Always worked.
Opened the Viewer with a single file using double-click and with selections and double-click or <Enter>.
In all tests, the image after the deleted one(s) was selected.

The only exception was when I deleted the last image in the year. In that case, the Viewer wraps to the first file in the year, when there is no selection.

If I select the last 10 or so files in a year and delete them all, the image before the selection is selected afterwards.

I tried several sort profiles as well. Do you use the standard "Capture Time" sort profile or do you have created your own sort profile and what does it contain?

mastodon · November 20, 2022, 11:59:29 AM

Yes, I use the standard "Capture Time" sort profile. Have you seen the log file?

Mario · November 20, 2022, 12:52:35 PM

Nothing related in the log file. Just a warning about a fairly high memory load.
Closing the Viewer and restoring the "best possible" selection/focus after files have been deleted is not something that is logged, so no help there.

I have tried this several times, in a year with 2000 and another with 10K files. Duplicating images, then viewing and deleting them in various combinations. Not once was the focus placed back to the first file (or another nonsensical position). I must be missing an important step or behavior that causes this on your end...

mastodon · November 20, 2022, 04:41:58 PM

Thanks, I come back, when I get any new info. High memerí load might be caused be too many data-driven categories (my fault, I have to stop them always calculating).
Maybe I am doing something "strange"

Mario · November 20, 2022, 04:54:32 PM

Data-driven categories usually don't consume a lot of memory (unless they are insanely large).
The only feature in IMatch which really needs chunks of memory is the Viewer - it uses the memory to preload files.

Even for a database with almost one million files, IMatch uses only 3 GB RAM.

If you run Photoshop, it by default will allocate 50% of the available memory - even if it does not use it. The Photoshop memory model is non-cooperative for performance reasons (I suppose).