Setting ROI type manually

From what I understand, in the latest milestones of QuPath, Pete has chosen to replace AreaROI with GeometryROI, as seen here:

Previously, there was a huge problem in terms of processing time using the Dilate-plugin in multiple times sequentially in the same script. However, with the usage of the Java Topology Suite it went from several minutes to matter of seconds (for a single WSI!). It’s brilliant. The same issue is addressed and solved here:

But if I understand it correctly, in order to use the Java Topoplogy Suite, you have to use the Geometry ROI type, right?

Well, that’s fine in it’s own, but for my use case, it would be nice if I could convert annotations back to the AreaROI type AFTER the dilation-processing. The reason for this is that I have produces annotations using a trained CNNs and post-processed them in the new QuPath-0.2.0m8, but the annotators, who are going to correct the predictions, are currently using 0.1.2. I believe I found a rather “illegal way” to convert a QuPath-project from a newer version to be readable in 0.1.2, but the problem is that the Geometry ROI type doesn’t exist in 0.1.2. Hence, annotations cannot be read.

Therefore, is it possible to still convert or set ROI type manually? I know that it is possible to do so from AreaROI -> GeometryROI, as seen here:

It would be nice if I could set GeometryROI -> AreaROI, such that annotations could still be readable in the old version. However, the easy solution would be for the annotators to just use the new QuPath-version. But currently, at least for previous milestones, they felt that it was too unstable. Maybe that is fixed now?

Kind regards,
André

2 Likes

Interesting question :slight_smile:

Not entirely… each ROI now has a ROI.getGeometry() method to convert it into the closest possible JTS Geometry. You can process that however you like and then use qupath.lib.roi.GeometryTools to get a QuPath ROI again. As part of the conversion, QuPath will try to use the simplest representation it can (e.g. a PolygonROI if that’s all that is needed).

The difference with GeometryROI is that the internal representation is a Geometry, and that it can represent more complex shapes - just like AWTAreaROI could previously.

There’s also a ROI.getShape() method, which is closer to what the old AWTAreaROI representation used internally. The reason why AWTAreaROI is no more is because (as I’m glad you also experience!) JTS is much faster for some operations, and converting AWTAreaROIGeometry can be extremely slow. So it helps to use one representation consistently.

The AWTAreaROI code lingers on for now so that old QuPath ROIs can be imported if necessary. There are no plans to actively use it in QuPath v0.2.0, since I think its disadvantages far outweigh its advantages for all future work.

Still, if you want a hack-y solution, in v0.2.0-m8 you could try this:

import qupath.lib.roi.GeometryROI
import qupath.lib.roi.AWTAreaROI

for (annotation in getAnnotationObjects()) {
    def roi = annotation.getROI()
    if (roi instanceof GeometryROI) {
        annotation.setROI(new AWTAreaROI(roi.getShape(), roi.getImagePlane()))
    }
}
fireHierarchyUpdate()

I’ve just tried it (n = 1) and was able to open the file in QuPath v0.1.2.

I don’t disagree :slight_smile:

Depends a bit what is meant by ‘unstable’. If it refers to ‘still changing’, that’s definitely true. If it means buggy and crashing, I don’t think that’s true - as far as I’m aware it’s pretty reliable. There were issues in earlier milestones - actually often concerned with converting to geometries (which turned out to be full of trouble) - but I think these have been ironed out, and numerous issues from v0.1.2 fixed.

I wouldn’t actively encourage anyone happy with v0.1.2 to change (yet!) as it could still be disruptive for at least a few more months, but if you/they are willing to tolerate than then I think v0.2.0-m8 has a lot of advantages - especially for annotations. One of them is the JTS support, which means annotations can be converted into other portable forms (including GeoJSON, Well-known text, Well-known binary) - so can’t get locked into QuPath only.

2 Likes

Your script worked brilliantly! I am now able to convert a QuPath-project between versions (0.1.2 vs 0.2.8 - both ways) using a python-script :slight_smile: Thanks! I applied the same script on a full project of ~700 WSIs (run for project), worked perfectly. I’m certain this will please the pathologists at my department.

Also thanks for the clarification. Feel like I understand a little more about the fundamentals around this incredible software you are developing.

And yes, maybe it’s time for the pathologists in my group to upgrade to a newer version. I would say that both speed and number of key funcionalities have greatly increased. The pathologists are especially fond the of the pixel classifier, which of course isn’t in 0.1.2. Previously, using the very first milestones, they had lots of issues, but for the latest version at least, I don’t find the same issues.

And again, thank you very much! :slight_smile:

2 Likes

Mm, for the moment the pixel classifier is quite a bit slower in M8 than 1.2/1.3. Hopefully to be replaced by the thresholding tool.

1 Like

While I have you here; how’s the deep learning-integration going? Is it an ongoing project, or are there more important fixed to me made before such a huge project is to be done?

I read that the Orbit-guys have made it such that you are able to deploy your own trained tensorflow/keras-models (using Groovy), as well as train DIRECTLY in the software (WOW!):
http://www.orbit.bio/

What they have done seemed very insipired by QuPath, hence, ideas and solutions they have might be of interest in the deep learning-integration.

1 Like

That is going to be a very Pete question. I never got to deeply into it and ended up waiting for similar tools :slight_smile:

Ongoing project :slight_smile: Works well enough for me to demo, but not yet ready for wider use. I’d love to have time to work on it, but there are many other less glamorous things needed to make it practical (e.g. the ability to actually do something with the results), along with rewriting the documentation and detection classifier.

I will show the current status at NEUBIAS this year…

Sounds great! Don’t think QuPath is the inspiration though and they have plenty of their own ideas - in fact, I’m pretty sure Orbit was publicly available first (I remember seeing it while I was still campaigning to get QuPath released open source).

Although of course I think we’ve all been inspired by @Wayne and ImageJ in the end :smiley:

Not sure, but I think you’re thinking of the Positive pixel count tool.

3 Likes

I should add, I’m no longer developing it alone. With @melvingelbard on board now, more will happen in 2020!

1 Like

Oops, right, I was thinking of the Positive pixel tool!

Oh, yeah. That’s makes more sense :sweat_smile:
But thanks for the fast reply!