Errors in elastix/parameter file lead to unclear error messages

[Svdvoort]

I've just started experimenting with this package and ran into some start-up problems, mainly due to some unclear error messages. I was using parameter files that worked fine with base elastix (just the binary), so I expected it to work with ITKElastix as well, but some changes were needed that were not obvious at first sight.

For example, I was registering 4D images, which in the pre-compiled Elastix binary (5.0.1) can only be short. However, ITKElastix has only been compiled with float support. Normally in Elastix this will lead to an error about having to recompile with different types for nD dimension. However, in ITKElastix setting for example FixedInternalImagePixelType to short will lead to a segmentation fault. I figured it out after looking at the examples, but it was to hard to diagnose that the segmentation fault was due to the FixedInternalImagePixelType.

Another non-obvious change was the WriteResultImage setting. I always set this to false in base Elastix, since I later use transformix to apply the transform. However, setting WriteResultImage to false in ITKElastix, and then trying to write the image using itk.imwrite will lead to an error like this:

RuntimeError: /work/ITK-source/ITK/Modules/IO/ImageBase/include/itkImageFileWriter.hxx:365:
Did not get requested region!
Requested:
ImageRegion (0x7ffd43ad9120)
  Dimension: 4
  Index: [0, 0, 0, 0]
  Size: [558, 619, 547, 4]
Actual:
ImageRegion (0x7ffd43ad90d0)
  Dimension: 4
  Index: [0, 0, 0, 0]
  Size: [0, 0, 0, 0]

which is not a very clear error message, considering that the solution is to set WriteResultImage to true.

Is there a way to parse such errors more clearly?

[thewtex]

xref #137

[ntatsisk]

The first non-obvious error message is being worked out indeed in #137.

The second about WriteResultImage leads to the empty buffer reported https://github.com/InsightSoftwareConsortium/ITKElastix/commit/f16f94237e28a2ad043aac93c9e8b2bfc7b42014 and it is related to issue #127. I guess it needs to be addressed as well.

cc @N-Dekker