IdentifySecondaryObjects - propagation bug

identifysecondaryobj

#1

When trying to identify secondary objects using the propagation algorithm, sometimes part of the cell border seems to be encountering an invisible boundary. I thought this may be due to the gradient of the input image, but even if I binarize the image prior to the identifysecondaryobjects module, the borders are still fixed.

  • I’ve only noticed this when the cell area (but not the object boundaries) is touching the edge of the image

  • Changing the regularization factor can make the border more zig-zag or straight-lined, but does not significantly change the general location of the border

  • Changing the threshold correction factor does not change the boundary

There is no reason why the border should be drawn here. There are no other objects taking up this space, and there is no gradient (in the binary image) and could be responsible for the borders. Any thoughts on what this could be?

I’ve attached a short pipeline and image set to demonstrate this. This pipeline was created in 2.1.1 but I’ve also noticed the same problem in 2.2.0

Pipeline211.cpproj (538.7 KB)

Here is what I get when I run the pipeline. The east/south borders are basically “fixed”.


#2

Do you mind posting the images produced by IdentifySecondary so we can see the problematic behavior you’re describing and make sure that when we run the pipeline we get the same thing?


#3

I’ve updated the original post to show the identified objects. The problem is with the 3 straight-ish edges (They’re only straight because the regularization factor was high during this run.


#4

I can reproduce this in my hands. I’m not sure why this is happening, but my best guess is that there’s some sort of assumption in the code for Propagate that the object should be expanded out in a roughly symmetrical fashion, and once it stops expanding in a couple of directions it stops looking for other spaces to fill. I’d have to spend a lot more time poking around in the source code to understand why though.

FWIW, the Watershed method reproduces your image a lot more closely in my hands, though it does also do some minor edge-respecting erosion.


#5

Are there any updates with this potential bug? We’re familiar with the watershed method, but propagation has been working a lot better on our images. Thanks!


#6

Often problems like this come down to some weirdness in a particular image and not as real bug, and can take Ages to figure out… so we tend to be a little less enthusiastically Pursuing them. :slight_smile:

Tell me this: does the result make more sense if you do NOT exclude border objects in the nucleus-identifying module?


#7

I ask because at least on my phone, I see nuclei peeking at the edge of the image… My guess is that those nuclei are claiming the cytoplasm that is thought to belong to them.


#8

Aha! I figured it out. There are other objects taking up that space- rather, the ghosts of other objects. :ghost:

If you set the regularization factor to 0, you get the shape outlined in green here; when you overlay it against the DAPI image, you can see that there are some partial nuclei there (and I confirmed in IdentifyPrimary that they were there and had been discarded because they touched the border.) This happens whether they’re thrown out for size purposes, for touching the border, or just when they hit your filter for CYTO intensity- they’re still claiming the space.

I’d have to give some thought as to whether IdentifySecondary refusing to overlap with objects that have been removed is actually a bug or a desired behavior, but it’s an explanation at least. Setting the regularization factor to 0 will at least allow you to get most of the cell.

Edited to add: Aww, man, @Anne_Carpenter, stealing my aha moment like 5 minutes before I finished typing up the post? Not cool. :wink:

Also, I’ve filed a GitHub Issue to see if people agree whether or not this is a behavior we should change; if so we’ll get on it.


#9

I think this is unlikely to be changed in the future- when I asked whether there was a reason IdentifySecondary respected filtered objects on the border I got a good reason from the always-wise @mbray:

I don’t have an instance on me right now, but think of it this way: the secondary cell really is there but you’ve chosen to filter it out since the nucleus touched a border. If a neighboring secondary object ignored the missing cell, it would simply fill in that space, and he boundaries would no longer look the way you’d expect, i.e, respecting the boundaries of the neighbors. Rather, it would (most likely) look like two cells incorrectly merged together.

I think the above case is more typical than yours , where you can tell definitively where the boundary is because only one of your cells appeared to have your cytoplasmic marker, so the behavior of the module is likely to stay that way.

Sorry!


#10

Yep, it’s intended behavior! Sorry for stealing your thunder. :smiley: