We plan to release Slicer 5.0 soon. This is a major version change, which happens in about every 5 years and brings lots of new features and also trimming of old features that have been replaced by alternative solutions.
We are considering removing the following modules/features:
Editor module: old module for editing labelmaps, superseded by Segment Editor module
Label Statistics module: superseded by Segment Statistics module
Charts infrastructure: replaced by Plots module
DoubleArrays module: superseded by Tables module (that can store one or more arrays)
Annotations: being replaced by Markups module - we will keep this around until we add markups ROI widget.
MultiVolume infrastructure: being replaced by Sequences module - we will keep this around until all features are implemented in Sequences (currently missing importing from folder, plotting of two volumes)
Unused CLI modules: ExpertAutomatedRegistration (replaced by BRAINS and Elastix), Fiducial Registration (replaced by Landmark registration and Fiducial registration wizard modules), Resample Scalar Volume (there are 2 other image resample modules), DiffusionTensorTest, TestGridTransformRegistration, BSplineToDeformationField (it is available in Transforms module’s Convert section)
Lightbox view: replaced by Screen Capture module’s lightbox view mode
Let us know within a week if you have any concerns or questions.
Among these, I only care for ResampleScalarVolume, because of its simplicity for downsampling. Other resampling modules require reference images and whole bunch of other parameters. While CropVolume is also simple, it doesn’t let me specify downsampling as flexible as ResampleScalarVolume.
Crop volume allows resampling by a constant, with option of forcing to isotropic output spacing. Is there any other resampling strategy that you would use?
I like the ability to give the spacing independently for all three axis, which CropVolume lacks. Also, I have encountered axis rotations with CropVolume with interpolated cropping (an ROI fit to the volume extend, but not under a transform), which causes external programs to see it in a different space than the original one.
We use ANTs/ANTsR a lot and it causes problems for us:
> orig=antsImageRead('/scratch/MRHead.nrrd')
> rot=antsImageRead('/scratch/cropped.nrrd')
> orig
antsImage
Pixel Type : float
Components Per Pixel: 1
Dimensions : 256x256x130
Voxel Spacing : 1x1x1.29999542236328
Origin : 86.6449 -133.9286 116.7857
Direction : 0 1 0 0 0 -1 -1 0 0
Filename : /scratch/MRHead.nrrd
> rot
antsImage
Pixel Type : float
Components Per Pixel: 1
Dimensions : 130x256x256
Voxel Spacing : 1.29999542236328x1x1
Origin : 86.6449 121.071 -138.214
Direction : -1 0 0 0 -1 0 0 0 1
Filename : /scratch/cropped.nrrd
> test = antsAverageImages(list(orig, rot))
========================================Error in avg + img * weights[ct] :
Images do not occupy the same physical space
To force a volume to have the same geometry as another one, the proper way is to specify a reference volume. Typing many floating-point values manually is tedious and very error-prone.
There should be really no reason to manually specify arbitrary spacing values, but we can put it in advanced section somewhere in the resampling module that we finally keep.
resampling using a reference volume => use resampling module
cropping & resampling using ROI => use crop volume module
Using an ROI and reference volume at the same time rarely makes sense, but if there is some use case when this is needed then you can do an additional resample step after cropping. If only axis permutation is needed (e.g., because the ROI cropping resulted in an axis order that you don’t want) then this extra resampling will not cause any data loss: voxel values are not interpolated, they are only reordered.
It’s worth noting that the MRHead is a sagittal acquisition and the cropped result is axial. The CropVolume outputs are kind of arbitrary and based on the origin and orientation of the ROI box. It does make sense to me that we should try to match pixel orientation if possible, at least in the case when the orientations match. Also independent controls of the axis spacings makes sense for some use cases.
I have a very simple use case. I want to have MRHead.nrrd, or any volume to be downsampled in place without changing anything except for dimensions and spacing accordingly. ResampleScalarVolume does exactly that. CropVolume requires a ROI and causes a flip in axis, and ResampleScalarVector/DWI causes creates an cropped volume (see screenshot). So, unless we have a direct replacement of this behavior without our tools, I don’t think we can call ResampleScalar as redundant.
This is indeed a simple use case, but this should almost never be done. Anisotropic spacing negatively affects almost all processing and analysis operations, so it should be avoided as much as possible. Resampling is a lossy operation, so it should be avoided as much as possible, too. Therefore, if you decide to resample an image then you should almost always use isotropic sampling (if you want to do any 3D analysis or processing) or match an existing volume’s spacing (so that the two volumes can be processed/visualized together without any additional resampling).
Resampling with arbitrarily chosen spacing values rarely makes sense, as it would combine both disadvantages: result would be not well suited for 3D analysis and another resampling would be needed later if geometry must be matched to another volume’s geometry. It is fine to have this option somewhere on the GUI but it should not be easy to find, to prevent novice users from using it just because they don’t know any better.
Yes, it could be useful, but it would need some extra GUI (to choose between using closest input volume axes / using ROI axes directions) and implementation workload.
Affine registration being one of the most common use cases. Most of the times for large volumes I find a low-res version of target and source images register very well and also very quickly with affine registration. I can take the output from this registration and then apply to the full resolution image using the other resamplevector module (in fact I think it was you showed me that trick) with resampling artifacts minimized (also a lot faster than had I register the full-resolution images).
Most microCT datasets are also isotropic to begin with, so concern for anisotropic data don’t apply most of our users.
Hi! Thank you very much for maintaining and perfecting Slicer. It is a unique tool that opens a whole universe of opportunities for researchers around the world.
As far as I know, the editor module is needed to edit the result of the airway segmentation module of the chest imaging suite. I was not able to edit the Label Map with the segment editor.
Best regards rudolf
In the DATA module, right-click on airway-lable, select Convert labelmap to Segmentiong node, and then you can edit it in the Segment Editor module.I hope it helps you.
We use the Editor module and the Charts infrastructure within the CIP modules. Is there a tutorial about the migration to the Segment Editor tool and the Charts infrastructure?
I agree that this is a rare use-case, and as such, this functionality can and maybe should be more “hidden” in the UI, but I find anisotropic resampling tp be valuable in the UI nonetheless. Just a few days ago, we wanted to test the behaviour of a pre-processing pipeline we are working on if (highly) anisotropic volumes were being processed. Since I only had isotropic images at hand, I used the “Resample Scalar Volume” module to quickly generate an anisotropic version of a few test samples I had. Helped us tremendously to anticipate errors/issues if such data was to be processed in future. It may be a rare thing to do, but I appreciate if it stays within the UI in some form, otherwise, I’d need to get out of Slicer, use a 3rd party tool etc… I like to stay within Slicer as much as I can during the prototyping stage.
I also use Resample Scalar Volume often, mostly to try algorithms with smaller versions of the target image without having to create a new volume programmatically.
@raul since it affects only a handful of modules, we will not provide a detailed migration guide, but we can help you with any specific questions or help updating selected modules/features that you have problems with. SlicerCIP has other issues caused by Python3 and other API changes, which needs some work but will greatly simplify maintenance and development of CIP. Due to the expected surge of chest disease cases due to COVID-19, it would be a good time to make SlicerCIP work in current Slicer.
