Question about Positive Cell Detection

Hi there,

I am using QuPath for a while now and it’s a big improvement for analyzing scans!
After updating to M5, I continued with creating my own script for the detection of positive cells with a NiDAB-chromogen without background staining.

One thing I have noticed is the following:
For the detection of positive cells I’ve set the threshold up to 0.36, unfortunately QuPath detected cells as positive below this threshold (0.347; see picture blue circles).

Did someone already had this after creating his own vector stainings? Or is this something what’s happened in the new milestone version?

Thank you!

Kimberly

Hi @K.massy,

I haven’t seen this and I haven’t been able to replicate it :confused:

I assume the selected cell has been called positive although I can’t see that in the screenshot.

Did you run the cell detection again after changing the threshold in the dialog box? Note that changing the threshold has no impact on cells that have already been detected (unlike when setting an intensity threshold when interactively training a classifier) - the detection must be run again.

If the problem persists and you only see the issue with a script, it would be helpful if you can share the script and also verify yourself whether it happens in earlier versions, as I am unable to do so.

I also realllly tried to replicate this but was unable to. I thought it might happen if I played with the background enough, but my overlaps look pretty perfect, both with smoothing enabled and a non-white background.

One thing to note, I think, is that if you run “Estimate stain vectors,” it does not update an open Positive Cell Detection window. You have to close that window and open a new one with the newly set color vectors. At least that used to be the case, I haven’t extensively tested that in M5.

Perhaps you could give us a script of the entire workflow from the workflow tab?

Thanks for your reply!

I’ve checked the script in milestone 4 and also here I’ve seen the same problem as mentioned before.

This is the script that I am using:

setImageType(‘BRIGHTFIELD_OTHER’);
setColorDeconvolutionStains(’{“Name” : “NiDAB”, “Stain 1” : “Background”, “Values 1” : "0.46964 0.58371 0.66236 ", “Stain 2” : “NiDAB”, “Values 2” : "0.59992 0.66163 0.44984 ", “Background” : " 232 229 239 "}’);

image

Could it be that the problem is that the last value of Stain 1 is the same as the second value of Stain 2 (0.662)? I don’t know for sure if this is the issue in detecting positive cells within the applied settings.

Thanks again! @petebankhead @Research_Associate

@K.massy The same values in the stain vectors shouldn’t matter, although calling your first stain ‘Background’ can be confusing (since ‘Background’ is also the term used for the whitespace used to normalize values). I also find it strange that your NiDAB is bluish while background is more brown. I think it would be good to look at creating a new script to set stain vectors.

Despite that I still couldn’t replicate the issue even using your script. Could you describe exactly the steps you apply in order (from opening the image to seeing the issue), ideally with an example image (possibly cropped) that can be used to demonstrate this?

I have been using the OS-2.ndpi image in my unsuccessful attempts to replicate the problem.

Thanks again for your reply @petebankhead

I will try to explain the order of the steps I perform:

  1. First I open a scan fully stained with NiDAB chromogen without a nuclear counterstaining.

  2. The image type was set on brightfield (other). Subsequently I selected a cell inside the tissue which is greyish but interpreted as not being positive (blue rectangle). Then I selected this blue rectangle as stain 1.

  3. As stain 2, I selected a clearly black (NiDAB-positive) stained cell (red square) and called this was NiDAB (stain 2).
    image

  4. Afterwards I drew a region (big rectangle) including positive cells and non-positive tissue (greyish ‘tissue background’). Via analyze and estimate stain vector I provided the stain 1 and 2 values by clicking on the ‘auto’ button.



5. Then I selected a region to apply the positive cell detection function by using the rectangle.
6. I put the lower detection limit at 0.3 and clicked on run. Actually the problem did not occur this time, maybe due to the fact that I set the vector stains again.

I still want to know if I am doing this right to set my own vector stain settings? Since the colors of the vector stains are still brown and bluish, I am in doubt.

Thanks again!

Kimberly

Sorry for the 2nd message, but I encountered the error again by first saving the script:
setImageType(‘BRIGHTFIELD_OTHER’);
setColorDeconvolutionStains(’{“Name” : “NiDAB”, “Stain 1” : “-”, “Values 1” : "0.53034 0.55442 0.64137 ", “Stain 2” : “NiDAB”, “Values 2” : "0.61709 0.6541 0.43745 ", “Background” : " 234 232 242 "}’);

Then I applied the saved script on a different scan (same performed staining) followed by a cell which is detected as being positive but is having the value below the lowest threshold of 0.3.

Kimberly

Ok, can you confirm you press ‘Run’ to detect the cells after you have changed the threshold?

Actually it looks like you have just typed the number in the threshold box - but it is still in focus/editable. Try clicking something else within the dialog box before pressing ‘Run’ - the actual threshold may not be applied yet because it thinks you are still editing it (because the little box containing the number is still active).

In the workflow tab you can see the entry each time you run cell detection and this should show the threshold that was actually used.

Yes I can confirm that I press the button Run after changing the thresholds :slight_smile: !

What about the points in my subsequent message?

That the number in the threshold box was still editable was because of the picture and to indicate what the lower threshold was. Even when we try it again and click at other regions, we still get the same value.
In case we performed a new detection, we indeed saw this in the workflow tab…

In the workflow tab, what is the threshold that is recorded whenever you get the ‘wrong’ results?

And what happens if you set the intensity classification later using the one-line script to set positive/negative from this blog post using setCellIntensityClassifications?

I can still find no way to replicate the issue. Might need a video/screencast to try to decipher what is happening or perhaps someone else can figure it out… it has not been reported as a problem before.

Note that the scripts you posted don’t work directly because they use ‘curly’ inverted commas. This formatting might have been introduced by discourse, if you use the ‘preformatted text’ button when pasting any scripts in image.sc then they should appear properly.

Thank you for the options @petebankhead

We applied the setCellIntensityClassifications. In addition, we encountered a cell which had a higher intensity then the set threshold and was not indicated being positive (see image below).

Beginning of next week I will check this again and try to make a video of the procedure I applied.

For now, many thanks for all your tips and help. Hopefully, we can solve this :slight_smile: !

Best wishes,
Kimberly

I noticed that in the most recent script, both stains have the same name. If QuPath is pulling values based on string matching names, that is likely to be a problem… I think. @petebankhead?

In the script it looks like the stains (collectively) have the same name as one of the stains… and another stain is called ‘-’. I can’t think of a reason why this would cause a problem, although probably best to avoid weird naming schemes while trying to figure out what is wrong.

If the problem doesn’t arise when using the default names of hematoxylin and DAB that would be good to know.

@K.massy a script generated from the full workflow (as @Research_Associate suggested above) that includes the detection would be helpful, rather than only the bit from before running the cell detection interactively. I am still having trouble following exactly what steps you apply when you see the issue, since when you listed all of them you said the problem didn’t occur… and it was only later that it reoccurred. I don’t know what exactly happened in between.

The best thing would be if you could show the problem occurs when you run a script only, with no additional steps involved.

It’s also not totally clear to me from your last answer: the problem happens both when you set the threshold during cell detection, and when you apply it later using setCellIntensityClassifications?

Finally, because the selected cell is yellow in the screenshot and the classification is obscured by the cell detection dialog, I can’t tell how it has been classified from the image. Moving the dialog out of the way or turning off the ‘Use selected color’ preference would resolve this.

QuPath’s code indicates that the threshold is applied using the measurements in the measurement list (here) - which are the same as the measurements displayed on screen - so I find it very mysterious.

I don’t feel I can make any new release of the software until understanding whether this is a bug that needs fixed urgently, or if there is some other reason why it’s happening - so I’m keen to get the bottom of it quickly.

Another, unrelated question. I didn’t see what operating system you were using. Is it Windows? Linux?

Hi there,

I’ve tried to made a record of the instructions in QuPath.
I upload it with a link to WeTransfer.
The WeTranfer link has a video record of the main problem; detecting positive cells below the threshold when using Positive cell detection

When I’ve made the video, I saw something happened after 5:00min. I set the threshold to 0.16 and QuPath detected a cell as positive below this threshold (0.1503). But when I’ve clicked on a other positive detected cell, the value of the first cell (0.1503) changes into (0.1832)…

The script that I’ve use was:

setImageType('BRIGHTFIELD_OTHER');
setColorDeconvolutionStains('{"Name" : "H-NiDAB default", "Stain 1" : "No stainingcolor", "Values 1" : "0.67343 0.57393 0.46593 ", "Stain 2" : "NiDAB", "Values 2" : "0.44038 0.6119 0.65699 ", "Background" : " 229 227 237 "}');

https://we.tl/t-ua9yBzL2qI

Could this be the problem?

Kimberly

2 Likes

Thanks, the video is very helpful. I haven’t seen this problem before.

I’m not sure I fully understand what is going on (and haven’t managed to replicate it), but as far as I can tell the classification is ‘correct’ - but sometimes the measurements displayed in that table are not.

My guess is that this is somehow connected with the rows of the table not refreshing immediately when they should - specifically around the row that is selected. It looks like the first measurement displayed after re-running the cell detection can retain a memory of the corresponding row from a previously-selected object, and after you click around some more cells this corrects itself and becomes consistent.

(This kind of makes sense with the way tables are rendered in JavaFX; the rows/cells are reused where possible. But I can’t tell if this is a JavaFX bug or a QuPath-specific one…)

Could that be the case?

Even following these steps I can’t get it to work for me but from the video it looks like this is occurring. You can also use Measure → Show detection measurements to get another table displaying the measurements… which I think/hope will agree with the results you see under the ‘Annotation’ tab after additional clicking.

1 Like

Thanks for your reply!

I think that is the case. However, I’m happy that my way of using the classification is ‘correct’ :slight_smile: I can continued with using QuPath for analyzing positive cells on this way.

I’ve also checked the detection measurements and these results are the same as the results I’ve seen under the ‘Annotation’ tab.

Many thanks @petebankhead for helping me, it was very usefull!

Best wishes,
Kimberly

2 Likes