Concept checking in MultiResolutionPyramidImageFilter

Algorithms
1

I am attempting to use this filter in a registration implementation requiring moving/fixed image pixels which have a vector PixelType (e.g. Itk::Vector<double,3>). My first assumption is that this filter should work with vector images; I have not seen any suggestions to the contrary, but would welcome correction on that.

Proceeding with this assumption: The compile fails during concept checking for NumericTraits. I’ve verified (I think) that NumericTraits<> is itself instantiated for these pixel types. The source of the failure rather appears to be in itkConceptChecking.h, where it is checking HasNumericTraits, where T = itk::Vector<double,3>. The point of failure is at the initialization

T a{0};

which for a vector type throws an error that "call of overloaded Vector() is ambiguous. (I do understand this error.) This suggests to me that the HasNumericTraits concept is (perhaps inadvertently) more restrictive than the simple determination of whether NumericTraits is defined.

From the error message, it would appear that the ambiguity is a simple one, between interpreting the ‘0’ as a NULL pointer to ValueTypes, and interpreting it as simply a zero ValueType.

Is there a way through this, or is my initial assumption that this filter should work for vector images incorrect? Many thanks…

2

@blowekamp and/or @Niels_Dekker might have an answer.

3

I don’t recall using it with the itk::Vector pixel type. As it was used mostly with the legacy ITKv3 registration methods so it has been a long time since I have used it.

4

I appreciate the responses.

After I posted, I “cheated” a little by hacking the itkConceptChecking.h file to replace

T a(0);

with

T a(ValueType(0));

which should properly (and unambiguously) initialize both scalar and vector types. This resulted in a successful compilation. I have not yet reached the point where I am in the position to actually test things, so I don’t know if there will be any “unintended consequences”. My admittedly incomplete understanding of the MultiResolution framework suggests that it should in principle work with vector images, unless there are embedded specializations of data types that force scalars. The fact that it actually compiled is hopeful, but not necessarily definitive. Thanks again…

2 Likes
5

Eric, what compiler and OS are you using?

Looks like this was changed to address a warning:

@Niels_Dekker @hjmjohnson may want to take a closer look.

6

Compiler is g+±12, OS is Linux (Gentoo), itk-5.3 (from the Gentoo science overlay). I understand why the change was made, it’s just that the initializer wasn’t “generic” enough.

7

Does it work for you when you remove the zero? I mean by replacing T a{0} with T a{}?

8

Thanks for checking in. I did not merely remove the zero. (Not sure exactly what the default behavior for that is likely to be.) As noted earlier, I did replace

T a{0};

with T a{ValueType(0)};

which removed the value/pointer ambiguity and allowed the compilation to proceed.

9

Not sure exactly what the default behavior for that is likely to be.

Maybe we should document this, but {} certainly does properly initialize an itk::Vector.

itk::Vector<double,3> vec{}; // does zero-initialize all its elements.

HTH, Niels

1 Like
10

Thanks for all the responses. Whatever choice is made, it is apparently necessary to hack a header file in the distribution in order to get the compilation to proceed. This kind of circles back to the original motivation, which is the question of whether there is any reason that MultiResolutionPyramidFilter, in its current form, should not be expected to work with vector images.