[Insight-developers] nifti-2 and transform io
Nicholas Tustison
ntustison at gmail.com
Wed Mar 23 10:12:10 EDT 2011
Thanks Kent. I'll try it out and hopefully I'll be able to get it to work.
On Mar 23, 2011, at 10:08 AM, Williams, Norman K wrote:
> It's in the BRAINS Repository.
>
> http://www.nitrc.org/plugins/scmsvn/viewcvs.php/BRAINS/trunk/SuperBuild/Ext
> ernal_HDF5.cmake?revision=12960&root=brains&view=markup
>
> Theres a fair amount of CMAKE_FLAGS that could be trimmed away, and some
> stuff that wouldn't be necessary in the context of ITK.
>
> I found a weird problem with static functions coming up undefined if
> -fopenmp was in the CFLAGS, so there's a workaround to remove that flag.
>
> Essentially this will workL
>
> set(HDF5_INSTALL_PREFIX
> "${CMAKE_INSTALL_PREFIX}" CACHE PATH
> "Where ever you want installed files to go")
> ExternalProject_add(HDF5
> SOURCE_DIR HDF5
> BINARY_DIR HDF5-build
> SVN_REPOSITORY http://svn.hdfgroup.uiuc.edu/hdf5/branches/hdf5_1_8
> UPDATE_COMMAND ""
> CMAKE_ARGS
> # if you build debug you get libraries with _debug in their names
> # which is impossible to deal with. & it isn't like we're going
> # to be debugging HDF any time soon.
> -DCMAKE_BUILD_TYPE:STRING=Release
> -DHDF5_ENABLE_Z_LIB_SUPPORT:BOOL=On
> -DHDF5_BUILD_CPP_LIB:BOOL=On
> -DHDF5_BUILD_TOOLS:BOOL=On
> -DCMAKE_INSTALL_PREFIX:PATH=${BRAINS3_INSTALL_PREFIX}
> INSTALL_DIR ${HDF5_INSTALL_PREFIX}
> )
>
>
>
>
>
>
> --
> Kent Williams norman-k-williams at uiowa.edu
>
>
>
>
>
>
> On 3/23/11 7:55 AM, "Nicholas Tustison" <ntustison at gmail.com> wrote:
>
>> Hans & Kent,
>> Do you have the cmake external project files available somewhere (perhaps
>> in BRAINSFit)? It looks promising but it would be nice to start looking
>> under
>> the hood.
>>
>> Thanks,
>> Nick
>>
>>
>>
>> On Mar 22, 2011, at 7:29 PM, Johnson, Hans J wrote:
>>
>>
>> Kent has already written the necessary cmake external project files for
>> this, so it is quite easy to add in a non-intrusive way and can be
>> optionally selected/deselected during configuration time.
>>
>>
>> Currently there are no suitable solutions in ITK to handle the complex
>> and extensible needs of composite transform reading/writing, and this
>> looks like a promising well established library to help with that.
>>
>>
>> Hans
>>
>>
>>
>>
>> From: Bill Lorensen <bill.lorensen at gmail.com>
>> Date: Mon, 21 Mar 2011 21:43:29 -0400
>> To: Hans Johnson <hans-johnson at uiowa.edu>
>> Cc: brian avants <stnava at gmail.com>, ITK <insight-developers at itk.org>,
>> Mark Jenkinson <mark at fmrib.ox.ac.uk>
>> Subject: Re: [Insight-developers] nifti-2 and transform io
>>
>>
>>
>> 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 <http://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 <http://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 <http://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
>>
>>
>>
>>
>>
>> _______________________________________________
>> 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.
> ________________________________
More information about the Insight-developers
mailing list