CoBrALab / atlases

Segmentations of Neuroanatomy on Hi-Res T1 and T2 MRIs and publicly available population averages in MNI space
Other
27 stars 18 forks source link

for your consideration: support other formats #6

Open fedorov opened 8 years ago

fedorov commented 8 years ago

It is not very trivial to convert .mnc to other formats. There are many questions about going from mnc to other formats if one googles (and I did), but there are no binary tools for conversion. Perhaps the reason is that MINC software has LGPL license Anyway, I've just been through the exercise to help a colleague of mine with this task, and it took much longer than I thought, so I decided to spend this extra bit of time to document and report to you.

I think your atlas might be more useable to the community if you provided labels in formats other than mnc. I attach the file I converted for my colleague so you can use it for your purposes.

The recipe I used to convert:

  1. have a build of 3D Slicer handy
  2. In the ITKv4-build directory in Slicer super-build change the variable Module_ITKIOMINC to on
  3. Run make from the Slicer superbuild directory - this will rebuild ITK and SimpleITK
  4. The MINC reader will still not be available in the Slicer "Add data" dialog to load MINC files, but you can do it via the python console: Ctrl+3 will show the python console, then you can do the following
>>> import SimpleITK as sitk
>>> i=sitk.ReadImage("your_file.mnc")
>>> sitk.WriteImage(i,"your_compressed_file.nrrd",True)

Resulting file: thalamus_subdivisions.nrrd.zip

Hopefully this is helpful to you, or other people who would have the same issue.

fedorov commented 8 years ago

followup for completeness:

I opened the data into my scene, but it doesn’t seem to line up with the colin27 images or the surface rendering of the thalamus.

Looks like perhaps the A/P directions are flipped?

and a bit later

It lines up after reflection in y

ps I found this opening about MINC rather ironic: "The MINC file format and toolbox was originally conceived, written and released by Peter Neelin in 1992 due to the frustrations of dealing with multiple file formats from varying scanners and research groups." The result feels like exactly the opposite of the original intent ...

dzenanz commented 8 years ago

Neither first nor last: https://xkcd.com/927/

gdevenyi commented 8 years ago

The core of the minc-tools contains the program mnc2nii which produces NIFTI files. It is available for Ubuntu: http://packages.ubuntu.com/search?keywords=minc-tools&searchon=names&suite=all&section=all Debian: https://packages.debian.org/search?keywords=minc-tools&searchon=names&exact=1&suite=all&section=all

The full superset of minc-toolkit is available at https://bic-mni.github.io/ for a variety of platforms, as both source and binary.

Furthermore, MINC is also supported by ITK and ANTs via the superbuild (https://github.com/stnava/ANTs/pull/198), so the ConvertImage tool can convert to/from NIFTI/MINC.

The MINC format has a documented standard https://en.wikibooks.org/wiki/MINC/SoftwareDevelopment/MINC2.0_File_Format_Reference and a reference open-source reader for that standard: https://github.com/BIC-MNI/libminc

Unfortunately, I cannot say the same for other tools. For example, which NIFTI file do I support? SPM2? SPM5? SPM12? FSL? Freesurfer? Which do I find the standards documents?

These files were created and are used with the official BIC release of colin27 available here http://www.bic.mni.mcgill.ca/ServicesAtlases/Colin27.

fedorov commented 8 years ago

Neither I nor my collaborator had an Ubuntu or debian Linux to try the packages you suggested.

FYI your windows or Mac packages do not include the tool you mentioned.

NIFTI and NRRD work out of the box with the binary of Slicer I can download for any of the three platforms.

gdevenyi commented 8 years ago

OSX Install https://bic-mni.github.io/#on-macos-x-107-and-109

And usage instructions: https://bic-mni.github.io/#using

gdevenyi commented 8 years ago

Since libminc is integrated into ITK, any ITK tool (such as Slicer or ITKSnap) can enable MINC support through an adjustment of their build system and allowance of MINC files in their UI, perhaps asking for that there would be a good place to look

https://github.com/Slicer

https://groups.google.com/forum/#!forum/itksnap-dev

fedorov commented 8 years ago

Thanks for pointing to the Mac binaries. Hope this will help someone who runs into this issue next time. I don't have a current need for this atlas or MINC. I was just helping a colleague.

About the support of this format, as I mentioned, MINC libraries are covered by LGPL license (according to Bill Lorensen), incompatible with 3D Slicer. It cannot be included.

gdevenyi commented 8 years ago

The main difference between the GPL and the LGPL is that the latter allows the work to be linked with (in the case of a library, 'used by') a non-(L)GPLed program, regardless of whether it is free software or proprietary software.[1]

https://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License#Differences_from_the_GPL

Looks A-OK to me. It will just be linked against.

dzenanz commented 8 years ago

LGPL is problematic for static library route.

Many people (myself included) prefer to compile libraries as static to avoid the problem of DLL hell during software development. Especially important if you have a dozen different versions of the same library (as I have of ITK and VTK).

gdevenyi commented 8 years ago

Still looks okay to me https://www.gnu.org/licenses/gpl-faq.en.html#LGPLStaticVsDynamic

gdevenyi commented 8 years ago

On a side note, should you be attempting to use 3DSlicer and these atlases to segment other files, we provide a pipeline that supports NIFTI as an input, to do automatic segmentation of scans https://github.com/CobraLab/antsRegistration-MAGeT

Based on ANTs tools + the MAGeT algorithm.

gdevenyi commented 8 years ago

One more way to get all the MINC tools in one place I forgot to mention:

I build an automated VM based on ubuntu 16.04 available here https://github.com/cobralab/MINC-VM

gdevenyi commented 8 years ago

After a followup with the libminc developers, turns out most of the MINC tools are released under a permissive MIT-like licence: https://github.com/BIC-MNI/libminc/blob/master/COPYING

fedorov commented 8 years ago

@gdevenyi, again, to cite the thread I mentioned earlier, according to Bill Lorensen @lorensen, who has a lot of expertise in this area:

MINC has an LGPL license which is not compatible with the ITK apache license. This is why we make it an optional build.

So there is a confusion on either MINC or ITK side.

If you want your format have better support in tools like ITK and 3D Slicer, you might want to follow up with the respective groups and invest effort into improving that support. I have neither resources nor need to work on this.

The purpose of submitting this issue was to help other users of your atlas, so that my time spent investigating the conversion issues can benefit someone else, and to raise your awareness about the limitations of this format support. You take it from there as you see appropriate.

HTH

lassoan commented 8 years ago

Great discussion! We've been planning enabling MINC IO support in Slicer build (http://www.na-mic.org/Bug/view.php?id=4085) but we constantly run into build problems on Windows. If you can help in fixing those then I'd be happy to assist with getting it into Slicer.

lassoan commented 8 years ago

For example, if I enable Module_ITKIOMINC CMake option in Slicer's ITK build then I get this error (Windows, VS2013):

1>------ Build started: Project: ZERO_CHECK, Configuration: Debug x64 ------
...
2>------ Build started: Project: itkvcl, Configuration: Debug x64 ------
3>------ Build started: Project: itkv3p_netlib, Configuration: Debug x64 ------
4>------ Build started: Project: itknetlib, Configuration: Debug x64 ------
5>------ Build started: Project: itksys, Configuration: Debug x64 ------
6>------ Build started: Project: itkdouble-conversion, Configuration: Debug x64 ------
7>------ Build started: Project: gdcmCommon, Configuration: Debug x64 ------
8>------ Build started: Project: ITKEXPAT, Configuration: Debug x64 ------
9>------ Build started: Project: ITK_bld_internal_H5make_libsettings, Configuration: Debug x64 ------
...
49>------ Build started: Project: itkminc2, Configuration: Debug x64 ------
49>  Building Custom Rule C:/D/S4D/ITKv4/Modules/ThirdParty/MINC/src/libminc/CMakeLists.txt
49>  CMake does not need to re-run because C:\D\S4D\ITKv4-build\Modules\ThirdParty\MINC\src\libminc\CMakeFiles\generate.stamp is up-to-date.
49>  convert.c
49>  datatype.c
49>  dimension.c
49>C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\math.h(515): error C2375: 'rint' : redefinition; different linkage
49>          c:\d\s4d\itkv4\modules\thirdparty\minc\src\libminc\libsrc2\minc2_private.h(209) : see declaration of 'rint'
49>  free.c
...
gdevenyi commented 8 years ago

Thanks @lassoan,

I'll notify the MINC maintainers of the attempts and problems you're running into.

gdevenyi commented 8 years ago

@lassoan For your bug, doing a quick dig through the MINC sources, rint used to be not supplied so it had to be supplied.

You can attempt to copy out the relevant code to see if the compile continues.

https://github.com/BIC-MNI/libminc/blob/develop/libsrc2/minc2_private.h#L209-L215

lassoan commented 8 years ago

After commenting out rint in header and c files, to compilation continues and I get other errors.

lassoan commented 8 years ago

2>C:\D\S4D\ITKv4\Modules\ThirdParty\MINC\src\libminc\libsrc2\hyper.c(52): error C2084: function 'double copysign(double,double)' already has a body 2> C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\math.h(483) : see previous definition of 'copysign' 2>C:\D\S4D\ITKv4\Modules\ThirdParty\MINC\src\libminc\libsrc2\hyper.c(65): error C2084: function 'double round(double)' already has a body 2> C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\math.h(516) : see previous definition of 'round'

commenting out copysign and round implementation makes the build continue...

lassoan commented 8 years ago

I get this error then:

1>------ Build started: Project: itkhdf5, Configuration: Debug x64 ------ 1> itkhdf5.vcxproj -> C:\D\S4D\ITKv4-build\lib\Debug\itkhdf5-4.10.lib 2>------ Build started: Project: itkminc2, Configuration: Debug x64 ------ 3>------ Skipped Build: Project: ITKHeaderTests, Configuration: Debug x64 ------ 3>Project not selected to build for this solution configuration 2> minc2_error.c 2> minc_config.c 2> Generating Code... 2> itkminc2.vcxproj -> C:\D\S4D\ITKv4-build\lib\Debug\itkminc2-4.10.lib 4>------ Build started: Project: ITKIOMINC, Configuration: Debug x64 ------ 4> Creating library C:/D/S4D/ITKv4-build/lib/Debug/ITKIOMINC-4.10.lib and object C:/D/S4D/ITKv4-build/lib/Debug/ITKIOMINC-4.10.exp 4>itkminc2-4.10.lib(minc_config.obj) : error LNK2019: unresolved external symbol strncasecmp referenced in function miread_cfg 4>C:\D\S4D\ITKv4-build\bin\Debug\ITKIOMINC-4.10.dll : fatal error LNK1120: 1 unresolved externals

Replacing strncasecmp by _strnicmp in minc_config.c makes the build complete!

lassoan commented 8 years ago

If you have a patch then let me know and I can test it.

You would need to set up a nightly Windows build or convince some ITK build machine developers to enable MINC so that you can see when something breaks.

lassoan commented 8 years ago

I've just noticed the link to https://github.com/BIC-MNI/libminc/issues/75. If you can get MINC enabled on ITK by default that will make MINC support widely available. Many ITK-based applications will just start to recognize MINC file formats without requiring any change from app developers (in Slicer it requires a few minor changes that I'll be happy to make). It'll also take care of quality control, as errors will show up on standard ITK dashboards.

fedorov commented 8 years ago

A request from my collaborator, 2 weeks after I helped him with some of the atlases ... just to remind you - this is real!

I am really sorry to ask this of you, but would you be able to save [the attached .mnc files] to .nrrd also?

vfonov commented 7 years ago

there is itk_convert binary include inside minc-toolkit_v2 - you can run that to convert minc to nrrd.

gdevenyi commented 7 years ago

Hi,

There is now a lightly quality-controlled (aka it looks okay to me) NIFTI version of files available for download at: http://cobralab.net/files/atlases-nifti.zip http://cobralab.net/files/brains_t1_nifti.tar.bz2

vfonov commented 7 years ago

so, what is it for?

gdevenyi commented 7 years ago

@vfonov discussion above requesting NIFTI versions of the CoBrALab atlases

fedorov commented 7 years ago

There is now a lightly quality-controlled (aka it looks okay to me) NIFTI version of files available for download at

It would make sense to me to note this fact in the README

gdevenyi commented 7 years ago

@fedorov for now, these are unofficial so they're not going to go there yet.

fedorov commented 7 years ago

This means that chances of them being found are approaching nil. Either way is fine with me.

Have you ever tried to put yourself into the shoes of a researcher who has no clue and no interest to learn about the peculiarities of imaging formats, has very little time, has no patience, and just wants to use your atlas. Let's say, they just want to see it overlayed on the structural image. They come across your repo here: https://github.com/CobraLab/atlases. Did you ever consider they might be confused how to do that?

lassoan commented 7 years ago

I've downloaded the files and they all load correctly into 3D Slicer, so it's already a great step towards better compatibility. I'm not an expert in neuroimaging, but the segmentations look beautiful.

On Windows, extracting .tar.bz2 archives requires installation of an application. If you choose to make the images available in .zip format as well then that could be browsed/extracted by the built-in file manager without installing any additional software.

I'm not sure if atlases-nifti.zip is complete, as it only contains 6 subdirectories and in colin27-subcortical there are no labels. There is also a "bin" directory that might be left there accidentally, containing some temporary file and python scripts.

It might be useful to save the atlas in format that is optimized for use in specific applications (3D Slicer, ITK-Snap, MITK, ...). If you were interested, I can help in creating an atlas that can be easily loaded and reviewed in 3D Slicer, even upload it into the 3D Slicer Data Store so that users can download it with a single click (similarly to the SPL brain atlas - http://www.spl.harvard.edu/publications/item/view/2037).

Another thing that you might be interested in is joint smoothing of the segmentations. In 3D Slicer we have a smoothing method that is designed to smooth segmentations, smoothing all labels at once, smoothing boundaries while respecting interfaces (mesh remains watertight).

Segmentation of brain2 cerebellum loaded into 3D Slicer: 2017-03-05-original

![Result after joint smoothing with a factor of 0.3: 2017-03-05-smoothed-0 3

gdevenyi commented 7 years ago

@lassoan Thank you for the constructive feedback.

There indeed are missing files, which I will get to fixing up and uploading. Thank you also for the note re: .tar.bz2, as a linux-only shop I usually consider .zip to be harder to handle than other formats. I have now uploaded a zipped version (http://cobralab.net/files/brains_t1_nifti.zip) and I have updated for the missing files (http://cobralab.net/files/atlases-nifti.zip). The extra directories are there because this zip file was (supposed) to just be a copy of this repository with nifti instead of mnc, so I just kept everything else.

As for the slicer files, we do not currently use slicer nor does anyone I know, so I really have no clue how to produce such files. I would be interested in some help to produce a slicer version.

As for smoothing, this operation is not in line with our intent for these atlases, which are all intended as a anatomically-informed manually segmented ground-truth and are a result of the exact segmentation protocol. Users are of course welcome to do with them as they wish, but we will keep our versions as produced by our anatomists.