Cannot import images coming from 2 different groups during the same connection

[Rdornier]

A user is part of 2 different groups A and B on OMERO.

• If an image is imported from group A, the image is imported in QuPath without any issue.
• Then, if we try to import a second image from the group B, it fails with the following error :

15:22:31.722	[project-import11]	ERROR	qupath.ext.omero.core.imageserver.OmeroImageServer	Couldn't create pixel API reader	java.io.IOException: Couldn't find requested image of ID 516335
	at qupath.ext.omero.core.pixelapis.ice.IceReader.<init>(IceReader.java:111)
	at qupath.ext.omero.core.pixelapis.ice.IceAPI.createReader(IceAPI.java:143)
	at qupath.ext.omero.core.imageserver.OmeroImageServer.create(OmeroImageServer.java:111)
	at qupath.ext.omero.core.imageserver.OmeroImageServerBuilder.lambda$buildServer$0(OmeroImageServerBuilder.java:30)
	at java.base/java.util.Optional.flatMap(Unknown Source)
	at qupath.ext.omero.core.imageserver.OmeroImageServerBuilder.buildServer(OmeroImageServerBuilder.java:30)
	at qupath.lib.images.servers.ImageServerBuilder$DefaultImageServerBuilder.buildOriginal(ImageServerBuilder.java:350)
	at qupath.lib.images.servers.ImageServerBuilder$AbstractServerBuilder.build(ImageServerBuilder.java:174)
	at qupath.lib.gui.commands.ProjectImportImagesCommand.initializeEntry(ProjectImportImagesCommand.java:727)
	at qupath.lib.gui.commands.ProjectImportImagesCommand$1.lambda$call$2(ProjectImportImagesCommand.java:468)
	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
	at java.base/java.util.concurrent.FutureTask.run(Unknown Source)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
	at java.base/java.lang.Thread.run(Unknown Source)

My guess is that the security context is not updated to access to the correct group (I already had this issue on my side, reported here BIOP/qupath-extension-biop-omero#7).
this.securityContext = new SecurityContext(groupId); to switch group.

[Rylern]

So I was able to partially fix this in v0.1.0-rc6. However, there are two limitations:

• Two images of two different groups cannot be read at the same time (see this issue). If an image is open, all images of different groups are now automatically closed.
• If you open an image belonging to group A, then open an image of group B, then open an image of group A, an exception is thrown (see this issue). I wasn't able to find a workaround for that.

[Rdornier]

Thanks for proposing a fix for this issue.
I can confirm that

• I'm now able to import images from 2 groups
• I can confirm the bug described in your second bullet point.
• I can import one image from group 1, following with one image of group 2, without troubles expect the thumbnail of the second image which takes more time to load.
• If I try to import img1 from group1, img2 from group2 and img3 from group3, then it shows a error message telling me to see the console but no error is added in the console. The img3 is also not imported. If I try again to import img3 (so full pipeline is img1>img2>img3>img3), img3 is finally imported
• If I try to come back to the first group (or any group already used to import images) (import img1>img2>img3>img3>img1), the last img1 is never imported, even I try to import it again and again

I don't really understand your first bullet point ; how this can happen ? I tried to reproduce but don't know how

[Rylern]

If I try to import img1 from group1, img2 from group2 and img3 from group3, then it shows a error message telling me to see the console but no error is added in the console. The img3 is also not imported. If I try again to import img3 (so full pipeline is img1>img2>img3>img3), img3 is finally imported

Can you set the logs to DEBUG (View, Show log, and then set the level in the top right corner of the window) and try again? I wasn't able to reproduce that.

If I try to come back to the first group (or any group already used to import images) (import img1>img2>img3>img3>img1), the last img1 is never imported, even I try to import it again and again

Yes, that's expected because of the limitations.

I don't really understand your first bullet point ; how this can happen ? I tried to reproduce but don't know how

Here is a script:

import qupath.lib.images.servers.ImageServers
import qupath.lib.images.servers.TileRequest
import qupath.lib.regions.ImageRegion

def url1 = "http://localhost:4080/webclient/?show=image-20"   // image of some group
def url2 = "http://localhost:4080/webclient/?show=image-44"   // image of some other group

def server1 = ImageServers.buildServer(url1, "--pixelAPI", "Ice")
def server2 = ImageServers.buildServer(url2, "--pixelAPI", "Ice")

server1.readTile(TileRequest.createInstance(server1, 0, ImageRegion.createInstance(0, 0, server1.getWidth(), server1.getHeight(), 0, 0)))

It create two image servers (of images that belong to two different groups), then attempt to read pixels from the first. Since the two images belong to two different groups, the ICE reader of the first image server is closed when the second image server is created. So, an exception occurs when attempting to read pixels from the first image server.

This may also happen in the user interface if you right click on the viewer, Multi-view..., Set grid size, Grid 2x1, and then open two images of different groups in parallel (but the error might not directly appear because of caching).

[Rdornier]

Can you set the logs to DEBUG (View, Show log, and then set the level in the top right corner of the window) and try again? I wasn't able to reproduce that.

So, with rc10, I wasn't able to reproduce it anymore. I could import successivelly img1>img2>img3>img4 from 4 different groups. So, should be ok

Yes, that's expected because of the limitations.

True, until it will hopefully be fixed

Here is a script:

Ok, I better see now, thanks. It's linked to this issue "if you open an image belonging to group A, then open an image of group B, then open an image of group A...." in fact.

[Rylern]

Ok, I better see now, thanks. It's linked to this issue "if you open an image belonging to group A, then open an image of group B, then open an image of group A...." in fact.

Not really, because here you just need to open an image belonging to group A and then an image belonging to group B to have the issue (you don't have to open another image of group A).

Another difference is that this issue is expected by the design of the extension (which closes all images of different groups when an image is open). The "if you open an image belonging to group A, then open an image of group B, then open an image of group A...." issue is not expected by the design of the extension.

[Rdornier]

Not really, because here you just need to open an image belonging to group A and then an image belonging to group B to have the issue (you don't have to open another image of group A).

I understand the point, now. But I didn't get any error if open in parallel in an image from group A and group B (probably due to caching, as you mentionned previously). I also try to import KVPs from OMERO for both images... and its works for both as well.

The "if you open an image belonging to group A, then open an image of group B, then open an image of group A...." issue is not expected by the design of the extension.

I agree

[Rylern]

Yes, you'll only get the error when fetching new pixel values since everything else doesn't use ICE