SimpleITK 1.1.0 Release

blowekamp · March 27, 2018, 7:18pm

We are pleased to announce the SimpleITK 1.1 Release!

Installing SimpleITK

Complete instructions on getting started with SimpleITK including downloading binaries or building SimpleITK can be found on the SimpleITK Read the Docs web page (http://simpleitk.readthedocs.io/en/release/Documentation/docs/source/installation.html).

Python Binary Downloads
- Python binary wheels are available for download. It is important to have the latest version of pip for correct wheel compatibility and installation. To install the latest SimpleITK package form PyPI:
```
python -m pip install --upgrade pip
python -m pip install SimpleITK
```
- Many Conda packages have been upload to Anaconda Cloud on the SimpleITK channel. These can be installed with:
```
conda install -c simpleitk simpleitk
```
A complete available set of compiled binaries, including select CSharp and Java distributions, along with source and data tar-balls are available on Source Forge (https://sourceforge.net/projects/simpleitk/files/SimpleITK/1.1.0/).

Release Notes

Improvements:

Enabled 4D Images for IO, ExtractImageFilter, and output of JoinSeriesImageFilter.
Enabled MINC IO by default.
New Filters: ObjectnessMeasuresImageFiler (Frangi’s vesselness), IterativeInverseDisplacementFieldImageFilter, UnsharpMaskImageFilter, and RoundImageFilter.
Added LBFGS2 optimizer to ImageRegistrationMethod.
Improved Show search path for FIJI now includes home directories.
Improved ITK Modular awareness, including ImageIOs.
Superbuild update PCRE 8.40, SWIG 3.0.12, ITK 4.13.
Many bug fixes and a couple segmentation fault issues addressed.
The build system is better and more robust then ever! Many new improvements and features!
Migrating examples, miscellaneous documentation and Wiki to Read the Docs: http://simpleitk.readthedocs.io/en/master/
Improved reading and writing of 64-bit integer images across platforms (except python 2.7 on Windows).
Added optional wrapping of the CoherenceEnahancingDiffusionImageFilter (not enabled in binary distributions).
Added and improved examples related to DICOM reading, writing and manipulating the meta-data dictionary.

API Changes:

Added ImageFileReader::ReadImageInformation.
- This adds support to read meta-data from any supported image file format with any dimension without reading the bulk pixel data.
Added ImageReaderBase::GetRegisteredImageIOs method to obtain list of loaded ITK ImageIO modules.
Added Version::ITKModulesEnabled method to obtain a list of ITK enabled modules when SimpleITK was built.
Added BinaryImageToLabelMap::GetNumberOfObjects.
Added optional MaskImage input to ConnectedComponentImageFilter.
Added SignedMaurerDistanceMapImageFilter::BackgroundValue paramater.
WarpImageFilter now uses named inputs.
Convolution filters use named inputs.
Added optional OrientedBoundingBox to LabelShapeStatisticsImageFilter.
Added missing features to RelabelComponentImageFilter including SortByObjectSize parameter and NumberOfObjects, SizeOfObjectsInPhysicalUnits measurements.
Added LabelStatisticsImageFilter::GetRegion.
Added MetaDataDictionaries to the ImageSeriesReader.

Compatibility:

DiscreteGaussianImageFilter, SmoothingRecursiveGaussianImageFilter now optionally take a vector argument for variance and sigma respectfully.
In Python the procedural methods, DiscreteGaussian and SmoothingRecursiveGaussian may not work with named arguments due to limitation with SWIG and overloaded functions.
N4BiasFiledCorrectionImageFilter now only takes uint8 pixel types for mask image input.

fedorov · March 28, 2018, 2:02pm

@blowekamp sorry for a basic question, but do you have an example demonstrating how to use this functionality?

This is probably due to lack of basic understanding, but I tried to read an image that has in the NRRD header this size:

sizes: 12 390 400 10

but when I read it using sitk.ReadImage(), the result is a 3-dimensional volume. I did upgrade to the 1.1.0 release.

blowekamp · March 28, 2018, 2:53pm

By 4D Images we mean images with 4 “spacial” dimensions represented by itk::ImageBase<4>. We have always supporting 3D vector images, which some commonly refer to as 4D images.

We don’t have an example, but we have written good testing for 4D images and the special filters which use them:

github.com

SimpleITK/SimpleITK/blob/ea1006530c41d3cbae31f0babfbf2b647bfe9e1d/Testing/Unit/sitkImage4DTests.cxx#L535-L573


      
          TEST_F(Image4D, JoinSeriesImageFilter)
          {
            std::vector<unsigned int> size(3);
            size[0] = 10;
            size[1] = 11;
            size[2] = 12;
          
            sitk::Image img = sitk::Image( size, sitk::sitkUInt8 );
          
            sitk::Image out = sitk::JoinSeries(img, img, img);
          
            ASSERT_EQ ( out.GetDimension(), 4u );
            EXPECT_EQ ( out.GetSize()[3], 3u );
          }
          
          TEST_F(Image4D, ExtractImageFilter)
          {
            std::vector<unsigned int> size(4);
            size[0] = 10;
            size[1] = 11;

This file has been truncated. show original

It looks like the IO test just test the nifti file format.

I would have to see the NRRD header. But my guess is that the image is 3D with multiple components. Did SimpleITK load the image with vector pixel types?

fedorov · March 28, 2018, 4:18pm

Yes, it is read as a 4-d vector image. I know that’s how it worked in the past, I was not sure if this is what is expected.

Here is the header:

NRRD0005
# Complete NRRD file format specification at:
# http://teem.sourceforge.net/nrrd/format.html
type: unsigned short
dimension: 4
space: right-anterior-superior
sizes: 12 390 400 10
space directions: none (-0.69999999999999996,0,0) (0,-1,0) (0,0,4)
kinds: list domain domain domain
endian: little
encoding: gzip
space origin: (177,133,-20)
measurement frame: (1,0,0) (0,1,0) (0,0,1)

I have two more questions:

is it expected that image is re-oriented when writing back out to NRRD? This is the result of read-write steps:

NRRD0005
# Complete NRRD file format specification at:
# http://teem.sourceforge.net/nrrd/format.html
type: unsigned short
dimension: 4
space: left-posterior-superior
sizes: 12 390 400 10
space directions: none (0.69999999999999996,0,0) (0,1,0) (0,0,4)
kinds: vector domain domain domain
endian: little
encoding: raw
space origin: (-177,-133,-20)
measurement frame: (-1,-0,0) (-0,-1,0) (-0,-0,1)

is it expected that I am unable to write the loaded 3d vector image as NIFTI? I am getting this error:

In [4]: sitk.WriteImage(i,'dwi_dro.nifti')
---------------------------------------------------------------------------
RuntimeError                              Traceback (most recent call last)
<ipython-input-4-6f30d19912b9> in <module>()
----> 1 sitk.WriteImage(i,'dwi_dro.nifti')

~/.pyenv/versions/3.5.3/Python.framework/Versions/3.5/lib/python3.5/site-packages/SimpleITK/SimpleITK.py in WriteImage(*args)
   8043
   8044     """
-> 8045     return _SimpleITK.WriteImage(*args)
   8046 class ImageReaderBase(ProcessObject):
   8047     """

RuntimeError: Exception thrown in SimpleITK WriteImage: /scratch/dashboard/SimpleITK-OSX10.6-x86_64-pkg/SimpleITK/Code/IO/src/sitkImageFileWriter.cxx:145:
sitk::ERROR: Unable to determine ImageIO writer for "dwi_dro.nifti"

glk · March 28, 2018, 4:24pm

What is happening with that 12-component fastest axis? The NRRD header says it’s a “list”, but what do those 12 values mean?

I’m guessing that this NRRD header is representing meta-data that is outside ITK’s expressivity. As far as I remember, for example, ITK doesn’t support multiple semantically distinct world-spaces (like RAS vs LPS), hence the conversion to LPS on write.

dzenanz · March 28, 2018, 4:25pm

Have you tried .nii or .nii.gz as an extension?

blowekamp · March 28, 2018, 5:25pm

I believe that your two issues have been address by the prompt responses. But I will elaborate…

ITK always operates in LPS, so when the file is loaded it is converted to this orientation.

SimpleITK can “express” this volume just fine as a 3-D image of vector pixels i.e VectorImage with 12 components per pixels.

This SimpleITK used the default ITK ImageIO factory mechanism to determine which ImageIO can write a file. Here is the call that is failing: ITK/Modules/IO/NIFTI/src/itkNiftiImageIO.cxx at a008ca96037c9aabcb9439a758529e8958523e4a · InsightSoftwareConsortium/ITK · GitHub

“nifti” is not a standard file extension for NIFTI images:

github.com

InsightSoftwareConsortium/ITK/blob/30206c0ec0cfecb6df9dec22e9a54e98463189db/Modules/ThirdParty/NIFTI/src/nifti/niftilib/nifti1_io.c#L2489-L2530


      
          /*----------------------------------------------------------------------*/
          /*! return whether the filename is valid
          
              Note: uppercase extensions are now valid.    27 Apr 2009 [rickr]
          
              The name is considered valid if the file basename has length greater than
              zero, AND one of the valid nifti extensions is provided.
              fname input          | return |
              ===============================
              "myimage"            |  0     |
              "myimage.tif"        |  0     |
              "myimage.tif.gz"     |  0     |
              "myimage.nii"        |  1     |
              ".nii"               |  0     |
              ".myhiddenimage"     |  0     |
              ".myhiddenimage.nii" |  1     |
          *//*--------------------------------------------------------------------*/
          int nifti_is_complete_filename(const char* fname)
          {
             const char * ext;

This file has been truncated. show original

fedorov · March 28, 2018, 5:55pm

Thank you, this answers my question!