NIFTI_XFORM_UNKNOWN issue

[jeffduda]

Recently ran across an odd issue when trying to deal some old ANALYZE images. If you run PrintHeader on the original image it reports:
qform_code_name = NIFTI_XFORM_UNKNOWN

If I read this file into ANTsR, then immediately write it back out as NIFTI, the resulting file also has:
qform_code_name = NIFTI_XFORM_UNKNOWN

If I read it in, multiply it by 1 or antsImageClone() it, and write it to NIFTI, you get the expected: qform_code_name = NIFTI_XFORM_SCANNER_ANAT

One consequence of this, is that if you read in the file, change the direction to something valid, and try to write it out as NIFTI, your output still has an identity matrix for the direction, but no errors or warnings were thrown. See below data links and code.

fa.hdr - https://drive.google.com/file/d/1e1LNfxyAEJBx2SOrZmm6nasd5D6cUF5N/view?usp=sharing
fa.img - https://drive.google.com/file/d/1wMTrdgadIjihFfMzjyHJlPGtBN5YlO8v/view?usp=sharing

fa = antsImageRead("fa.hdr")
d = antsGetDirection(fa)
d[2,2] = -1
antsSetDirection(fa, d)
antsImageWrite(fa, "faFixed.nii.gz")

This output will still have the wrong direction info. If you print(fa) before writing it, the direction appears to have been changed successfully. If you add fa = fa*1 as the second line, then the output is as expected. It's weird.

[cookpa]

Possibly related? Sounds like a similar issue of changes not being permanent due to pipeline connections

https://itk.org/pipermail/community/2014-July/002858.html

[jeffduda]

I tried calling itkImage->DisconnectPipeline() before returning the image from antsImageRead(), also tried to set ReleaseDataFlagOn() on the reader, but neither approach fixed this issue.

[jeffduda]

The ChangeImageInformationFilter would likely work, but would break the interface for backwards compatibility since it would require:
img = antsSetSpacing(img, spacing)

[jeffduda]

Solution is to set SetUseInputMetaDataDictionary(false) on the image file writer. However, not calling DisconnectPipeline means pointers to the file readers, etc are being kept alive which could lead to memory issues. Not a bad idea to add a lot of calls to DisconnectPipeline throughout.