Python wrapping for all the classes.

[phcerdan]

A list to keep track of classes without wrapping: https://github.com/phcerdan/ITKIsotropicWavelets/tree/master/wrapping:

Core

• itkWaveletFrequencyForwardUndecimated . It can follow forward decimated version made by @thewtex
• itkWaveletFrequencyInverseUndecimated . It can follow inverse decimated version
• itkStructureTensor. Done in ENH: Python, wrap structure tensor #102
• itkRieszRotationMatrix. Done in ENH: Add wrapping for RieszRotationMatrix #93

Decimate/Expand (in frequency or spatial domain).

• itkExpandWithZerosImageFilter and itkShrinkDecimateImageFilter. Done in ENH: Add python wrappings for expand with zeros and decimate #146

Utilities

• itkIsotropicWaveletUtilities. Done in ENH: Python, wrap utilities free functions intro a struct #145

---

Wrap enhancements:

• Wrap output of Forward/Inverse using itk::VectorContainer instead of current std::vector. Or wrap std::vector<ImagePointer> with ImagePointer ${WRAP_COMPLEX_REAL_TYPE}. Follow on in Wrap for python std::vector<ImagePointer> in helper functions. #67

[thewtex]

👍

[jhlegarreta]

Which fits best/applies to the Decimate Expand filters: itk_wrap_image_filter (filters that need one or more image parameters of the same type) ; itk_wrap_image_filter_combinations (If it is desirable or required to instantiate an image filter with different image types) or itk_wrap_image_filter_types?

[thewtex]

@jhlegarreta It depends how the classes will be commonly used. There is a trade-off between build time / package size, and available options.

[phcerdan]

@jhlegarreta They are used in the Decimated pyramid on images with complex pixel type.
I think the minimum requirements are: Dimensions: 2 and 3, PixelType: float/double, and complex<float/double>. The OutputImageType is ok to be the same than InputImageType.

[phcerdan]

Now I am thinking that the wrapping is to expose it to the user, the internal use of the Shrinker/Expander doesn't matter.

The Decimate filter basically removes every Nth pixel without interpolation (Nth pixel based on the m_ShrinkFactor), and the Expander adds zeros on those spots. I think they are good to have for the development of filters (especially in the signal analysis area) but not super useful for Pythonists I guess. Are there people developing filters directly in Python?

[thewtex]

Since we can't create new templated classes directly in Python, they can be hidden when wrapping.

[jhlegarreta]

When trying to a add the wrapping for the itk::StructureTensor, I've realized that it seems to be a filter or other construct, rather than a tensor, as defined in the module. The name seems misleading to me. Is the name still correct or should we propose a new one and do a separate PR?

AFAIK, ITK iterators are not wrapped. Does this mean that we cannot wrap subclasses? Shall we add a .notwrapped file for them?

About the utilities classes, I'd like to have some pointers at how to perform their wrapping, since they contain a variety of free functions, some requiring template arguments, and others not.

Thanks.

[thewtex]

AFAIK, ITK iterators are not wrapped. Does this mean that we cannot wrap subclasses? Shall we add a .notwrapped file for them?

Right, there is no use to wrapping the iterators. A .notwrapped file with a comment that explains this may help others in the future.

[phcerdan]

@jhlegarreta about itk::StructureTensor. You are right, it is indeed an ImageToImageFilter with the OutputPixel being a matrix. Thanks for pointing it!

The output matrix per pixel is composed by the eigenvectors and eigenvalues computed from a StructureTensor, we can factor out this StructureTensor into a new class. Should we append ImageFilter to the name to make it clear. Or even better but verbose: itkStructureTensorEigenSystemImageFilter?

Opening an issue to rename it and also to refactor a StructureTensor into a new class: #62

[phcerdan]

The refactor wont't affect the wrapping though, we would need to wrap an output of type:

 typename TOutputImage =
 itk::Image<itk::VariableSizeMatrix<typename TInputImage::PixelType>,TInputImage::ImageDimension> >

where TInputImage::PixelType would be limited to ${WRAP_ITK_REAL}