Cellprofiler: Object module request: IdentifyOverlappingObjects

[bethac07]

Believe you're already working on this, but as an official request- as of right now the only way to parse overlapping objects is via Untangle worms, which is a good interim solution particularly since it's trainable but suffers from the assumptions that the objects in the end should be worm-like. The ability to create and work with non-worm like overlapping objects would be great!

[braymp]

Something like this would be great to neurons, esp. doing the right thing with an overlapping network of long axons/dentrites. Or for cells that have overlapping extensions in general.

I do wonder, though, how such a thing would work with more generic objects, e.g., your average pair of touching cells. With worms, thee's a heuristic to tell where a worm ends, but how would it know where a typical cell edge ends, if not the neighboring border?

[dlogan]

Can you clarify the request? You can use RelateObjects and MaskObjects, to define object relationships. Or do you mean that to measure things about these new objects, one needs to (re)Identify them? .. Perhaps I am hitting on another solution: Can we use RelateObjects to define a new overlapping object class itself, rather than a new Identify* module?

[AnneCarpenter]

Our ability to "tell" whether objects are overlapping is fairly limited based on the shapes of the objects themselves. I propose that it's really only linear objects for which our current algorithms have any ability to tell whether two objects overlap, right?

If that is true, it would argue that the practical implication of your request is that you want certain modules to use ijv storage format (or whatever redesigned way we have to store overlapping objects, see #2239 ) so that the output can be overlapping objects.

This would be I think only the following modules: (a) IdentifyDeadWorms and (b) a new IdentifyPrimaryLinearObjects (or better yet a fork at the beginning of IdentifyPrimary asking if you're dealing with blobs or lines).

I think @bethac07 has been pondering whether DeadWorms would work for a current project or whether a better linear-object detection algorithm is needed. Once she has decided that, we should change the title to reflect whether it's a request to add overlapping objects to be exported from IdDeadWorms, or whether it's a request to add linear object algorithms to IdentifyPrimary.

[braymp]

Would be good to add to IdentifySecondary too. I think the more common use case would be IDing cells from primary nuclei with long overlapping processes (e.g., neurons)

[bethac07]

Unfortunately IDDeadWorms isn't going to be the solution, at least not without some code hacking; Carolina was right that you can get it to make overlapping dead worm "diamonds" if you fiddle with the settings (see below), but the diamonds aren't what are returned as the objects, it's the darker bits in the center. When you use the dead worm centers to propagate out secondary objects as suggested in the help the secondary objects don't overlap to the best that I can tell (I did some checking with areas and axis lengths to be reasonably sure).

[AnneCarpenter]

I'm not following the practical implications... is the request, then, to adjust the code to save the diamonds as overlapping objects (which you're saying the algorithm is already capable of identifying)?

And also allowing it to look for rectangular objects, or maybe any arbitrary shape, as a bonus?

Indeed, I don't think IdSecondary can create overlapping objects, but if the above is accomplished that would not be necessary?

Note: none of this sounds suitable for neurons, where the stick-fitting or diamond-fitting approach would fail. that would require some alternative approach.

[bethac07]

Apologize for being unclear- even if we had the diamonds, we would still need to extend them with IDSecondary to fill the larger space in every use case I can think of, and if IDSecondary doesn't support overlapping objects then it's moot to try to adjust IDDeadWorms to get the diamonds out in the end.

IDDeadWorms pretty explicity defines how the diamonds are created and shaped, so it's possible I can hack that to look for sticks instead. If and when I manage that, it'd obviate the need for IDSecondary in this particular use case and we can see about getting it to export the things that we need it to.

I think it's worth trying to figure out where we might benefit from overlapping objects and where the tipping point will be when we actually try to make a general method to find them- I'm not sure we're there yet but I think weight is shifting that way.

[AnneCarpenter]

I'm commenting that this ultimately should be called IdentifyLinearObjects (because I keep searching for it that way).

[mcquin]

Overlapping structures do not make sense in computer vision.