Double-check ITK's `.h5` composites

[oesteban]

Ensure we have tests of .h5 composites to make sure that #81 was properly addressed (see #165 (comment) for further details).

[oesteban]

Assessment by Codex, when asked whether #137 and #171 are related:

Yes. Both issues relate to how ITK HDF5 displacement fields are interpreted.

It's answer is described below:

Summary

The earlier orientation bug (#137) and the new ordering issue (#171) both arise from assumptions about the layout of displacement fields in ITK’s HDF5 files. They are therefore related, even though they highlight different facets of the same underlying problem: inconsistent interpretation of the data stored in those files.

Extended explanation

Issue #137 concerned misoriented displacement fields when loading HDF5 files. The corresponding fix added sign flips and adjusted the resulting affine transformation. This can be seen in the 2022 patch modifying nitransforms/io/itk.py, where a sign correction and LPS orientation were introduced:

field[..., (0, 1)] *= -1.0
xfm_list.append(
    Nifti1Image(field.astype("float"), LPS @ affine @ LPS, hdr)
)

(OE note: I think it refers to this instead)

nitransforms/nitransforms/io/itk.py

Lines 420 to 427 in 0dff054

	field[..., (0, 1)] *= -1.0
	hdr = Nifti1Header()
	hdr.set_intent("vector")
	hdr.set_data_dtype("float")
	xfm_list.append(
	Nifti1Image(field.astype("float"), LPS @ affine, hdr)
	)

Issue #171 manifests because ITK sometimes stores displacement fields in row‑major order. Current code assumes Fortran ordering. The relevant lines are:

nitransforms/nitransforms/io/itk.py

Lines 412 to 419 in 0dff054

	# ITK uses Fortran ordering, like NIfTI, but with the vector dimension first
	field = np.moveaxis(
	np.reshape(
	xfm[f"{typo_fallback}Parameters"], (3, *shape.astype(int)), order='F'
	),
	0,
	-1,
	)