Exception during execution of SimpleFilter filters

Development
1

I am currently trying to test different filtering methods in the UI which will later be automated through python. I am using a volume of DICOM images and I am getting an error on several different SimpleFilter filters. If i try to filter using the LaplacianImageFilter for example, using the default parameters and using my volume as input, I will get the following exception when running the filter:

Exception thrown in SimpleITK LaplacianImageFilter_Execute: d:\d\p\slicer-481-package\simpleitk\code\common\include\sitkMemberFunctionFactory.hxx:196:
sitk::ERROR: Pixel type: 16-bit signed integer is not supported in 3D byclass itk::simple::LaplacianImageFilter

I can’t find much about the error, does anyone know how to fix it?

2

You need to cast the input images to a supported pixel type using “Cast Scalar Volume” module.

3 Likes
3

ok, that seems to have fixed the issue. however, the information on what the supported pixel types are for a given filter aren’t easy to find. I was able to use trial and error for the LaplacianImageFilter and found that it only takes in float and double, and after looking in the header file for the declaration here, I can see that there is a check for floating point here:

itkConceptMacro( InputPixelTypeIsFloatingPointCheck,
     ( Concept::IsFloatingPoint< InputPixelType > ) );

however, this isn’t listed anywhere else that i can see on the main file, and the input parameter only says that both input and output need to be of the same dimensionality.

thanks for the response.

2 Likes
4

Yes, I sometimes find this difficult, too.

@blowekamp Do you have a suggestion how to address this?

5

For filters which just take one input, it is quite easy to know what is accepted. If you look at the SimpleITK Doxygen e.g. LaplacianImageFilter, they have a member typedef called PixelIDTypeList which is the input pixels types supported by the filter defined by a “typelist”.

For multi-input filters the image types are generally expected to be the same dimension and pixel type. However “Mask” images are expected to be of pixel type uint8_t. There are a handful of filters which are “dual dispatch”, meaning the support different image types for their inputs. This include the LabelStatisticsImageFilter, MaskImageFilter, LabelIntensityStatisticsImageFilter etc. These conventions are documented here.

Determining the output image type is admittedly difficult. It can be dependent on the input image type(s). Even looking at the instantiated ITK filter’s template arguments does not always show the output image type. You need to look at the ImageToImageFilter ancestor of the instantiated ITK type.

Yes this situation should be improved. I am open to suggestions and a discussion on what should be done to improve it. Documentation in the SimpleITK class description? Runtime access?

1 Like
6

Thank you Brad. I think the main pain point is that the error message is Exception ... Pixel type: 16-bit signed integer is not supported in 3D byclass itk::simple::LaplacianImageFilter - it does not give a clue about what pixel type is supported.

It should not be too difficult to generate a link to the doxygen page of the filter. This could be useful for other purposes anyway, to learn what is the meaning of different parameters, etc.

However, for me it is not obvious how PixelIDTypeList tells what the accepted input pixel types are.

typedef RealPixelIDTypeList itk::simple::LaplacianImageFilter::PixelIDTypeList
Define the pixels types supported by this filter
Definition at line 78 of file sitkLaplacianImageFilter.h.

Is it the Real word that indicates that it requires floating-point input?

1 Like
7

Yes. As is frequent in Doxygen, and C++ conventions there are nested types that need to be clicked through. You can find this definition:

typedef typelist::MakeTypeList<BasicPixelID<float>, BasicPixelID<double> >::Type itk::simple::RealPixelIDTypeList

Although that still may not be clear to many…

So you suggestion is to improve the error message when the image types are not supported. Either by listing what is supported, or linking on where to get more information?

8

Yes. Since currently it is a bit difficult to decipher pixel type info from doxygen, either doxygen page generation should be tuned or somehow SimpleFilters should figure out what the pixel type is and display that to the user.

9

Is the finding of the input pixel type for the simple-filters been simplified yet or still we need to do trial and error with Cast Scalar volume ?