QUPath Open URL

[M. Zarella]

I'm having a lot of difficulty getting the "Open URL" command to consistently work.  It seems to work when I browse to a filename on my local network, but when I use an actual URL it says it can't open the file.  However, the same file works after I download it locally.

For testing, I'm using a publicly available URL/file from the Openslide site.

[Pete]

If I understand correctly, 'Open URL' can't do what you'd like - at least not now, or not directly.  Nevertheless, it potentially helps make that possible... and certainly the ability to access images that aren't stored locally could be very useful indeed.

To read images remotely, you'd need two things:

1. a 'tile server' - which has direct access to the image files, and can extract the pixels and then return these on demand
2. a QuPath extension that knows how to make requests to that tile server
   

There are lots of different potential tile servers that might be used - open source and not.  I believe there's an example of one included with OpenSlide + Python: https://github.com/openslide/openslide.github.com/issues/6

IIPImage is another option (although I haven't tried it myself; might require converting pathology images): http://iipimage.sourceforge.net

In any case, tile servers tend to require requests to be made in different ways, and QuPath has no built-in support for any of them.  However, the 'Open URL' command means that adding support wouldn't require any core changes to QuPath (because no assumption is made that an image is always stored in a local file), and so support certainly could be added.  It would have to be tailored to whatever tile server is used, and so is only worthwhile creating if there is a direct need.

If you or anyone would like to discuss handling the QuPath side of this, just let me know - I can certainly help with that.  But a few considerations are:

• there would need to be documentation for how the tile server wants requests to be made (and no barriers to using this documentation in an open source project)
• it's a lot easier to add support for 8-bit RGB images; multichannel fluorescence images (for example) would be trickier
• it's common for the tile server to extract pixels, then (re)compress them as JPEG images before sending them to the client (i.e. QuPath in this case).  The compression step means that the pixel values may not be exactly the same as if the image was accessed directly.  Assuming the compression is set to a reasonably high quality level I expect that the impact this would have on analysis results is likely to be negligible, at least for brightfield images... but it's something to be aware of.

In the meantime, the (much less interesting) occasional use I have for 'Open URL' is to get the path to the image I currently have open, and then copy/paste either from or to this field.

[M. Zarella]

Really interesting response, thanks.  So I have a tile server already, but I suspect QuPath isn't able to correctly interpret because it's proprietary.  I checked with the software developer of this platform and he said the API is non-standard.  I'm not sure how to proceed, but I would definitely welcome a discussion about it.

Also, when I mount the network drive locally, QuPath reads it ok (using Open URL - sounds like the way you're doing it) and seems to be exploiting the image pyramid to do so because it is loading much more quickly than it takes to download the full file.  My ultimate goal is to get this kind of performance, but to use an URL instead of a mounted folder.

[Pete]

Hmmm.... some years ago I came across OpenSeaDragon for viewing large images, and this includes support for a 'custom tile source': https://openseadragon.github.io/examples/tilesource-custom/

I could certainly something similar being useful in QuPath: an almost complete implementation of an extension to read from a tile server, but one that is nonetheless missing the key bit of plumbing necessary to format the requests to the server.

Off the top of my head, given an image URL, the minimal information I think would be required is:

• a method to request image metadata: image dimensions, preferred tile size, pixel size in µm, available resolutions in the image pyramid, number of z slices or time points (if supported)
• a method to request individual tiles, taking as input QuPath's standard requests (including a downsample value, and bounding box defined in the full resolution coordinate space)

And two other parts that may be needed:

• a way to obtain a list of available image URLs, if these are not otherwise known or accessible
  
• a way to handle passwords/authentication (which potentially complicates things considerably)

It should be possible to handle everything else that is needed in a fairly generic way, at least if interest is restricted to 8-bit RGB images.

I could see this not-quite-useful-but-almost implementation becoming part of QuPath if there was a clear path to filling in the gaps to make it useful, at least for some users.

One last concern is how well different tile servers might respond to needing to handle potentially many more requests from different users applying image analysis simultaneously.  I imagine this might well be more demanding than multiple people simply viewing and annotating images... but maybe it's not an issue, I don't know.

[M. Zarella]

Well, I think this kind of feature would have broad application because it would allow QuPath to be integrated fairly easily to other platforms.  Whether it's something as simple as an Excel database of URLs (not terribly uncommon in research actually...) or as mature as an image management platform (a PACS system for example).  By adding URL support, it simply allows the user to keep his data in the cloud or on a network server and not have to go through the process of downloading it locally.  It's potentially superior to the mount-a-network-drive-locally solution because authentication could be handled by the image management platform rather than by Windows (there are lots of reasons not to provide end-users direct access to the network share).

My particular application would be to replace Aperio's ImageScope software with QuPath, because I think QuPath's image processing tools are more accurate.  But ImageScope has the ability to load URLs...  so that's where I'm stuck.

[Saket Kulkarni]

Hi all - Just came across this post and realized that this is also one of my biggest pain points. There are lot of images on servers which I can view using Webscope/Imagescope but cannot input them in QuPath. It would be fantastic if someone has been able to successfully setup the "tile server" as Pete has mentioned in one of his replies to get a FOV for QuPath analysis. Right now I export the FOV and then open the .tiff in QuPath, but getting a slick integration would be awesome. Look forward to hearing some positive replies. Cheers !

[Pete]

Good timing... this shows the idea in action.

[CH HUANG]

Hi,

You may want to consider about the work of OpenRemoteSlide (https://github.com/huangch/openremoteslide), which allows you to use exactly the same way as of OpenSlide, but able to access WSIs from a remote server via FTP, HTTP, etc. I manipulated the low-level code of file access in the original OpenSlide, so essentially, as long as the QuPath didn't do anything on the string of file path, or any file management job based on the string of file path, OpenRemoteSlide should be able to work just like original OpenSlide. You can see the example of openslide-show-properties showing in the OpenRemoteSlide github...

Happy Coding...

CH

[Pete]

Hi CH,

This sounds great - I've looked at the TCGA API a few times hoping to find a way to request image tiles, but never did.  Am I right to think that it doesn't exist, and your solution resembles lower-level file access... but for files stored remotely?

One potential problem (at least in the short term) is that OpenSlide's Java API takes a File object as input, and immediately throws an exception if the file does not exist locally:

https://github.com/openslide/openslide-java/blob/master/src/org/openslide/OpenSlide.java#L101

It should be possible to work around this, but at least it means that replacing the native libraries alone wouldn't be enough to get it to work and some more effort would be required.

To work with QuPath, there would ideally be portable binaries available for all platforms (something I never quite managed fully with OpenSlide and issues remain) and a separate extension created to add support with this fork of OpenSlide.  If someone tries to create this I'd be very interested in the results. If the performance is good enough to support the tile requests sent by QuPath when interactively browsing a whole slide image it might ultimately replace the current OpenSlide extension.

Best wishes,

Pete