Viewer: Rejects wrong file when manually selecting image

[Jingo]

Hi.. noticed another item when I was working with the viewer today to cull images.  During the process, I selected 8 images.  I manually selected the 2nd image (clicked into the box) and was comparing it to the rest - it had the yellow highlight box surrounding the photo in the thumbnail panel as well as the image grid.

I then clicked the 3rd image (the yellow highlight box updated to show it was selected in the grid) and hit the reject key.  

The 2nd image was marked for deletion instead of the 3rd image which was highlight and selected.  I did notice that the thumbnail panel never moved the yellow box to the 3rd image during this process.

I create a video and attached it to showcase the issue (sorry for the horrible resolution - needed to convert to GIF to attach and keep size under 4MB).  You may need to zoom in quite a bit to see the cursor.

The 3rd image is selected around the 7 second mark and the 2nd image marked for deletion within the same second.  Could this be a timing thing (am I being too quick to select and then reject?).  I noticed the highlight box only moved the 2nd time I went through to reject the 3rd image after un-rejecting the 2nd one.. and then the highlight box did move in the thumbnail strip.

I can reproduce this with various other image combos too... Sorry for all the posts today!!

[Jingo]

Anyone else experiencing this issue?

[Tveloso]

I could reproduce this, but it did require a very quick press of the Delete key.
__PRESENT

I does seem to be a timing issue...when an image in the Viewer Grid is selected, there's a slight (subsecond) delay between when that selection is made, and when the corresponding thumbnail in the Filmstrip becomes selected.  Ant the reject function appears to be based on the Filmstrip.  If this condition is created (where file that was rejected by the Delete Key press, is not the one that's now selected), pressing the Delete key again does not un-reject the previously rejected file, but rejects the second (now selected file).

But again, on my PC, with my 86K+ Files Database, I need to be very quick with the delete key to create the condition.  Perhaps with larger databases the issue is more pronounced?...

[Jingo]

Thx Tony... I can reproduce this as well and it seems like the database isn't updating the move to next action before performing the reject action.  In a burst mode review session - it is easy to reject 6+ images quickly since most are same and can easily be duplicates or out of focus items... it works fine until you select an image manually - then this error occurs.

Appreciate the feedback!

[sinus]

Yes, I tried this also here and had the same effect.

I do all my checks, what image to take, in the viewer. 
And I do it by give an image a red pin.

I have noticed this since several month. And I guess, it is the same, like Tony and you wrote: a kind of "timing problem". 

If I do this too quickly the yellow border is very quickly around the new selected image and if I then hit too quickly r (for red pin), then this is assigned to the image, where I was before.

I tried this also with e (blue pin) or delete, always the same.

I just thought, I mustn't click sooo quickly, and after that I had no more problems.
But if I was still too fast and didn't notice, I'd occasionally tag the wrong thing with a pin and only realise it later.

[Jingo]

Thx Markus - appreciate the verification as well.. I thought I was seeing things!  The extra odd thing with this as well - if you then try to select a previous image that was incorrectly rejected, the image BEFORE that one gets unrejected (or rejected if the flag was set).  So, something happens to the actual "selected image with the yellow box" and which image the SYSTEM thinks is currently selected.

I'm hopeful Mario will be able to review and come up with a fix (as he usually is able to) when he has time... I can certainly "slow it down" a bit.. but - I'm not going THAT fast!  

[sinus]

So we know now: 
Sometimes it is not good, working too fast! 

[Mario]

I've played around with this for a bit, seeing if I can reproduce. I expected some sort of timing issue.

When the user left clicks into a Viewer image window, many things must happen.
Maybe the user is initiating a dive zoom. Maybe the user clicked into an annotation object and which. Or maybe the annotation selection was just reset by clicking outside any annotation object?
Stuff like that.

After doing all this, and deciding the best operation to perform, the image window may send a "I have been clicked" message to the Viewer. The Viewer reacts to this message by setting a short timer, in order to let things "settle". The timer was 500ms (0.5 second). When the timer is triggered, it, among other things, changes the focused file to the image just clicked, updates the film strip, scrolls it when needed, updates all overlays, the category panel, the annotation panel etc.

Yes. A simple mouse click does generate a lot of work.

If it now happens that the user presses <Del> within the 0.5 seconds the timer needs to run, indeed the wrong file may be marked for deletion.

I have reduced the timer duration to 0.2 seconds and noticed no ill effects so far.
This change may break things that worked "out in the field", I have no idea. It might be interfere somewhat with users who prefer to navigate between image windows in the Viewer using the cursor keys instead of clicking, but unlikely since this is a different execution path, mostly.

So, before the next version is out, please wait at least 0.6 seconds before pressing <Del> after clicking into an image. Or get a faster PC

[Jingo]

Thx Mario... I'm sure I'm just being a bit too fast with things. Normally, I wouldn't be interacting with the viewer to delete/reject images so quickly. It is only because I am going through bursts of images (50-120fps) and once I find one that is sharp/good, I want to reject the rest.  Will slow things down on my end until the next release and then I'll play again and see how the system responds with your code change.

Or get a faster PC

Please.. don't tempt me...!  

[Mario]

Use the keyboard for navigation between files. It updates the "focused file" immediately and you can click <Del> faster.

[Jingo]

Thx Mario - I tested this using the mouse for navigation and it is MUCH better now... appreciate this greatly!!