/build

(also CC'ing @hjmjohnson in case there are more comments)

/build

I'm not sure hard-coding these values is the right process, either we should be setting them to whatever is appropriate or inheriting whatever the original values were if present in metadata. ITK hard codes it but that's not necessarily the best thing to do, nor is inconsistent values in the header a problem so long as they are set correctly. Setting both these values to 1 selects transform method 3 (https://www.nitrc.org/docman/view.php/26/204/TheNIfTI, pages 12 and 13). If an input nifti uses another method then the header of the output image will be different but both ITK and our code will do this consistent with one another. If we did hard code the values as such we have to fill in the srow_* values correctly as well as qoffset_* and quatern_* values.

If we did hard code the values as such we have to fill in the srow_* values correctly as well as qoffset_* and quatern_* values.

this part is done by the set_qform and set_sform API, should be fine:

• https://github.com/nipy/nibabel/blob/75c2b85cadb3ef427167ac90a5c0860937cc9e75/nibabel/nifti1.py#L1068
• https://github.com/nipy/nibabel/blob/1eb21d8d05f599baf6a2d396f2404604124ef027/nibabel/nifti1.py#L935

I will need some time to make a more detailed review. I have found that all options are a catch-22 with nifti files.

The qform is lossy with respect to the dicom standard, and often results in numerical precision problems when dealing with physical space. The sform has enough precision to be lossless with respect to the dicom standard, but does not necessarily impose that the representation has orthogonal axis.

To further complicate matters, many external tools have developed different protocols and interpretations of when/how to use each of the storage format.

Even ITK's behavior has evolved over time trying to adapt to the environment. The most recent changes opted to try to be less lossy during data conversion so that physical space can be reliably represented with respect to the original dicom data. This change occurred when nifti binary masks were not reported in the same physical space as the dicom originating space. The problem turned out to be small errors in translation to/from qform representations.

/build

@hjmjohnson did you take a second look here?

@hjmjohnson did you take a second look here?

Yes. I don't think there is a clear solution from ITK's standpoint. ITK defaults to writing the sform content because it most closely matches the internal ITK storage representation, and it provides the least lossy path from DICOM representations of physical2index space mapping.

So, approve PR?

/build

/build

/build