OverlayOutlines cannot specify thickness in pixels anymore?

I am thinking of updating my cellprofiler pipeline from 2.2 to 4.0. but while in the earlier version I can numerically set the thickness of the outline in pixles, in the newer version I can only select “thick” This is just 2 pixles wide and cannot see at the resolution I need to.
Not being able to see the outline is kind of a dealbreaker for me.
I see this issue was raised before but there was no resolution.

Are there any work arounds or any plans to add the old flexibility back?



A few years ago the outline drawing functions were replaced with scikit-image’s implementation, since this is capable of drawing in 3D images. Unfortunately the skimage version doesn’t offer the ability to change the diameter of an outline, though they may consider doing so at some point if asked.

One potential workaround here would be to use the DilateObjects module to expand the objects by x width, then use MaskObjects to ‘subtract’ the original object set, creating the set of outlines you want to draw. OverlayObjects could then be used to draw those custom outlines.


Dear David.Thanks for this and the explanation.

I had three different colours for outimes, one for a different classes of objects, all on a single image, with each very specific order of being overlaid (on top of each other so only one colour is visible depending on which class they were a member of ). Is that possible in what you propose?

If what you propose might work, is is the basic approach in a pipeline somewhere, that might give me an idea about implementing it as I cannot quiet, follow what you are suggesting.
Alternatively, if this approach or other options are slow to process or very complex to implement I might just continue to use version cellprofiler 2.x

David’s approach in general should work (though for 3 object sets, you’d need to add that 3-module “suite” 3 times, with the final OverlayObjects steps in the same order as your current OverlayOutlines module); I wonder if another approach might be to use the Resize + ResizeObjects modules to make your images and objects smaller, perform your overlay step there, and then up-size the overlay image (which should also make the outlines thicker, albeit at some loss of “sharpness”).

1 Like

Thanks for the idea, but one question I have is how to I control the colour of each masked object, won’t they all be multicoloured from the IdentifyPrimaryObjects?


Hmm, you’re right, I had mis-remembered that OverlayObjects would let you set a colormap, but it does not (perhaps a feature request for future versions!). In that case, the downsample-overlay-upsample option might be your best bet.

1 Like

I think I found something, which if inelegant kind of works.
I have multiple modules ExpandOrShrinkObjects with “Expand object by a specified number of pixels” which is set to 2 pixels in one model , 4 pixels in another module…
Then all these objects are all overlaid in a single OverlayOutlines module , with the “thick” line option. This way you can specify colour of the outlines that can be spaced to make a big thick visible line.
it would be much better to be able to do this without all these extra modules, like in the earlier versions. Thanks for the help.

Because we now use skimage’s implementation, we can’t add that feature back unless they decide to add it; sorry, we know it’s a pain!

1 Like

While I think there is a work around to the thread issue , I wondered what the downsides were to continuing to use version 2.1 (which does not have the issue) and not attempt to upgrade –for I am sure it is big upgrade for the vast majority of users to 4.X–
One advantage is that I can think is being able to keep java up to date without having to maintain legacy versions, but otherwise I am not so sure.
If anybody is still monitoring this helpfully resolved thread, I wondered if they might have the time to convince me that upgrading my pipeline is worth the effort ( I hope that fact that the threshold method Global>Kapur I was using in IdentifyPrimaryObjects is no longer an option will be resolvable).

I mean, the best image analysis is the one that works for you, so on the one hand, if your current workflow still works, go for it.

Sticking in that version, though, you don’t have access to a lot of new measurements, a lot of new modules, significant speed upgrades, or any bug fixes (not to mention on many newer OSes, it’s no longer possible to run 2.1.1 at all, so it makes it harder for someone else in the community to adopt your solution if that’s a thing that matters to you), so at whatever point your workflow needs to change, it probably makes sense to move to the newest version at that point. RE: Kapur, all the thresholding implementations have changed between 2 and 4, so you would have had to re-assess thresholding at the point of upgrade anyway; we removed some methods because we didn’t feel they performed as well as the new ones we added.

1 Like

Thanks, I am persuaded to upgrade.