About RegionRequest and annotations

Hi all,
I am trying to export/import regions and annotations, yet the problems bother me are:
(1) For RegionRequest, are the metrics of getX/getY/getWidth/getHeight in terms of pixels or microns?
(2) About the vertices of polygons for the annotation, are they in microns as well?

I appreciate it if I can have some information here:)

Both are defined in pixel coordinates from the full resolution image, with the origin (0,0) at the top left of the whole slide image.

This is mostly because the μm information read from the file can sometimes be wrong, and if this is corrected then it shouldn’t be necessary to update all the coordinates. The coordinates shown on the bottom right of the viewer may be in μm if this info is available, but under the preferences you can change this with the ‘Use calibrated location text’ option.

(I’m currently in the process of updating the javadocs and refactoring the code to hopefully make this information more accessible… some scripts may break as things move around, but I hope that ultimately it makes scripting a lot easier…)

Ah that will much easier :slight_smile:

By the way, may I ask what the currentSegment fetches (from the pathIterator of the shape of an ROI)? It appears to be double instead of int.

Well, that one is a Java question more than a QuPath one, so there are already better javadocs: https://docs.oracle.com/javase/8/docs/api/java/awt/geom/PathIterator.html#currentSegment-double:A-

Yea about that I am wondered, are the coordinates here float because of interpolation? It doesn’t seem to be the exact coordinates of the array itself.
Could the pair of the float of the pathIterator be used as the coordinates of the PolygonROI?

I’m not sure what you mean. The coordinates should match with those of the PolygonROI, both of which can be floating point. QuPath doesn’t force ROI coordinates to be integers*; indeed the ROI might be calculated at a different resolution and rescaled by some non-integer amount.

The (slightly) relevant notes here might help a bit: https://petebankhead.github.io/qupath/technical/2018/03/13/note-on-contours.html

*-I do occasionally wonder if it should…

I see. Really appreciate it, Pete.

Just in case: does the PolygonROI the best choice for contours of a “doughnut”-alike annotation, i.e. polygons with holes inside?

Ah, no - they’ll need to be AreaROIs. The polygon can only be used to generate the outer contour. From memory, the easiest way to create what you want is through PathROIToolsAwt (if you don’t find the methods, let me know the version of QuPath and I’ll check where the class is…).

I should mention there is some trouble in v0.2.0-m1 and v0.2.0-m2 when it comes to handling such doughnut ROIs in the hierarchy… basically, the hole is ignored when resolving which objects are ‘inside’ one another. This happens because v0.2.0 is using Java Topology Suite (JTS) to improve performance and increase the range of ways shapes can be queried and manipulated… but it turns out that the built-in method of converting java.awt.Shapes to JTS Geometry objects can end up ignoring holes (see here).

Area measurements shouldn’t be affected (because they don’t use JTS code) and v0.1.2 shouldn’t be affected (because it doesn’t use JTS at all). I believe I have a workaround that can convert QuPath ROIs to valid JTS Geometry objects consistently (at least, it has survived all my tests so far) so this should be fixed in the next milestone… which should be available within the next month, mostly because I’d like it working before Zidas. But I’ve got caught up in a lot of refactoring and documenting, which is proving slow.

Finally, JTS/GeoJSON has a much more ‘standard’ way of representing ROIs than QuPath’s home-grown one, in which polygons can have holes. QuPath might switch to this one day, but probably not any time soon. For now, a QuPath polygon is really more of a linear ring.

Gotcha.
I am exploring some of your tutorials.
It appears that this one may be the resolution: https://petebankhead.github.io/qupath/scripting/2018/03/13/script-export-import-binary-masks.html

Perhaps I can convert the vertices-based xml annotation to the binary mask first? Or there might be a way to revert the xml containing plain vertices coordinates of the contours from a doughnut back to the areaROI? I find it tricky to figure out what is the inner ring/outer ring and which area should be filled.

What do you mean by ‘vertices-based xml annotation’? Is this an annotation created in some other software? In the end, what is the purpose…?

There are various threads about exporting/importing annotations with QuPath, which predate the use of this forum:

If there is a suitable open format then support it could be added in QuPath, but I don’t know of any clear choice. GeoJSON is one candidate.