Add physical space conversion to Median Image Filder

[muratmaga]

MedianImageFilter CLI module expects the neighborhood size to be entered in voxel-space (e.g, 2,2,2). Given that everything else works is reported in physical space, this is a confusing behavior.

I suggest revising the UI so that first the input and output volumes are specified (so we know what actual image spacing is), and then have the user enter the kernel size in physical space and display the corresponding number in voxel space next to it (similar to the smoothing and margin filters. That way the behavior would be more consistent.

[pieper]

These CLI UIs are autogenerated so it's not feasible to do conditional processing. But someone could wrap the CLI in a scripted module that implements the features you described. Something like the SurfaceToolbox for experimenting with different parameters and easily switching between input and output would be nice. It could be called DenoisingToolbox or something.

[lassoan]

CLI modules are not capable of doing such things. It is a wrapper for an executable algorithm, and so interactive behavior (such as analysing the input data and displaying the result on the GUI) is not supported in any way.

For this reason, I do not consider CLI modules as end-user modules, but as building blocks for interactive loadable modules. The automatically generated GUI serves as a nice testing interface for developers, but usually not friendly enough for end users.

Therefore, instead of trying to improve CLI module usability, I would suggest to add a convenient load able module (Pyrhon or C++) to address whatever the end-user need is.

Can you describe the end-user need? What kind of smoothing do they need to perform on what kind of images for what reason? Do they know the desired kernel size in mm or pixels in advance or they would set it visually?

[jamesobutler]

My group created its own UI through a scripted loadable module to display median filtering options in physical space, but also included information displaying the kernel size in voxel dimensions. We display the voxel size in red based on our own determined metric of whether we think the kernel size is too large where performance is likely to be poor with the application hanging for a bit.

In our case we are actually utilizing the median image filter as provided through SimpleITK. This filter is also similarly used in a CLI format through the "SimpleFilters" module.

Additionally, it is a bit odd to have both the "MedianImageFilter" C++ CLI loadable module and also the "SimpleFilters" scripted loadable module because they provide the same type CLI interface for running the ITK Median Image Filter. My assumption is that "MedianImageFilter" module still exists because Slicer can be built without Python support, although I'm not sure how common that is amongst Slicer custom applications today with the growth of python development. Things could potentially be simplified by not including "MedianImageFilter" if the "SimpleFilters" module is also going to be included.

[muratmaga]

Can you describe the end-user need?

We have occassional scattering artifacts in microCT scans that median filter is helpful. (before) (after, this is too aggressive though, so not a good example)

We have to empirically try the kernel size (typically start 2x2x2 and then adjust upper/lower). So from usability perspective having the kernels in voxel space is actually nice. But it goes against everything else in Slicer, and is kind of confusing to the new user.