[Insight-developers] nifti-2 and transform io

[Johnson, Hans J]

Brian, Nick, and ITK,

Kent Williams and I have been looking at the HDF5 file format, and it is
looking promising as a way to store heterogenous composed transforms of
various types, along with all the necessary meta-data needed to properly
reconstruct the transform chain.

I wanted to let you know of those efforts as well to see if we can all
share the work load.

The HDF5 format has many independent tools (Matlab, R, standalone tools,
etc...) that can be used to validate or interogate those files during a
debugging session.

Hans


On 3/21/11 11:58 AM, "brian avants" <stnava at gmail.com> wrote:

>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
>_______________________________________________
>Powered by www.kitware.com
>
>Visit other Kitware open-source projects at
>http://www.kitware.com/opensource/opensource.html
>
>Kitware offers ITK Training Courses, for more information visit:
>http://kitware.com/products/protraining.html
>
>Please keep messages on-topic and check the ITK FAQ at:
>http://www.itk.org/Wiki/ITK_FAQ
>
>Follow this link to subscribe/unsubscribe:
>http://www.itk.org/mailman/listinfo/insight-developers



________________________________
Notice: This UI Health Care e-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged.  If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited.  Please reply to the sender that you have received the message in error, then delete it.  Thank you.
________________________________