Using SimpleITK with Segmentations

Development
1

Using the VTK oriented image data from ITK seems a bigger hassle than choosing another filter, but I’ll look into this one too.

2

If I want to use an ITK filter I usually put a wrapper class in vtkITK. I haven’t tried with vtkOrientedImageData, but ITK supports oriented image data, so it might be doable (when we start working on adding orientation support to VTK images, this may be a good case for testing how orientation information can passed through the VTK pipeline). But we can just do what we do for all other VTK image filters (convert input to simple VTK image and then restore orientation information in the output image data of the filter).

3

For me it’s the other way around - I always stay away from VTK when operating on oriented images, and get them into an ITK representation first. Here’s the latest place where I had to do it, in case it can help:

You can next use use SimpleITK LabelShapeStatisticsImageFilter to get the centroid: https://itk.org/SimpleITKDoxygen100/html/classitk_1_1simple_1_1LabelShapeStatisticsImageFilter.html

4

Thanks for the suggestions!

@fedorov Creating a node for the labelmap of one segment and adding it to the scene is an excessive workaround for such an operation. Also it goes against what we wanted to achieve with segmentation nodes (that there are no stray unconnected nodes around in the scene containing intermediate and potentially invalid data). I see how this is easy to do, and if you clean up afterwards (I hope you do), then it’s not too bad, but this is not an elegant solution either. I just looked at the function in segmentation logic, and adding the node to the scene does not seem necessary. Is it needed for SimpleITK? If not, then having a node which is not in the scene is much better.

@lassoan Similarly, implementing a vtkITK wrapper is the “hassle” part I was referring to.

There are many solutions here, and many of them sound equally good (or rather, bad), but it’s still a hassle to use ITK filters in general. When Hongtao gets to the stage when he needs this part, I’ll try to choose the least bad solution.

5

It would be nice if in designing Slicer functionality, such as Segmentations, you guys appreciated the reality that developers would want to be able to use SimpleITK for the segmentations and image data. If you provided convenience functions to get SimpleITK image, all of those “dirty” workarounds would not be necessary, and developers would appreciate it (I would for sure).

1 Like
6

ITK is somewhat difficult to use in Slicer because ITK’s generic design and also because most Slicer classes are VTK classes. SimpleITK is great but it’s a huge additional layer and there are still some inconveniences (such as importing/exporting images, running in debug mode, etc.) but these may improve in the future.

We already have Segment editor effects implemented using SimpleITK, for example the watershed effect.

1 Like
7

Andras, the way you get data into SimpleITK in the effect you linked is pretty much the same that I do in the code I shared. I am not sure I understand your argument about SimpleITK being “a huge additional layer” - it is already part of Slicer, there is no extra layer to add. I personally find SimpleITK a lot easier and more intuitive to use than VTK classes.

8

I agree that it would be nice to have a more direct way to get SimpleITK images from segments.

If there is a way for the ReadImage function to specify a scene (which is not the Slicer scene just a temporary scene for example), or it is possible to convert a node that is not part of any scene, then it is already better than adding a node to the Slicer scene that emits lots of signals and may contain invalid data later (which are the two issues that make it dirty in my eyes). If not, then SimpleITK could facilitate easier conversion.

Segmentations needed to be written in VTK, because the entirety of Slicer (i.e. MRML) relies on VTK, and it is much more direct to display VTK objects, such as image data and poly data. This does make ITK or SimpleITK less powerful. They are powerful. Still it’s hard to dispute that it is not straightforward to use from the VTK-based Slicer. If there are ways to mitigate this, then let’s go for it!

1 Like
9

Yes, this is how you can use SimpleITK in Slicer now. As Csaba pointed out above, if SimpleITK utility functions worked with private scenes then it would allow cleaner use of SimpleITK. I would add that it should be possible to refer to nodes by node ID and it would be nice to have convenience functions for non-image data I/O (transforms, models, markups, …). Most of these could be improved with not too much effort and it would worth doing it. It’s just a matter of priorities.

Large: I mean that binaries are large (160MB, about 2x the size of entire VTK, 4x larger than Qt) and increases Slicer build time buy about 20%. Slicer includes it by default, but projects that don’t need additional ITK filters (or use it from C++) build their custom Slicer without SimpleITK. Additional: it is an additional “simplification” layer on top of ITK (it is not a simplified version of ITK that replaces ITK with a smaller or simpler version).

We all agree that SimpleITK is great and it should be easy to use it for processing segmentations. While examples exist already, we should keep adding more examples, convenience functions, and improve documentation to help users in this.

1 Like
10

Makes sense.

Since we never build custom Slicer binaries for any of our applications, this has never been an issue for us.