ENH: Support for VariableLengthVector in CastImageFilter

[Leengit]

This pull request resolves the issue that the use of the OutputPixelType constructor in itkCastImageFilter::DynamicThreadedGenerateDataDispatched does not work when the pixel type is a VariableLengthVector.

PR Checklist

• No API changes were made (or the changes have been approved)
• No major design changes were made (or the changes have been approved)
• Added test (or behavior not changed)
• Updated API documentation (or API not changed)
• Added license to new files (if any)
• Added Python wrapping to new files (if any) as described in ITK Software Guide Section 9.5
• Added ITK examples for all new major features (if any)

[dzenanz]

Code looks good, but style requires slightly different whitespace. Please run clang-format on the changed source files.

[Leengit]

@dzenanz, clang-format is trying to change, for example,

struct PixelFactory< itk::VariableLengthVector< TSubPixel > >

to

struct PixelFactory<itk::VariableLengthVector<TSubPixel>>

Is the latter the desired style? (Has the style guide been updated recently?)

[dzenanz]

The style is what clang-format 8.0.2 produces. We agreed not to fight it. Major style update was done maybe a year ago.

[blowekamp]

Can you please add a test case for the conversion you are adding to the filter?

The filter works for variable length -> variable length. Based you the commit/PR message its not clear what conversion you are trying to add but I think it's something like fix array -> variable length.

[blowekamp]

The pixel factory is not needed. Just do the following:

OutputPixelType value = outputIt.Get();

I believe the above should be a "deep copy" but please test the output in the test.

[Leengit]

Will do.

[Leengit]

Can you please add a test case for the conversion you are adding to the filter?

Will do.

The filter works for variable length -> variable length. Based you the commit/PR message its not clear what conversion you are trying to add but I think it's something like fix array -> variable length.

A comment by @blowekamp in Issue #1579 suggests that casting to a VectorImage did not work in CastImageFilter<TInputImage, TOutputImage>::DynamicThreadedGenerateDataDispatche due to an invalid C++ construction of an OutputPixelType. This PR fix addresses this.

Yes, the Image<Vector<type,c>,d> ↔ VectorImage<type,d> was just implemented, in PR #2073.

Edit: oops just realized that the person I am responding to and the supplier of the original comment are one and the same, @blowekamp. Apologies if the above reads kind of crazy due to my overlooking that!

[blowekamp]

The simplicity of this solution was missed when I looked at this. Thank you for changing to the simpler solution and adding tests.

With this conversion: VectorImage<type,d> ↔ Image<Vector<type,c>,d> it may be worth wild to test/verify, that an exception will be thrown ( early in the pipeline e.g. GenerateOutputInformation? ) when the dimensions of the vector-like objects don't match.

[Leengit]

With this conversion: VectorImage<type,d> ↔ Image<Vector<type,c>,d> it may be worthwhile to test/verify, that an exception will be thrown ( early in the pipeline e.g. GenerateOutputInformation? ) when the dimensions of the vector-like objects don't match.

I believe that the desired behavior is to do something reasonable even when the dimensions of the input and and output images are not equal. For example, the comment at the top of of the definition of CastImageFilter::GenerateOutputInformation() is:

// do not call the superclass' implementation of this method since
// this filter allows the input the output to be of different dimensions

[blowekamp]

With this conversion: VectorImage<type,d> ↔ Image<Vector<type,c>,d> it may be worthwhile to test/verify, that an exception will be thrown ( early in the pipeline e.g. GenerateOutputInformation? ) when the dimensions of the vector-like objects don't match.

I believe that the desired behavior is to do something reasonable even when the dimensions of the input and and output images are not equal. For example, the comment at the top of of the definition of CastImageFilter::GenerateOutputInformation() is:

// do not call the superclass' implementation of this method since
// this filter allows the input the output to be of different dimensions

There are two "dimensions":

• The dimension of the Image ( which your comment refers too )
• The dimension/size/length of the pixel component vector ( which my comment refers too ).

If the length of the input pixel vector and the output vector differ we need to ensure we have "well defined" behavior and don't over run any buffers. My expectation would be an exception would be thrown some where under the GenerateOutputInformation when it is detected that length of the pixel vectors are not equal.

[Leengit]

If the length of the input pixel vector and the output vector differ we need to ensure we have "well defined" behavior and don't over run any buffers. My expectation would be an exception would be thrown some where under the GenerateOutputInformation when it is detected that length of the pixel vectors are not equal.

Ah, yes, of course, thank you. Will do.