WIP: Fix MINC read/write to convert from/to RAS coordinate system

[gdevenyi]

Convert the coordinate system from RAS to LPS during MINC loading, and convert back on writing.

Also adds a setting to keep old configuration, so that MINC-based ITK tools (EZMinc) can maintain their original configuration and return sensible coordinate values in MINC-space.

Paging @vfonov

[gdevenyi]

Originally discussed at https://insightsoftwareconsortium.atlassian.net/browse/ITK-3503?attachmentSortBy=fileName

[vfonov]

What about minc transform?

[gdevenyi]

@vfonov I have the code for converting the MINC affine to from RAS to LPS, I was going to do a seperate PR. Would you rather I roll that into this?

[gdevenyi]

@vfonov MINC vs ITK also defines its transforms in opposite directions, do you want that added to the reader, or leave that to the user?

[gdevenyi]

I have added the conversion for Affine transforms.

I'm not quite sure where to add the switch to disable this conversion to support backwards compatibility.

Can anyone give some guidance here?

[gdevenyi]

My transform work isn't right. It used to be combined with inverting the affines so that MINC and ITK transforms went in the same direction. I backed that part out and this needs some fixes as a result.

[vfonov]

one of the main reason for me to have minc interface for ITK is to be able to run ANTs & Elastix. I think we should run extensive checks to make sure that this conversion does not screw up their results.

[gdevenyi]

Totally agree. On the walk home I wrote up a bunch of tests in head to ensure this works properly. Will enumerate later.

[gdevenyi]

Given two files, in both MINC and NIFTI format:
GAD

• scan of me T1
• convert to MINC with dcm2mnc, minc-toolkit/1.9.16
• convert to NIFTI with dcm2niix/1.0.20171215

mni_icbm152_t1_tal_nlin_asym_09c

• original MINC version
• convert to NIFTI with mnc2nii

Tests to do:

• minc-to-minc affine registration with antsRegistration
• nifti-to-minc affine registration with antsRegistration
• minc-to-nifti affine registration with antsRegistration
• bestlinreg minc-to-minc
• save transforms as both ants and minc format
• apply all transforms using antsApplyTransforms
• apply minc-style transforms with mincresample
• ConvertImage to/from minc/nifti

[vfonov]

Sounds like a plan

[gdevenyi]

Additional tests:

• antsRegistration SyN to produce nonlinear
• save as minc/nifti
• confirm forward/reverse transformations also work as expected with antsApplyTransforms and mincresample
• nlfit to produce nonlinear
• confirm forward/reverse work with antsApplyTransforms

[vfonov]

nlfit <-> antsApplyTransforms probably will not work.

[gdevenyi]

All conversions and affine registrations now pass my listed tests.

The following still don't work

• nlfip -> antsApplyTransform
• mincresample applying the NLIN fields produced by ANTs

ITK and MINC have opposite transform directions, and nlpfit doesn't produce an inverse warp field and doesn't handle the invert flag of an XFM grid transform properly (yet...)

I think we have the issue that in grid-based transforms, the X and Y vector components point in opposite directions when produced in minc-land or ITK land.

Questions

1. Should we flip all the voxel vectors?
2. Can anyone suggest an efficient way to do this?
3. @vfonov the TransformMINC doesn't have an option to not flip the transforms, do you need it?

[gdevenyi]

PR #194 addresses the issue with MINC NLIN transforms only being generated one-way and ITK not properly handling the invert flag on such transforms.

Still remaining is I need to figure out an efficient method to voxel-wise multiply the incoming grid file by (-1,-1,1) to flip the RAS vector components to LPS vectors.

[gdevenyi]

Added patch now properly handles Grid transforms to/from MINC land.

My local tests of

• mincresample applying ITK generated transforms
• antsApplyTransforms applying grid transforms generated by nlpfit

Now work properly.

The question that remains is should ITK also invert all transforms it produces (and handle inversion on reading) so that the directionality of MINC vs ITK transforms is also transparently handled.

This patch also works properly on top of/with #194

[dzenanz]

As I am not too familiar with MINC format, I only have minor remarks.

[dzenanz]

Probably not needed.

[dzenanz]

Can be removed, I think.

[dzenanz]

Probably redundant.

[gdevenyi]

Thanks @dzenanz I have removed the extraneous Fills.

[gdevenyi]

@thewtex I think this change is breaking the current tests, is that correct? If so, any hints as to how to I would go about sorting that out?

[thewtex]

@gdevenyi there are 51 minc tests failing on all platforms. Do the tests all pass locally?

[gdevenyi]

@thewtex that's what I'm asking? how do I go about checking that locally :)

[hjmjohnson]

@gdevenyi Is this PR still relavant?

[gdevenyi]

@gdevenyi Is this PR still relavant?

Yes, the MINC reader is still incorrect, and the coordinate system conversion fixes it.

[hjmjohnson]

@gdevenyi Could you provide a roadmap for what you think needs to be done still? There may be students looking for projects this fall, and I'll see if I can convince one of them to look at this.

[gdevenyi]

@hjmjohnson

Current state as I recall, fixed are

• images load and save properly now
• affine transforms read and write properly (both MINC/ITK push/pull definitions handled and RAS/LPS coordinates converted)
• warp transforms read and write properly (both MINC/ITK push/pull definitions handled and RAS/LPS coordinates converted)

as I recall the blockers were

1. How to handle the breaking change for downstream dependent tools, right now there's a bool option in the loader, but I don't see how to access given how most tools use a generic reader, I think it should be a compile-time switch instead, I'm not skilled enough in CMAKE to make that happen
2. How to handle other voxel formats which have directional information, in particular DTI

[vfonov]

There is currently 4 different ways how Analyze file format can be handled, just make the same thing for MINC/XFM reader writer : https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/IO/NIFTI/include/itkNiftiImageIO.h#L42

[vfonov]

It looks like the origin is incorrect when RAS to LPS is needed

[gdevenyi]

Good catch @vfonov I'll take a look

[vfonov]

I am trying to make a new pull on the latest codebase: https://github.com/vfonov/ITK/tree/MINC_RAS_LPS_v2 (WIP)

[gdevenyi]

It looks like the origin is incorrect when RAS to LPS is needed

@vfonov The Origin Read/Write will need negative applied to the X and Y dimensions to go from R->L and A->P

[vfonov]

It looks like the origin is incorrect when RAS to LPS is needed

@vfonov The Origin Read/Write will need negative applied to the X and Y dimensions to go from R->L and A->P

So, most things are fixed in https://github.com/vfonov/ITK/tree/MINC_RAS_LPS_v2 , we need to make more tests there.
Also, the TransformationMINC for RAS->LPS is not quite complete .

[gdevenyi]

Can we perhaps revive this to integrate this breaking change for ITKv6?

@dzenanz @vfonov

[vfonov]

I already forgot what needs to be done. Do we want to, essentially make MINCs behave as if they were NIFTIs ?

[seanm]

Can we perhaps revive this to integrate this breaking change for ITKv6?

@gdeveny Can you rebase on master and fix the conflicts? I'd be interested to see how/if this breaks our app (Brainsight)...

[gdevenyi]

I already forgot what needs to be done. Do we want to, essentially make MINCs behave as if they were NIFTIs ?

The core issue is MINC's internal coordinates are RAS = +X+Y+Z, but the ITK internal Image coordinate system is LPS = +X+Y+Z. MINC-IO in ITK loads the files not converting the coordinate system, making it impossible to mix MINC and any other image loaded by ITK IO.

This is not "behave as if they were NIFTIs" but rather, "behave like every other image loaded by ITK ImageIO"

@gdeveny Can you rebase on master and fix the conflicts? I'd be interested to see how/if this breaks our app (Brainsight)...

Will do.

This will impact things if you were special casing anything about MINC, otherwise it should just make things load properly coordinate wise.

[dzenanz]

Why not just document (via direction matrix) that the image is in RAS coordinate system?

[seanm]

This will impact things if you were special casing anything about MINC, otherwise it should just make things load properly coordinate wise.

It's been forever since I touched our MINC reading code (via ITK), but maybe we are doing some flipping, because no one, internally or externally, has ever reported Brainsight loading any MINC files flipped.

[gdevenyi]

Why not just document (via direction matrix) that the image is in RAS coordinate system?

Is this a suggestion to address this in code somehow? I'm not deeply familiar with ITK internals, so I'll need some hints.

My overall goal here was to bring MINC to first-class support in terms of it being treated equally and interchangeably with any other image loaded via ImageIO. Right now, I can't do this due to the misinterpreted coordinates.

[dzenanz]

I did not take a close look at the code. If you are shuffling array elements to "conform to LPS" standard, you don't need to do that. I see that you are fiddling with orientation matrices, so this PR might already be doing what I suggested.

[vfonov]

As far as I remember now the issue is with transformations, in particular with non-linear _grid files. That would need to be recomputed via F∘T∘F transformation on loading and saving any such file.

[gdevenyi]

As far as I remember now the issue is with transformations, in particular with non-linear _grid files. That would need to be recomputed via F∘T∘F transformation on loading and saving any such file.

Correct, this was the last outstanding thing that needs fixing in this PR in a performant way.

[gdevenyi]

Rebasing was too difficult so I manually ported the changes into the new PR #4864