BUG: duplicate search results

[pwalczysko]

Workflow:

• select a cat
• run a search
• refine it twice
• change the Retrieved images number from 100 to 20 and back to 100, running "Refine Search" after each change
• check the list of found images - there are two cases (at least) of images appearing twice in the list, at different positions - see screenshot
• double checked that this is really only one image - not a real duplicate which was imported twice
• both of the images live in the same dataset -> it is the same image found twice

[spli]

OMERO.searcher returns each channel separately. The triplet of numbers in the middle column indicates the C.Z.T indices, so in the screenshot channels 1 and 2 for person-12 are being returned as separate results.

Do you have any suggestions for how this could be improved? There's a separate ticket for single channel (instead of merge) previews: #11060

[pwalczysko]

Sorry, I understand now. Tried some searches with filtering of the channels and the results are consistent. So I guess this is not a Bug, but an RFE. The only thing needed is an on-the-fly info for the user. Yes, the thumbnail color will definitely help. The thing which is crucial in this case is to match the 0, 0, 0 with the C, Z, T on the top

• there is sometimes a long list, and the header scrolls away as you go down the list.
• But even when being at the very top of the list, it does not help that the header and the columns are somewhat shifted (see screenshot).
• seeing something like 1, 0, 0 without any explanation makes you think this is some incremental counter - no real match with C, Z, T in the biology-orientated head at all (channel zero ???? - doubt this would be supported/acceptable on any microscope acquisition software)

I think these would be the things to tackle in order to bring the (sound) point across to the user.

[spli]

So options include:

• Line up the 1.0.0 with the C.Z.T header (this is a general problem with the whole table).
• Make the table header row static so that it stays fixed whilst the rest of the table scrolls.
• Change the triplet to something like C=1 Z=0 T=0, or even C=FITC Z=0 T=0 if a channel name is available. Maybe omit the Z completely if there's only a single Z, and similarly for T and C.
• Add a tooltip/popup like when you mouseover a tag or attachment.
• Use 1-based indexing for everything.

Thoughts on what's best?

[pwalczysko]

@spli My opinion on your list would be:

• The first two items: I would think this should happen anyway, even if this is possibly a general Web issue, certainly this is a behaviour which you want for the whole table.
• Ad point 3: definitely we should aim to unify the channel displays with what is happening in the OMERO.Web (after all, we are in OMERO.Web) - possibly this is not always doable, but for the .png images at hand it would/should work (see screenshot below).
• Point 4 - not sure how keenly you would like to mouseover each item in a long list.
• Point 5 - yes, if everything else fails, but see above please

[pwalczysko]

Ah, for the Z and T - from the screenshot it is obvious that OMERO.Web is taking Z and T from 1, not from 0.

[pwalczysko]

Further to this topic

• the table is also not aligned with respect to the thumbnails (see screenshot) (.
• The thumbnails are very small to judge from them conveniently whether the images are positive or negative. Sometimes it would be helpful to see the whole image, or at least bigger thumbnail.
• it is not possible to deselect the radio button, once selected, mean: when I actually did not want to mark a particular image as positive or negative, I cannot go back to "non-selected" once I have clicked for example "positive".

[jamoore]

Cleaning up searcher backlog.