bug or feature SLIC SuperPixel Segmentation?

I am trying to use the SLIC SuperPixel Segmentation algorithm in ITK.

However, it seems to behave in a strange way, generating areas that contain pixel values with very high intensity variations (for instance the eye region).

Am I missing something, or is this a feature of the algorithm?

My test image has spacing 1.25x1.25, dimension 256x256, and the example code is something like this:

	using ImageType = itk::Image<float, 2>;
	using LabelImageType = itk::Image<unsigned int, 2>;
	using SLICFilterType = itk::SLICImageFilter<ImageType, LabelImageType>;

	auto filter = SLICFilterType::New();

Seems I need to increase the number of iterations to get a reasonable result:


I would be interested in learning about your experiences using this method. Do you use it to segment slice by slice or you can add entire 3D blocks at a time?

I’ve experimented with ITK watershed segmentation, which looks very similar to SLIC. Watershed works in 3D and it is nice that you can specify some kind of spatial detail (may be similar to number of iterations for SLIC), but it was still nowhere as practically usable as Fast Grow Cut method.

What do you plan to segment with this? What is your segmentation workflow (what inputs the user specifies and how the user guides the segmentation when the contours require adjustment)?

1 Like

Hello Andras,

Perhaps the Insight Journal Article could answer some of your questions: https://arxiv.org/pdf/1806.08741.pdf

Yes, the filter works in N-D with scaler and multi-component vector images.


Thank you @blowekamp, I’ll give this a try. I’ve noticed that SimpleFilters module in 3D Slicer did not contain the json description for this filter but I’ve found it in SimpleITK repository. Could we simply update the json files of SimpleFilters module with the json files in SimpleITK?

You could give what’s in the SimpleITK repository a try:

1 Like

Thank you, it works! Should we simply update the json files in SimpleFilters with the json files from SimpleITK?

Hi Andras

I am planning to integrate it with our paint brush tool (i.e. 2D). Instead of brushing pixels, the user can brush superpixels. The idea would be to have a switch to quickly switch between pixel vs superpixel painting/correcting.

Best regards

1 Like

There is a script to do some subtree merge things that should be used:

There have been a few filter which have been removed from this Slicer module, that may cause conflicts and need to be manual fixed during the merge.

1 Like

the super pixels can be run through the LabelMap statistics filters to do classification and clustering on the super pixel regions to generate a rough initial segmentation.


I was interested in your comment about Fast Grow Cut and experimented a bit with the Slicer implementation.

What I feel is missing is the ability to lock specific labels, so they not are used as seeds, but also cannot be re-labeled (or traversed).

Without touching the fast grow code, I guess I could achieve that more or less by only providing seeds from other labels, and not copying the output to voxels that already have a locked label. However, then existing labels (say “Skull”) could not function as a barrier for growing.
Do you think the algorithm/code could be easily adapted to respect a mask (zero for locked voxels)?

This is indeed a very useful feature and I implemented it in Slicer’s Fast Grow Cut algorithm a couple of years ago. You can define the locked regions using masking section in the Segment Editor (you can lock a region inside/outside one segment, visible segments, or intensity range).

This demo shows masking with intensity range (but you can use any other masking option in Masking section at the bottom of the Segment Editor panel):

1 Like