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.