Dilate bug

I have got a strange bug when using dilate on a skeleton, see attached image DilateBug.png. When saving the image before dilating and then open the image and dilate it works OK, see attached image DilateOK.png. It does not matter which structuring element that is used, I have tried disk 3, disk 7, disk 15, square 3, etc., all with the same result.

I have attached the pipelines I have used and input and resulting images.
debug.zip (2.99 MB)




Thanks for the test case; we’ve filed this as github.com/CellProfiler/CellPro … ssues/1150.
-Mark

Ignore below, Pettar, I’m working on it, github.com/CellProfiler/CellPro … ssues/1150 is the problem. It might be the structuring element…

[quote]Hi Pettar, thanks for the report. I’m having difficulty reproducing the problem, though. I load debug.cpproj and run, but the results look reasonable.

I’m thinking that perhaps my version of CP and its dependencies yield a binary image, whereas yours yields a floating-point one. Morph would then use a greyscale dilation, possibly with different results. So I think I need to know whether you’re running a binary distribution or from source, whether you’re on a Mac or PC and what version of Numpy you have if you are running from source

python -c “import numpy;numpy.version.version()”

to get the numpy version.

Still investigating, maybe I will still be able to reproduce the problem.
[/quote]

–Lee

The last morph step is being done with a masked image and the mask is “DilatedRemovedSpurs1”. That’s a pretty sparsely populated mask - about 1% of the pixels. Operations on a masked image are always a little difficult - it’s often hard to interpret what it means for a pixel not to contribute to the result and currently, CellProfiler doesn’t show you what pixels are masked, so the pixels that are unaffected by the dilation are probably either masked pixels or are adjacent to them.

I’ve done a pipeline which, as its last step, produces a dilated skeleton on a version of the pipeline where I used ImageMath’s multiply function to remove the errant pixels rather than doing it with masking, I told ImageMath to ignore the masks from the spur-removed and endpoint-removed images and that’s a key step - the mask is on the original skeleton (which is no mask at all).,

–Lee
nomasks.cppipe (16.7 KB)