From jharlap at bic.mni.mcgill.ca Mon Jan 23 08:08:01 2006 From: jharlap at bic.mni.mcgill.ca (Jonathan Harlap) Date: Mon, 23 Jan 2006 08:08:01 -0500 Subject: [MINC-development] MINC 2 - re transitioning from MINC 1 Message-ID: <43D4D531.80203@bic.mni.mcgill.ca> 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 From jason at bic.mni.mcgill.ca Mon Jan 23 08:14:44 2006 From: jason at bic.mni.mcgill.ca (Jason Lerch) Date: Mon, 23 Jan 2006 08:14:44 -0500 Subject: [MINC-development] MINC 2 - re transitioning from MINC 1 In-Reply-To: <43D4D531.80203@bic.mni.mcgill.ca> References: <43D4D531.80203@bic.mni.mcgill.ca> Message-ID: . I'm > curious if anyone out there actually writes code for libminc2? Are > they > expecting that people will happily go convert all their data? Yup. And yup. Begone, ICVs!. The transition is quite painless - a single command during which no data or headers are lost - and since all the tools can work on minc2 files after a simple recompile (or so's the theory, which so far is holding true in practice), this really isn't that bad a deal. > 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 That default is easily changed. Moreover, the minc tools produce output files based on what the inputs where. So, given two input minc2 files, for example, mincmath should produce an output minc2 file as well. I'll let Bert and/or Leila speak to the design decisions ... Jason > > > 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 From bert at bic.mni.mcgill.ca Mon Jan 23 10:42:19 2006 From: bert at bic.mni.mcgill.ca (Robert VINCENT) Date: Mon, 23 Jan 2006 10:42:19 -0500 Subject: [MINC-development] MINC 2 - re transitioning from MINC 1 In-Reply-To: Message-ID: Hi, Keep in mind that once you have created MINC 2 files, most of the command line tools will default to creating MINC 2 output files. The rule is: 1. If _any_ of the input files are MINC 1, produce MINC 1 output 2. If _all_ of the input files are MINC 2, or if the "-2" flag is specified, produce MINC 2 output. -bert On Mon, 23 Jan 2006, Jason Lerch wrote: > . I'm > > curious if anyone out there actually writes code for libminc2? Are > > they > > expecting that people will happily go convert all their data? > > Yup. And yup. Begone, ICVs!. The transition is quite painless - a > single command during which no data or headers are lost - and since > all the tools can work on minc2 files after a simple recompile (or > so's the theory, which so far is holding true in practice), this > really isn't that bad a deal. > > > 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 > > That default is easily changed. Moreover, the minc tools produce > output files based on what the inputs where. So, given two input > minc2 files, for example, mincmath should produce an output minc2 > file as well. > > I'll let Bert and/or Leila speak to the design decisions ... > > Jason > > > > > > > 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 > > _______________________________________________ > MINC-development mailing list > MINC-development at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development > From baghdadi at sickkids.ca Mon Jan 23 12:00:52 2006 From: baghdadi at sickkids.ca (Leila Baghdadi) Date: Mon, 23 Jan 2006 12:00:52 -0500 Subject: [MINC-development] MINC 2 - re transitioning from MINC 1 In-Reply-To: <43D4D531.80203@bic.mni.mcgill.ca> References: <43D4D531.80203@bic.mni.mcgill.ca> Message-ID: <1138035652.5852.69.camel@localhost.localdomain> 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 From jgsled at sickkids.ca Mon Jan 23 15:11:12 2006 From: jgsled at sickkids.ca (John G. Sled) Date: Mon, 23 Jan 2006 15:11:12 -0500 Subject: [MINC-development] MINC 2 - re transitioning from MINC 1 In-Reply-To: <43D4D531.80203@bic.mni.mcgill.ca> References: <43D4D531.80203@bic.mni.mcgill.ca> Message-ID: <20060123201111.GC22140@sickkids.ca> 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