[Insight-developers] nifti-2 and transform io

Mon Mar 21 21:43:29 EDT 2011

the hdf5 library is pretty big (~250k lines of code). VTK uses it.

On Mon, Mar 21, 2011 at 7:28 PM, Johnson, Hans J <hans-johnson at uiowa.edu>wrote:

> 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.
> ________________________________
> _______________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20110321/afb5e93f/attachment.htm>