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

[John G. Sled]

Hi Jonathon,

With respect to reading MINC1 files using the MINC2 API, a work around
that had been discussed was to implement the miopen call to spawn
mincconvert when needed.  This is still an option, however, it may not
be worth the trouble if the switch to MINC2 is rapid.  The change over
went so smoothly at MICe that it went unnoticed by most users.

The reason that the MINC2 API doesn't directly support MINC1 is that
it adds new concepts that don't map back onto the MINC1 format.  That
said, it is my understanding that converting a MINC1 file to MINC2 and
back is a lossless operation.

cheers,

John

On Mon, Jan 23, 2006 at 08:08:01AM -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