[MINC-development] minc 2.2.00

[Sean McBride]

On Mon, 24 Sep 2012 20:34:07 -0400, Andrew Janke said:

>And this is the point exactly. The idea is to have an option in the
>libminc build that will disable MINC1 (as compared to before where you
>enable MINC2).

Understandably desirable.

>As part of this we will shift a few chunks of volume_io to minc2 that
>are required. At the moment this is for reading of transforms and tag
>files only so that ITK can support these also.

Nice.

>As for MINC1 support, Vlads ezminc based ITK reader already does this
>as does the original one for ITK.

To what do you refer by "the original one for ITK".  Do you mean itkMINC2ImageIO in ITK3?  It only does MINC2.

>Still it's messy and the netCDF
>dependency precludes MINC's inclusion into ITK so MINC2 only it is.

Does it?  Did anyone ask the ITK maintainers about this?

>As for MINC1 files, the best way around this that I see is a
>stand-alone mincconvert.

We currently use ITK3 to read ACR-NEMA, DICOM, PAR/REC, Analyze, NIfTI-1, and MINC2.  And I use VTK to read MINC1 (vtkMINCImageReader).  I was really hoping some future MINC reader from you guys could do both MINC1&2 so that ITK could open everything. :)

It's understandable that the ITK devs might not want to add yet another 3rd party library (NetCDF) to ITK.  But for all the 3rd party libs ITK includes, it also lets you point to your own copy, instead of ITK's, ex: ITK_USE_SYSTEM_ZLIB.  Perhaps ITK could at least let you point it to your own NetCDF then your reader could have some "#ifdef NETCDF_FOUND" stuff to support MINC1 files anyway?

Cheers,

-- 
____________________________________________________________
Sean McBride, B. Eng                 sean at rogue-research.com
Rogue Research                        www.rogue-research.com 
Mac Software Developer              Montréal, Québec, Canada