From binary mask to qpdata

qupath
#1

Hi guys,

I was trying to get a qpdata file from a binary mask with a script (avoiding use the gui) but I’m not sure if this is something possible. Until now I’m been using the script to import binary masks and create new qupath annotation and everything work fine but I would like to automatically generate a qpdata from a binary mask to open it directly in qupath.

Can someone give me some clue?

Thank you in advance!

0 Likes

#2

Not sure about a qpdata file, but a similar question was asked here, but you can save annotation objects and detection objects as a file.

0 Likes

#3

Can you say more about your workflow? Presumably the automatic generation is via a script or something else… but not run through QuPath since you want to avoid the GUI.

Not sure if it answers your question, but .qpdata files basically use Java serialization. To write one, you’ll need to be using Java and the relevant QuPath jars as dependencies. The GUI isn’t strictly necessary.

So if you’re meaning to write a .qpdata file completely independently of QuPath, this isn’t really possible. But if you want to write it using Java/Groovy + the QuPath jars without showing the GUI, this should be possible.

0 Likes

#4

First of all thank you for your quick responses!

Our idea would be more like write the qpdata using Java/Groovy + the QuPath jars without showing the GUI as you say @petebankhead . We are generating a binary mask in a server and we want to avoid to download the binary mask and run the script to convert the mask in an annotation in the client every time we generate a new mask in the server. We would like to run that script in the server and download just the qpdata to the client to open it in qupath.

I mentioned about not using the gui as we don’t have it in the server.

0 Likes

#5

I assume you’re referring to the script here: https://petebankhead.github.io/qupath/scripting/2018/03/13/script-export-import-binary-masks.html

The main thing there that depends on the GUI is

def imageData = QPEx.getCurrentImageData()

which requests the current imageData open in the viewer.

In your case, you’ll need to create a new one. You can do this with something like the following:

def serverPath = '/path/to/image'
def server = ImageServer.buildServer(serverPath, BufferedImage.class)
def imageData = new ImageData(server)

I have neither tested this now included the necessary import statements, but hopefully it helps point in the right direction.

To write the .qpdata file, you’ll use something like this:

PathIO.writeImageData(file, imageData)

Note that the precise details may differ depending on whether you’re using QuPath v0.1.2 or the (still-in-development) v0.2.0, and the situation is slightly different if you want to use projects rather than individual .qpdata files.

In general, the API for all this in v0.2.0 isn’t yet stable because the way data files and projects are managed is undergoing a pretty major revision. Not so major that .qpdata files aren’t backwards compatible (that might be necessary in a later version, but not any time soon), however the changes I’m making have a few purposes & not-fully-resolved-challenges:

  • Use URIs for server paths rather than ‘paths to the file system’, since not all images need to be stored locally (e.g. an image accessed through OMERO)
    • Challenge: some servers need more than a path to an image, and rather need also to encode extra info (e.g. rotation, cropping, image number within a file). Currently that info is encoded within the path, but that might not be sustainable. A unique path is essential for tile caching.
  • Don’t force Projects to be directories on the local file system. Convert Project to an interface that might be implemented in other ways.

I hope that makes some kind of sense. Basically, v0.1.2 isn’t changing so if that’s what you’re using then you can ignore the rest. But for v0.2.0 things aren’t stable yet. With that in mind, I’m happy to discuss any API changes that could help make this task easier, if I can understand more what exactly you want to do and why.

You’ll want to avoid using QPEx at all, since this is only in the GUI jar and you probably want to skip any reliance even on JavaFX being available (regardless of whether you use it). This means you likely want to build your file paths a different way for that used in the original binary image to annotation import script.

0 Likes