StarDist-QuPath_3.0 SNAPHOT (Detection for bigger Annotations)

Good day all,
In an attempt to using the he_heavy_augument script (with customization parameteers to include the probability estimates as measurements and some little expansion as shown in the script below.

import qupath.tensorflow.stardist.StarDist2D
import qupath.lib.objects.PathObjects


// Specify the model directory (you will need to change this!)
def pathModel = 'G:/Neo/Scripts/StarDist/he_heavy_augment'


def stardist = StarDist2D.builder(pathModel)
      .threshold(0.1)              // Prediction threshold
      .normalizePercentiles(1, 99) // Percentile normalization
      .pixelSize(0.5)              // Resolution for detection
      .cellExpansion(0.5)          // Approximate cells based upon nucleus expansion
      .cellConstrainScale(1.5)     // Constrain cell expansion using nucleus size
      .measureShape()              // Add shape measurements
      .measureIntensity()          // Add cell measurements (in all compartments)
      .includeProbability(true)    // Add probability as a measurement (enables later filtering)
      .build()

// Run detection for the selected objects
def imageData = getCurrentImageData()
def pathObjects = getAnnotationObjects()
if (pathObjects.isEmpty()) {
    Dialogs.showErrorMessage("StarDist", "Please select a parent object!")
    return
}
stardist.detectObjects(imageData, pathObjects)
println 'Done!'


The script worked perfectly for smaller annotations but when I try it same script on a larger annotation, I keep getting an error (also posted below). afterwards the QuPath console closes.


(This script worked here)


(same script gives error on bigger annotations, the error is posted below)

log.txt (66.6 KB)
Error text

I will be delighted if somebody could help me out.

Regards.

Thanks @Benjamin_Igbo the critical error is

ERROR: IllegalArgumentException: Points of LinearRing do not form a closed linestring

ERROR: org.locationtech.jts.geom.LinearRing.validateConstruction(LinearRing.java:93)
    org.locationtech.jts.geom.LinearRing.<init>(LinearRing.java:88)
    org.locationtech.jts.geom.GeometryFactory.createLinearRing(GeometryFactory.java:382)
    org.locationtech.jts.geom.GeometryFactory.createLinearRing(GeometryFactory.java:369)
    org.locationtech.jts.geom.GeometryFactory.createPolygon(GeometryFactory.java:495)
    qupath.tensorflow.stardist.StarDist2D.createNuclei(StarDist2D.java:890)

It’s the same as the one here: QuPath_StarDis tmodel - #2 by Research_Associate

I believe I’ve already got a fix for that but haven’t pushed the code yet; it originates from the StarDist prediction returning ‘Not-a-number’ values. The fix seems to work, but I remain unsure why these ‘Not-a-number’ values are occurring.

I’d be curious as to whether this occurs with QuPath v0.2. To test this, you can build from the main branch (not the dev-0.3 branch), in which case it will be using a different version of TensorFlow.

The other errors are not so important:

at loci.formats.in.JPEGReader$DefaultJPEGReaderConstructorAccess.newInstance(Unknown Source)
    at com.esotericsoftware.kryo.Kryo$DefaultInstantiatorStrategy$1.newInstance(Kryo.java:1275)
    at com.esotericsoftware.kryo.Kryo.newInstance(Kryo.java:1139)
    at com.esotericsoftware.kryo.serializers.FieldSerializer.create(FieldSerializer.java:562)
    at com.esotericsoftware.kryo.serializers.FieldSerializer.read(FieldSerializer.java:538)
    at com.esotericsoftware.kryo.Kryo.readObject(Kryo.java:731)
    at com.esotericsoftware.kryo.serializers.ObjectField.read(ObjectField.java:125)
    at com.esotericsoftware.kryo.serializers.FieldSerializer.read(FieldSerializer.java:543)
    at com.esotericsoftware.kryo.Kryo.readObject(Kryo.java:731)
    at com.esotericsoftware.kryo.serializers.DefaultArraySerializers$ObjectArraySerializer.read(DefaultArraySerializers.java:391)
    at com.esotericsoftware.kryo.serializers.DefaultArraySerializers$ObjectArraySerializer.read(DefaultArraySerializers.java:302)
    at com.esotericsoftware.kryo.Kryo.readObject(Kryo.java:731)
    at com.esotericsoftware.kryo.serializers.ObjectField.read(ObjectField.java:125)
    at com.esotericsoftware.kryo.serializers.FieldSerializer.read(FieldSerializer.java:543)
    at com.esotericsoftware.kryo.Kryo.readObject(Kryo.java:731)
    at com.esotericsoftware.kryo.serializers.ObjectField.read(ObjectField.java:125)
    at com.esotericsoftware.kryo.serializers.FieldSerializer.read(FieldSerializer.java:543)
    at com.esotericsoftware.kryo.Kryo.readObject(Kryo.java:731)
    at com.esotericsoftware.kryo.serializers.ObjectField.read(ObjectField.java:125)
    at com.esotericsoftware.kryo.serializers.FieldSerializer.read(FieldSerializer.java:543)
    at com.esotericsoftware.kryo.Kryo.readObject(Kryo.java:731)
    at com.esotericsoftware.kryo.serializers.ObjectField.read(ObjectField.java:125)
    at com.esotericsoftware.kryo.serializers.FieldSerializer.read(FieldSerializer.java:543)
    at com.esotericsoftware.kryo.Kryo.readObject(Kryo.java:731)
    at com.esotericsoftware.kryo.serializers.DefaultArraySerializers$ObjectArraySerializer.read(DefaultArraySerializers.java:391)
    at com.esotericsoftware.kryo.serializers.DefaultArraySerializers$ObjectArraySerializer.read(DefaultArraySerializers.java:302)
    at com.esotericsoftware.kryo.Kryo.readObject(Kryo.java:731)
    at com.esotericsoftware.kryo.serializers.ObjectField.read(ObjectField.java:125)
    at com.esotericsoftware.kryo.serializers.FieldSerializer.read(FieldSerializer.java:543)
    at com.esotericsoftware.kryo.Kryo.readObject(Kryo.java:709)
    at loci.formats.Memoizer$KryoDeser.loadReader(Memoizer.java:163)
    at loci.formats.Memoizer.loadMemo(Memoizer.java:888)
    at loci.formats.Memoizer.setId(Memoizer.java:666)
    at qupath.lib.images.servers.bioformats.BioFormatsImageServer$BioFormatsReaderManager.createReader(BioFormatsImageServer.java:1339)

They are reported here and caused by a change in the latest release of Java. I believe they shouldn’t stop the script working, but I’ll look into reducing them on the QuPath side.

2 Likes

The error is also mentioned here

2 Likes

Ah thanks @phaub I’d forgotten about that.

Upon closer inspection, the error occurs when the normalization is invalid: specifically, when the 1st and 99th percentiles give the same value.

I’m not sure what QuPath should do in that case. Certainly it shouldn’t fail completely, but I don’t know if it should just not normalize at all, or try using the min/max values… or give an image entirely with zeros or some other value. I’ll need to give it more thought, since the ‘normalize’ op can be used independently of StarDist and so ought to do something sensible in such cases.

1 Like

Slightly off topic, but it is interesting that the CMU-1.svs opens much more slowly in 0.3.0 than in 0.2.3 or 0.2.2. Almost instantly in 0.2, but takes 5-10 seconds to open in 0.3. Not the end of the world, but oddly slow. No errors or particular notes in the log in either case. In both cases it opens via Openslide with the same pyramid levels. Not sure why the slowdown.

As with the thread indicated by @phaub, I do not see the same errors in 0.2.2 for the indicated areas. It clearly “does bad things” in those areas, though.

image

2 Likes

Well-spotted, hadn’t noticed but I think I know the problem – will investigate now.

To be clear, the bad things are in v0.2.2 – right? Conceptually, normalizing by percentiles in patches that contain nothing is expected to give bad results – but not to crash.

2 Likes

Yes, bad things are in 0.2.2, crashes with the above error are in 0.3.

2 Likes

Thanks, I’ve fixed the normalization issue (I think) – proposed changes are at More fixes for v0.3 by petebankhead · Pull Request #716 · qupath/qupath · GitHub

3 Likes

@petebankhead Thank you for the great imput.
I have gone through the fixes for v0.3 #716 and seen the script but I am handicaped how and where to include it in my script above to overcome come the problem of normalisation for instance.

I will be delighted if someone helps me with where to include the fixes or repalce the initial norm,alisation in my script above. Thanks for your your input @Research_Associate , @phaub

1 Like

Hi @Benjamin_Igbo check out StarDist in QuPath Normalization issue - #5 by petebankhead

3 Likes

Hi @petebankhead,
Thank you so much. This the inclusion of the new normalisation script as posted StarDist in QuPath Normalization issue - #5 by petebankhead has worked perfectly.
I also noticed that the amount of Memory allocated to Qupath has also played a role on how fast the detection results appeared.

1 Like