[Insight-developers] nifti-2 and transform io

[brian avants]

Hi Everyone

Below is a discussion with Mark Jenkinson about Nifti-2.   It’s
developing in stride with us and it would be great if we could try to
use compatible solutions and ideas to specify our transform i/o.   We
should see how this develops and discuss on t-con.

Brian


>>>>> brian to mark <<<<<

 hi mark

 am working on the itk deformable registration framework.  we are
 attempting to define a composite transformation file format ---
 something that would include a series of mappings that are composed
 together to perform a full map between different (subject/whatever)
 domains.

 the critical sub-transform type is the dense transform type.
 currently, the dense transform will include mappings derived from:

  bsplines
  velocity fields
  deformation fields
  finite element models

 and possibly other stuff we've not foreseen.  so, in defining an I/O
 type for these transforms, we've encountered the basic issue of how to
 define them "completely."  that is, what information should we put
 into the header that will facilitate transferring these transform
 types between researchers such that their application is clearly
 specified?   let's leave FEM off that list for now and assume we've
 mapped the FEM output to a displacement field.  one work-around we
 considered was having a text-based descriptor field that would
 hopefully let a researcher define the assumptions needed to apply such
 transforms.   not elegant or standard, but easy.

 do you know if there has there been significant progress on this
 topic?   is there a working document somewhere?   it's part of another
 problem, i think, that involves nomenclature and reproducibility as
 well.

 practically, the itk community has been leaning towards using the
 matlab binary format to 'solve' this problem.

 your thoughts much appreciated.

 brian

>>>>>  mark responds <<<<<


 A quick response for now, just to let you know that I'm enthusiastic
 about this.  The timing of this email is quite amazing.

 I have just been involved with updating the NIFTI standard over the
 last month and there is now a NIFTI-2 standard that has the capability
 of storing large data arrays (each dimension is now stored in a 64-bit
 field rather than the limiting 16-bit restriction that existed in NIFTI-1).

 Anyway, I have been thinking that this is exactly the right time to
 resurrect the discussion about a spatial transformation standard.
 Having got rid of this size restriction allows us to do some things
 with NIFTI files that we couldn't have done before, and I felt was a
 major limiting factor (and hence why the meeting we went to didn't
 go anywhere - well, that and the lack of further NIH support).

 So, I'm very keen to see if we can use the NIFTI format to store
 exactly this kind of information.  There is already a well documented
 and used system for voxel and mm coordinates within NIFTI,
 and so I don't think it would require too much work to start with that
 and build on it.  At least to the point that we could define a standard
 file format that people could use as an exchange format if they are
 already using their own format (assumedly the most common case)
 but something that could also be useful as a practical format too.

 I would really, really, really prefer that we did it via NIFTI (or something
 very similar) rather than a matlab binary.  Many packages - including FSL -
 would not deal well with such a format.  Whereas I think NIFTI would
 be readily supported by many of the major packages.  My recent experience
 in proposing the update to the NIFTI format has shown me that there is
 a lot of good-will towards NIFTI and developers are still very on-board
 with it as a format, even though it is far from perfect.

 So I'm keen to push forward on this, with NIFTI.  I hope that sounds good
 to you. The main things that we'll need to work on is documenting how
 the various representations need to be interpreted, and make it flexible
 enough so that existing packages can easily fit into this.  For example,
 we (FSL) store b-spline coefficients currently in a slightly non-standard NIFTI
 image, but there is no documentation on how these coefficients are
 converted into displacements, and that is what is needed.  Plus, if there
 are other b-spline implementations out there that have different ways
 of mapping between coefficients and displacements, then we don't want
 to be overly restrictive and force only one possibility.  As long as there is
 a defined formula for the conversion then we just need to identify what
 the formula is.  I think that the NIFTI intent codes are a good model for
 that (although I don't think we should use intent codes - but our own
 codes for spatial transformations).  We can add whatever we want as a
 NIFTI extension, and that would be my proposed solution.

 So let me know what you think in principle, and I'm glad that this timing
 has worked out so well.


>>>>> brian to mark <<<<<

>
> i really appreciate that you are interested in this topic.  and it
> would be great if we could cooperate at least on design.   ideally,
> itk would support both the matlab solution and the nifti solution.
> even better if they were compatible/translatable.
>
> do you have a guess as to how far off the nifti-2 standard is from
> being available?   if it's not shortly or immediately available then
> we may have to go with the matlab hack for now while aiming, design
> wise, to be able to support the nifti solution when it emerges.
>
> do you mind if i restart this discussion on the itk dev list to see
> what the rest of the itk community thinks?


>>>>> mark again <<<<<


Hi Brian,

The NIFTI-2 format is released officially as of last week!
However, we haven't got updated libraries or a full
header file yet, just a document with the definition in
(posted on NITRC in the NIFTI forum).  I hope that library
code, a full C header (like NIFTI-1) and example files
will be available very soon.

As for starting a discussion on ITK - go for it.
I would certainly be keen for a compatible/translatable
solution as we (FSL) are not in a position to easily adopt
anything matlab-like.

I will also email the people who attended the meeting
at the NIH (quite a few years ago now) and see who is
interested in being involved in this now.

Cheers,
       Mark