Equivalent to Cellprofiler's IdentifySecondaryObjects / Distance N in Fiji?

Another Fiji question where I’m not whether sure I am missing something obvious as I don’t normally use IJ for these things myself (but want to outline a way for facility users who like to use imageJ).

I am looking for a way to Dilate/Enlarge regions by up to n pixels, but without encroaching into neighbouring regions. The typical scenario is dilate from the nuclear marker to (an approximation of) the whole cell in order to measure intensity. Watershed is not a good idea as the channel in which intensity is to be measured should not be used for segmentation.

I can come up with a workflow that could be turned into a macro (below), but I wonder whether there is a simpler built-in method that I am overlooking.

Outline of workflow:

  • Given ROIs (i.e. from nuclear segmenation)
  • Create label image from ROIs using macro as outlined here.
  • Create binary image from label image.
  • Use morphological dilation to enlarge binary mask by desired number of pixels n .
  • Use Seeded Watershed in MorphlibJ, using dilated binary image as mask and label image as seeds, with binary seeds deselected
  • Threshold resulting foreground object to find objects with label > 1.
  • Run analyze particles to turn objects into ROIs.

That works, but it seems incredibly complicated.


Hey Volker,

it’s awesome to see that we (as a community) solve the same problems again and again by writing macros because there is no easy-to-use tool for that. :slight_smile:

Here comes my #clij macro (notebook) doing something similar to what you mention: https://clij.github.io/clij2-docs/md/tribolium_morphometry/

I use it and similar code literally every day - always GPU-accelerated, always processing time-lapses. What I’m saying: If you setup a task-force fostering these easy-to-use plugins, I’m on board :muscle:


1 Like

Hi Robert,

thanks once again for your quick reply.

Regarding your clij notebook. I don’t think it quite does what I want as it appears that the object with the higher label number starts overlapping (cutting into) objects with lower label numbers, see the two cells highlighted by the arrow as an example:

You would not get this with the Distance-N method (but maybe this is just an artefact from showing the volume in 2D and no actual overlap?).

Regarding your comment regarding the community reinventing solutions to the same problems over and over again, I agree. As far as branching into ImageJ plugin development: I would be spreading myself to thin, I’m struggling already to find time to contribute to the Python bioimage ecosystem (which I am more familiar with).

1 Like

That’s just your visual impression because the operation runs in 3D and you’re looking at the maximum projection of the result.

The underlying filter does not overwrite any pixel with intensity unequal to zero:

Good to know, even better to have it on the GPU, thanks !.

1 Like

The procedure you are looking for is called “dilation without merging” or “dilate-no-merge” (two plugins to do this in 4 and 8 connected binary images exist in the Morphology collection).
or the Morphology update site in Fiji.
It is an extremely slow method for large images because it involves dilating sequentially every labelled object individually followed by a logical operation.
Hopefully there is a quicker algorithm for this.


Thanks @gabriel, I will give this a go. I think a faster algorithm can be achieved with the distance transform, but I just want to have something I can refer users to now.

1 Like

The problem is that you need to check whether there are any labels that merge at a particular distance.
If you find a faster way of doing this, please post it here.

1 Like

Hi @gabriel,

as I mainly use Python I have previously always used the few lines of code from the CellProfiler source:

As they are generally useful, I will actually try to extend this and open a PR to scikit-image.

A lot of the heavy lifting is done here using the index image returned by the distance transform in scipy.ndimage and numpy's fancy indexing. I haven’t looked at the computational complexity or done comparisons to iterative dilations, but for me it has been fast enough to be useful even for large expansion values.

I do not enough about the Java/Imglib/Imglib2 ecosystem to know whether there is a simple equivalent.

1 Like

Thank you. Does this just prevent a label being dilated or it dilates just the bits that can be dilated without merging into other labels?

1 Like

The latter. It will dilate the labels until they are direct neighbours or up to n pixels (whichever happens first).

1 Like

Thanks. Sorry to keep asking. Do you mean “adjacent” or with a 1 pixel background space between them? (which sometimes can be 2 pixels space due to the discrete space and regions dilating in parallel).

1 Like

adjacent, no gap IIRC, but I will have to confirm

1 Like

I see, thanks. I am thinking of a faster algorithm that preserves the binary region count.
Actually these label dilations always have some bias. In the case of allowing adjacency of labels, if two labels are 1 pixel apart we cannot dilate both, and some arbitrary choice needs to be made as to which label gets dilated and which doesn’t and this of course makes the result dependent on this and non-unique.

1 Like

Good point, I will have to test the edge case you mention.
Typically I deal with objects that are >> 1 pixel so the error introduced in the edge case of objects 1 pixel apart is usually not significant for what I am doing. But I see your point when dealing with many small particles. I guess (depending on the implementatoin) it would be more of a random error (instead of a bias) though.

1 Like

It is not only the case of small particles, but convoluted boundaries as well (think of inter-digitating skeletons). For example, if you sort the dilations by label number then the smaller label index regions may get dilated first every time. That would produce a different final result if you rotate the image 90 degrees (as the label assignment is most often based on raster scan order in the image).


Hello everyone,
while reading this, I’ve been wondering if CLIJ / (or any other GPU based parallel calculations) might be useful to speed this “nowadays”? :thinking:

@haesleinhuepf am I wrong? (sequential calculations different than parallel => bad idea?)

1 Like

See the link in @haesleinhuepf 's answer at the top.

1 Like

Yes :slight_smile:

But we may build a nicer user interface around it. I think that’s where the discussion is leading us

1 Like

My bad,
I didn’t realise the embryo example was doing it

and the overlapping spots distracted me :pensive:.

1 Like