Hi Mario - just opening this ticket to report an issue with how the viewer is working. This was working correctly in 2025.1.12 and perhaps changed with 2025.2.2 (or 1.14).
The Issue: - Select 20 images in the File Manager
- Open them in the viewer
- Select all for compare with 16-up as default (16 load up in the compare window)
- Hit reject on the first image
The issue appears: the rejected image disappears from the block of 16, the screen "reloads", all additional images shift forward, and the zoom within the image location is reset to its default spot (not the spot it was set to before).
What Should Occur:The rejected image should remain on the screen but low-lit (to indicate reject), the cursor should move to the next image, the zoom within the image should remain fixed (so I can compare the close up across remaining images).
My Feature Request (Viewer Request (https://www.photools.com/community/index.php/topic,14935.0.html)) would also then allow the viewer to....: Once the last image is either rejected or moved past (before cursor jumps back to the first image), the next group of 16 images should be loaded (if there are enough to fill the 16 boxes) or it should load the next x images remaining.
Once all images have been displayed at least once, then the viewer should start at the first image (if the option to cycle is set), and the next 16 NON-REJECTED images should be displayed again for another round of comparison.
With this bug request resolved and the feature request in place, I could select 60 images, cull through them (rejecting/skipping) to narrow down the list to a small number all without having to leave and re-enter the viewer and while keeping the zoom fixed and waiting for screen reloading, etc.
Thx - Andy.
Was this exact behavior not added because of a feature request?
What is the state of Edit > Preferences > Application: Viewer "Delete moves next" and "Auto Advance" and "Skip deleted files" on your system?
My settings for these are:
Delete moves next: YES
Auto Advance: YES
Skip deleted files: YES
Zoom level in 16-up is set to either 50% or 100% depending upon the level of detail I'm comparing.
I'm happy to provide a small video to show what is happening...
Set all to NO. What happens?
I can still reproduce the same behavior with all of them set to NO.
I attached a small (low resolution for upload) video that shows me zoomed in, selecting an image in the 2nd row and rejecting it. The zoom levels reset, the image is removed and all images shift. I then reset the zoom, select another image on the 3rd row and the same thing happens.
I will have a look at this for one of the next IMatch releases.
As I said several times, changing the Viewer to implement the behavior you (?) requested for selected files in the film strip was not a good idea. I just may roll it back, removing the film strip selection feature again to simplify side-by-side handling in the Viewer. This has become too complex for my taste.
Thanks Mario...
I rely upon the viewer as my main method of culling images.... so, the ability to show 16 images at a time, zoomed in like in the example, and to quickly reject those that don't make the cut - is crucial to my workflow. I'm typically working through groups/stacks of 20-50 similar images and use IMatch to reject (and eventually delete) about 80% of these similar or bad images (RAW files always maintained outside IMatch).
When you are able to review this, I would hope for the following Viewer functionality:
- Always keep the selection of images when rejecting in comparison boxes
- Keep zoom levels fixed when rejecting/moving between images in comparison boxes
- When you reach the end of a group of selected images, load the next set of images into the boxes (repeat until there are no more unseen images loaded in the viewer)
- When you reach the end of the unseen images in the viewer (and the wraparound option is set to Yes), reload the comparison boxes with images ignoring already rejected images.
Just as an aside: I could not find ANY other software on the market that allows one to compare up to 16 images like IMatch can... this is a huge differentiator in the market... if we can work this out, it is another big marketing plus for sure!
Thanks as always.. happy to talk and help test, etc.... Andy.
QuoteJust as an aside: I could not find ANY other software on the market that allows one to compare up to 16 images like IMatch can... this is a huge differentiator in the market... if we can work this out, it is another big marketing plus for sure!
The average number of images viewed in the Viewer is 1, according to telemetry.
I doubt that many people have a need to compare 8, 12 or 16 images side-by-side.
Quote from: Mario on April 07, 2025, 06:17:01 PMQuoteJust as an aside: I could not find ANY other software on the market that allows one to compare up to 16 images like IMatch can... this is a huge differentiator in the market... if we can work this out, it is another big marketing plus for sure!
The average number of images viewed in the Viewer is 1, according to telemetry.
I doubt that many people have a need to compare 8, 12 or 16 images side-by-side.
I find this surprising... but I use IMatch as the last stop for image work.. it contains only RAW-editor exported JPG's which I then review in bulk to cull via the viewer. Once the images are rejected, I delete them from the database which leaves me a lean and ideal database full of final JPG images.
I do not know of course, how many people are using telemetry at all.
But I do using usually up to 8 images, but in the last weeks I have also used more.
The viewer is a great tool for comparing, really.
@Jingo: I do the same like you, basically, but have raw and jpg neatly side-by-side :)
Sometimes I do create a new version from the raw, on this way it is done quickly.
Quote from: Jingo on April 07, 2025, 02:28:57 PMHi Mario - just opening this ticket to report an issue with how the viewer is working. This was working correctly in 2025.1.12 and perhaps changed with 2025.2.2 (or 1.14).
What Should Occur:
The rejected image should remain on the screen but low-lit (to indicate reject), the cursor should move to the next image, the zoom within the image should remain fixed (so I can compare the close up across remaining images).
I am still on 1.14 and the behaviour, what you described as "What Should Occur" is exactly, what happens here, except that the rejected image (when I hit delete) does low-lit and a big sign on this image.
This is, in my opinion, correct.
Hmm, in this case, this behaviour could be changed later.
At the moment I do update not that frequently, because I have some troubles with the time. 8)
If you press <Del> in normal operation, the image is just rejected and dimmed, not causing a full reload.
This is what @sinus experiences. It just works as it should in normal operation.
As far as I can understand, all of this happens only when the user makes a selection in the Viewer film strip and IMatch dynamically adjust the number of images shown, based on the number of selected images in the film strip and the maximum number of available images for side-by-side.
Because, other than the normal mode of operation, in this mode rejecting an image actually removes it from the View, causing all other image containers to reload the "next" image in sequence.
When loading a new image, image panels reset certain stats, because the new image loaded may have a different size or format or whatever. In your particular use case, this is not the case, because you are comparing a number of identical images, but that's not something we can assume to be true always. Other users may compare differently sized images.
This would mean I need to add even more logic and special cases / checks on top of all the stuff already going on. And I don't like this.
I think I will remove the film strip selection feature. It causes way to much trouble, to much work and has complicated the Viewer unnecessarily. It was a bad decision on my part to implement this feature request, not knowing of all the resulting complexity it would cause.
I will think about this for a couple of weeks and then decide.
Quote from: Mario on April 08, 2025, 10:58:28 AMIf you press <Del> in normal operation, the image is just rejected and dimmed, not causing a full reload.
This is what @sinus experiences. It just works as it should in normal operation.
As far as I can understand, all of this happens only when the user makes a selection in the Viewer film strip and IMatch dynamically adjust the number of images shown, based on the number of selected images in the film strip and the maximum number of available images for side-by-side.
Ah, that could be the point.
I do never use selections inside the viewer film strips.
Hmm.. you know.. I never realized this only happens when you choose photos via the film strip! It is just what I have always done... but the viewer works well if I don't use it... so I won't!!
I'd be 100% fine removing the filmstrip (and its logic) from the viewer... if some of the logic items I mentioned above can be incorporated into the compare logic, that would be a huge bonus!
Sorry for the confusion.. I didn't realize the filmstrip selection was causing the issue!
Quoteif some of the logic items I mentioned above can be incorporated into the compare logic, that would be a huge bonus!
Please write a feature request then.
I don't check bug reports for feature requests and this may just get lost.
When you use the normal Viewer mode (selection comes from File Window), I think it already does most of what you request? Maybe check again and then write a feature request when something is amiss and you think it would be beneficial for a number of users.
Hi Mario - just wanted to follow-up and say that I think what the Viewer currently does is just fine for me.. been using the viewer for a couple weeks culling a thousand images and I can easily work with this functionality.
The key to this whole exercise was not using the thumbnails in the viewer to select images. Since so few users seem to utilize the viewer, I will hold off on adding a feature request for the other "nice to haves"....
Thx again!