[MINC-development] MINC 2 - re transitioning from MINC 1
Jonathan Harlap
jharlap at bic.mni.mcgill.ca
Mon Jan 23 08:08:01 EST 2006
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
More information about the MINC-development
mailing list