.nii support for minc tools

[andreashorn]

Given the recent paper with great success of BestLinReg (https://www.sciencedirect.com/science/article/pii/S1053811918302350) and some discussion (https://twitter.com/default_mode/status/980064187228573696) I wanted to ask whether there is any interest in natively supporting .nii format for some basic MINC tools? (e.g. starting with a linear and nonlinear registration algorithm)? I think the community would greatly benefit from this and would love to integrate MINC tools based registrations into our DBS toolbox lead-dbs, too!

thank you for considering, Andy

[vfonov]

Hmm, the date of this issue is 1st of April. Is it an April's fool joke?

[andreashorn]

Not at all! Really high interest here!!

[vfonov]

We can also leave all the good stuff in MINC only, and then maybe there will be more interest in supporting minc-toolkit development and adopting the file format.

[andreashorn]

...and I wouldn’t blame you for that! You (=both yourself and the Neuro) have already given and continue to give so much to the community.

Still, despite all the problems of the NIfTI format (I personally don’t like it a lot either), we can probably agree that there is no other single file format supported by as many tools out there. Thus, any open pipe tool will always use it and including MINC Tools into any such pipeline will produce unnecessary I/O (conversion steps) and potentially header compatibility problems.

I’ve met quite a few people already that would like to use MINC tools but don’t due to the file format. I even know of a comparison study that didn’t include the tools for similar reasons..

Maybe it could also be a gradual support, adding it to the most important tools first and seeing what it brings?

In any case keep up the good work and thanks for considering!

[andrewjanke]

I think the "potential header compatibility problems" is an understatement. I'd argue that part of the reason that MINC has been so successful at registration over the years is the consistent, well documented and rigorous definition of the coordinate space. Over time NiFTI has caught up but there is by no means consistent adoption of this standard by all Nifti tools yet.

What I'm angling at is that Vlad could do the work to "support" nifti and then from the point of the user "BestLinReg" would start to fail given the number of permutations of radio/neuro flips, direction cosines, orientation issues...

FWIW, minc-toolkit already supports Nifti.

$ nii2mnc input1.nii input1.mnc $ nii2mnc input2.nii input2.mnc

$ bestlinreg.pl input1.mnc input2.mnc out.xfm output.mnc

$ mnc2nii output.mnc output.nii

I see no reason to bake in nii reading/writing into the core MINC libraries as then it becomes incumbent on the MINC developers to support the conversion problems of the entire community that were not of MINC's making. (and incidentally was one of the original motivations for MINC). I'd see that as wasted development effort that is far better utilised in writing great registration/non-uniformity/etc tools.

With the amount of work that Vlad has put into minc-toolkit in recent years I don't think there is a valid argument anymore that installing/using MINC is too hard.

Or, I'm just old and grumpy now!

[gdevenyi]

I must agree with @andrewjanke, @vfonov has done a great job maintaining minc-toolkit and improving upon it. It would be a huge burden adding the "flexible" nifti format into the cleanly designed MINC world.

I can see some need for the nii2mnc/mnc2nii pair to be improved a bit, but this is mostly an issue with the fuzzyness that is NIFTI, rather than anything to do with MINC.

As I see it, the way to get the best of MINC into the neuroimaging world is pushing for making the file format a first-class citizen in the other tools out there (already is in ITK). libminc provides the interfaces, @vfonov provides the a maintained release (its even in debian stable, who are notoriously picky about packaging). The maintainers of other tools should be politely asked to enable the option to use MINC by using libminc, then, you can get all the MINC goodness.

[vfonov]

By the way, now Register and Display can read and write nifti files natively, thanks to the changes by @rdvincent .

[vfonov]

Also, something interesting for @andrewjanke , graph of top 10 contributors activity to minc-toolkit-v2, over years:

[andrewjanke]

Most interesting, thanks Vlad. I could claim that some of that green should be orange! "Back in my Day" (TM) you had to ftp your changes/additions to Peter Neelin and he'd commit your changes to RCS/CVS! MINC dev used to require a BIC account. :)

[vfonov]

By the way, there is going to be another meeting on the future of MINC at the MNI in a couple of weeks, maybe they will organize Skype/go-to meeting/Google hangout this time: https://doodle.com/poll/nxv2awddth2c4qyp

[andreashorn]

Thanks all for your responses! Was worth a try I guess!

[zijdenbos]

I'd agree that the issues with NIfTI's coordinate space confusion (at one point we struggled for weeks trying to shuttle NiIfTI data between different NIfTI tools, which between themselves couldn't agree on the use of qform and sform). As convenient as it may seem to build in native NIfTI support into MINC, leaving the conversion to dedicated converters (nii2mnc/mnc2nii) already works - given the complexity and I/O burden in the tools themselves, these conversions are minimal overhead.

A few related thoughts, from the recent "Future of MINC" meeting:

• there was a suggestion to push for the other direction; i.e., building native MINC support into other toolkits. Given that MINC is better behaved, I'd that may actually be easier, and would promote the use of MINC-the-file-format.
• there was a very clear sentiment in the room that contradicts Andrews assertion that installing/using MINC is not too hard. Several people who were actually there, in the heart of MINC-world, told of how it took them months to get MINC working. I think that is (still) a real concern that "we" should not dismiss.
• my major frustration in the past few years, has been that dcm2mnc (any version) chokes on a very large percentage of DICOM data that we receive. To the point that we have started using a script "dcm2nii2mnc" to "solve" that; simply because dcm2nii is far more robust than dcm2mnc is. If promoting MINC is the goal, making sure dcm2mnc works on anything, should be first on the list IMHO.

-- A

On Tue, Apr 3, 2018 at 6:02 PM, Andrew Janke notifications@github.com wrote:

I think the "potential header compatibility problems" is an understatement. I'd argue that part of the reason that MINC has been so successful at registration over the years is the consistent, well documented and rigorous definition of the coordinate space. Over time NiFTI has caught up but there is by no means consistent adoption of this standard by all Nifti tools yet.

What I'm angling at is that Vlad could do the work to "support" nifti and then from the point of the user "BestLinReg" would start to fail given the number of permutations of radio/neuro flips, direction cosines, orientation issues...

FWIW, minc-toolkit already supports Nifti.

$ nii2mnc input1.nii input1.mnc $ nii2mnc input2.nii input2.mnc

$ bestlinreg.pl input1.mnc input2.mnc out.xfm output.mnc

$ mnc2nii output.mnc output.nii

I see no reason to bake in nii reading/writing into the core MINC libraries as then it becomes incumbent on the MINC developers to support the conversion problems of the entire community that were not of MINC's making. (and incidentally was one of the original motivations for MINC). I'd see that as wasted development effort that is far better utilised in writing great registration/non-uniformity/etc tools.

With the amount of work that Vlad has put into minc-toolkit in recent years I don't think there is a valid argument anymore that installing/using MINC is too hard.

Or, I'm just old and grumpy now!

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/BIC-MNI/minc-tools/issues/78#issuecomment-378413850, or mute the thread https://github.com/notifications/unsubscribe-auth/AA_r-CW91tHAnIfmhu_WeLu9YXqqTYkgks5tk_F3gaJpZM4TCzAf .

[andreashorn]

A few more thoughts:

• Re "MINC is better behaved" I'd think this is likely not true. If you'd stay completely within one well-maintained environment (e.g. inside the "SPM world"), nifti is a near perfect file format with no issues attached whatsoever. Problems arise when using different tools that interpret headers differently. I'd bet that similar things could happen if every dev whatsoever started using MINC instead (and without properly consulting the specs).
• …then again IMHO this (everybody using minc) won't happen – if not a larger internatl. consensus body would agree to it (afaik this what was how NIfTI started in the first place). There are a multitude of file formats out there that are potentially superior to .nii (besides .mnc to name .nrrd, .mgh/mgz, .mrc). Still, .nii seems to have emerged as a consensus (given the sheer multitude of tools supporting it – most of them as their single format of choice).
• Re "FWIW, minc-toolkit already supports Nifti" and "these conversions are minimal overhead" I beg to differ. Given we are dealing with high-res files in my domain (and this may come to most domains sooner or later), the I/O overhead is substantial, e.g. when doing multimodal registrations on large datasets. I'd very much rather do this conversion in RAM then on disk. We already chose not to include BestLinReg into our pipeline given the I/O and speed/compat restrictions but it does include SPM, FLIRT, ANTs, BRAINSFit and Hybrid versions.
• Instead, I do agree with the thread on twitter that MINC tools would be widely used if they supported .nii natively (e.g. https://twitter.com/atypical_me/status/981450051401723904).

All this being said I completely understand your positions as devs especially due to being in similar positions often. You are researchers yourselves, not service providers and while pursuing your own work still do a great job in developing something definitely great that others may use for free!

Feature requests as mine are nothing but requests that sometimes can be met and sometimes may not – both of which needless to say is totally fine!

Thanks again for your thoughts and consideration, best from Berlin,

Andy

[vfonov]

@zijdenbos I think the conclusion of the meeting was that those people had so much trouble with minc because of the lack of documentation, not because something was wrong with minc-toolkit itself.

Implementing new features (like support for nifti) is not going to help in these cases.