[MINC-development] MINC 2 - re transitioning from MINC 1

[Leila Baghdadi]

Hello Jonathan,

Hmm, I must say to my knowledge we have spent a fair bit of time trying
to make decisions for the sole purpose of making libminc2 alot simpler
and certainly less painful than what you have described hence I find
your e-mail unfair!
Specifically, the backward compatibility code which was done by Bert and
works like a charm! I say this because I have recently converted almost
every single tool and application that uses minc files out there to
manage minc2 files and it has been so simple than I had difficulty
believing it myself!

1. All minc tools (i.e, tools that are part of minc source directory)
work with both minc1 and minc2 files and can produce minc2 files
exclusively! As Jason mentioned, you just need to build it properly.

2. Programs like Display and register now have --with-minc2 option (once
again thanks to Bert) which allows you to build it in such a way that
you can

read minc1 file --> write minc1 file
read minc2 file --> write minc2 file
in register
read minc1 and minc2 file --> resample minc1 file
read all minc2 files --> resample to minc2 file
As Bert mentioned in his e-mail

3. I have personally built the following to support minc2 (as I said
with very little changes)
xdisp
Emma
mincmorph
py_minc
and the list goes on

4. I have also written code to support minc2 IO
for 

ITK
VTK --> this is for our visualization program which reads all sorts of
images (i.e, multi-channel and time series)
Amira

so these ones read only minc2 files but you can check the first three
bytes of any file and figure out whether it is "CDF" or "\211HDF" 
and send it to the right reader/writer (i.e, if you have say an old VTK
reader that reads minc1 files you can continue using it)

5. Finally, thanks to its simplicity and speed I have recently converted
our MR scanner to produce minc2 files exclusively and I am now working
on converting our other modalities (i.e, CT and OPT and so on).

People in our lab (Mouse Imaging Center in Toronto) seem to be very
happy with minc2 and believe me some of them are real serious computer
geeks (i.e, Jason) and it is not very easy to satisfy them!!

6. The only thing that I am not very happy about is the documentation
which Bert and I have put some effort into but due to having so many
other things to do is not complete yet. I do have plans however to work
on them when I get some time!

I certainly hope that you continue using minc2 and please do not
hesitate to ask questions should you require any help.

Thanks

Leila

On Mon, 2006-23-01 at 08:08 -0500, Jonathan Harlap wrote:
> Heylas,
> 
> Seduced by the exceedingly more user-friendly API of libminc2, I 
> recently attempted to use it rather than libminc1 or volume_io for some 
> new code I'm working on.  I felt it would be a good learning experience 
> and that I might as well write code looking to the future rather than 
> sticking with MINC1 forever.  My findings were somewhat disappointing, 
> raising some questions about how people should be expected to transition...
> 
> 1) libminc2 doesn't open minc1 (NetCDF-based) files.  I suppose that one 
> could argue that being a new library for a new file format, it doesn't 
> need to be backwards compatible.  However, if I write a new tool, I 
> don't want to limit its functionality to a file format that hasn't yet 
> been adopted.  So, I guess it's back to the minc1 library (meaning, 
> libminc, not MINC 1.x).  Which is really disappointing, because the new 
> API doesn't seem inherently incompatible with minc1 format files.  I'm 
> curious if anyone out there actually writes code for libminc2?  Are they 
> expecting that people will happily go convert all their data?  We have 
> terabytes of data - converting it all would be fairly complicated, to 
> put it mildly.  Not to mention, that even had we converted it all, as 
> soon as someone runs a minc tool, odds are we'll have minc1 files again
> 
> 2) The command line tools default to creating minc1 format files.  This 
> seems really counterproductive - if I just upgraded from minc1 to minc2, 
> shouldn't you be encouraging me to create minc2 files and require me to 
> make a little extra effort if I still want to create minc1 files - as 
> opposed to requiring me to make extra effort if I want to create minc2 
> files?  This also extends to libminc, wherein unless I direct it 
> explicitly, micreate will keep me with minc1 files if I pass it minc1 
> files.  Actually, it'll even keep me with minc1 files if I call micreate 
> before opening any other minc files.  This kind of behaviour seems 
> designed to encourage people to continue using minc1 rather than getting 
> them to start creating minc2 files and slowly weaning them off the old 
> format.
> 
> 3) The library has absolutely no error reporting from what I can tell. 
> While testing my code and finding that a simple miopen_volume call 
> failed on a file that other minc tools had no problem reading, it took 
> me reading through the libminc2 source code to figure out why, because I 
> couldn't ask the library what was wrong.  (Turns out I was naively 
> trying to read a minc1 format file with libminc2...  See issue 1.)
> 
> 
> I have to wonder what prompted these design decisions - am I missing 
> some fundamental truth, or is libminc2 really meant to look good but not 
> be used?  Are there any sites actually using minc2?  Are they actually 
> adding -2 options to *every* command, or are they really just running 
> MINC 2.x but only using the minc1 file format?  If the latter, then 
> what's the point of MINC 2.x?
> 
> Cheers,
> J
> _______________________________________________
> MINC-development mailing list
> MINC-development at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development