From minc-development@bic.mni.mcgill.ca Tue Jun 10 01:29:41 2003 From: minc-development@bic.mni.mcgill.ca (Andrew Janke) Date: Tue, 10 Jun 2003 10:29:41 +1000 Subject: [MINC-development] mincstats In-Reply-To: <20030608161614.B702593@shadow.bic.mni.mcgill.ca> References: <20030608161614.B702593@shadow.bic.mni.mcgill.ca> Message-ID: On Sun, 8 Jun 2003, Steve ROBBINS wrote: > > I think that the ambiguity may be why I did not set a default. Perhaps > > Steve's suggestion of an error is the simplest route. The user should be > > forced to be specific. > > I attach, therefore, a proposed change that will bark if you specify > -mask without specifying the mask values. I haven't committed this, > so please speak up before I do. Looks reasonable. My only change to this would be the error line to: fprintf(stderr, "%s: Please specify mask values using -mask_floor, -mask_ceil, -mask_range, or -mask_binvalue\n", argv[0]); Assuming this line is not hidden in a function! I have got in the habit of doing this after attempting to figure out what has gone wrong in a script from log files, only to come to error as such: "Incorrect input range". or the likes. :) > What *do* you mean by "binary mask"? For me, it's C-ish, anything that isn't a 0 is fg. But I often use mask files which contain multiple masks using different values. a From minc-development@bic.mni.mcgill.ca Wed Jun 11 03:45:09 2003 From: minc-development@bic.mni.mcgill.ca (Peter NEELIN) Date: Tue, 10 Jun 2003 22:45:09 -0400 Subject: [MINC-development] mincstats In-Reply-To: <20030608161614.B702593@shadow.bic.mni.mcgill.ca> Message-ID: On Sun, 8 Jun 2003, Steve ROBBINS wrote: > I attach, therefore, a proposed change that will bark if you specify > -mask without specifying the mask values. I haven't committed this, > so please speak up before I do. 'Looks good. > Incidentally, this thread has made me realize that I don't know what > folks mean by the term "binary mask". I have always thought in terms > of C boolean values. For me, I would interpret the set of zero voxels > as the background, and non-zero as the foreground. I get the feeling > that some would view voxels with value "1" as the foreground, and > everything else as background. What *do* you mean by "binary mask"? I suppose that binary mask means what you would expect: include all that voxels for which the mask evaluates to true. The mask is an operation applied to an input file. In mincstats, the operation can be either round(maskfile) == n, or min <= maskfile <= max. So the binary mask is not the mask file alone, but rather op(maskfile). BTW, the first operation mentioned is very useful for selecting a mask out of a file full of labels. Peter ---- Peter Neelin (neelin@bic.mni.mcgill.ca) From minc-development@bic.mni.mcgill.ca Fri Jun 13 21:42:31 2003 From: minc-development@bic.mni.mcgill.ca (John G. Sled) Date: Fri, 13 Jun 2003 16:42:31 -0400 Subject: [MINC-development] Draft API for MINC 2.0 Message-ID: <20030613164231.E9376@sickkids.ca> MINC developers, Bert, Leila, and I have put together a draft description of the API for MINC 2.0. It can be assessed on the web at http://www.bic.mni.mcgill.ca/users/jgsled/outgoing/minc2.0/ Please read it over a let us know what you think. If you find any loose ends please pull on them. We want the final API to comprehensive, self-consistent, general, easy to understand, easy to use and well documented. Post any suggestions, patches, new ideas, old and overlooked ideas, additional functions and corrections back to the list for discussion. cheers, John From minc-development@bic.mni.mcgill.ca Sat Jun 14 22:17:29 2003 From: minc-development@bic.mni.mcgill.ca (Steve ROBBINS) Date: Sat, 14 Jun 2003 17:17:29 -0400 Subject: [MINC-development] Draft API for MINC 2.0 In-Reply-To: <20030613164231.E9376@sickkids.ca>; from jgsled@sickkids.ca on Fri, Jun 13, 2003 at 04:42:31PM -0400 References: <20030613164231.E9376@sickkids.ca> Message-ID: <20030614171729.A375388@shadow.bic.mni.mcgill.ca> On Fri, Jun 13, 2003 at 04:42:31PM -0400, John G. Sled wrote: > http://www.bic.mni.mcgill.ca/users/jgsled/outgoing/minc2.0/ > > Please read it over a let us know what you think. If you find any > loose ends please pull on them. Wow -- that looks like a lot of work. Is there a gentler introduction that outlines the concepts and data types? For instance, what is a "group"? What is the "path" argument that many functions take? Is this api layered on top of hdf5? If so, is it necessary to understand it to read the new api document? If I view the current MINC libraries as volume_io layered on top of minc, which is in turn layered on top of netcdf; what "layer" is the new api? If it supplants both minc and volume_io, then does it make sense to group the new api in a similar set of layers? > We want the final API to > comprehensive, self-consistent, general, easy to understand, easy to > use and well documented. Can we add "extensible" to that list? -S From minc-development@bic.mni.mcgill.ca Mon Jun 16 06:06:53 2003 From: minc-development@bic.mni.mcgill.ca (Andrew Janke) Date: Mon, 16 Jun 2003 15:06:53 +1000 Subject: [MINC-development] Draft API for MINC 2.0 In-Reply-To: <20030614171729.A375388@shadow.bic.mni.mcgill.ca> References: <20030613164231.E9376@sickkids.ca> <20030614171729.A375388@shadow.bic.mni.mcgill.ca> Message-ID: On Sat, 14 Jun 2003, Steve ROBBINS wrote: > > http://www.bic.mni.mcgill.ca/users/jgsled/outgoing/minc2.0/ > > > > Please read it over a let us know what you think. If you find any > > loose ends please pull on them. > > Wow -- that looks like a lot of work. > > Is there a gentler introduction that outlines the concepts and > data types? For instance, what is a "group"? What is the "path" > argument that many functions take? Is this api layered on top of > hdf5? If so, is it necessary to understand it to read the new api > document? What Steve said. + Are you really really sure you want to add more data types? (COMPLEX, etc) I for one was happy with the idea of a 'vector_dimension/complex_vector' for these as it allowed a fair bit more flexibility. The reason I ask is that it's going to make the current "voxel_value_get" type functions a whole lot more difficult to grok. Do you return a pointer to a double and assume that double++ will contain the second part of the complex data point? or do you return a struct? or do you have a set of special functions like this: get_complex_voxel_value(starts[], double *real, double *imag) ? On a similar note, (and I don't know their real purpose yet), is there really a good reason to introduce things such as "TALAIRACH" types into a data format? these are head CT/MRI specific things are they not? By all means include them but I would have thought such a thing was better included as a user attribute using some C/L tool. Granted you have included it as what appears to be an optional extra. Extra wants/needs/desires: * gems such as voxel_loop() get transferred, and hopefully parallelised... :) * get_data_from_world_point(ulong coord[]) ie: internal interpolation that returns null/0 when out of bounds. This may well be a very slow function but such is life. * 'noob' functions? get_voxel_data_3d(x, y, z) ala volume_io ? Apart from that I like a lot, expecially the functions with hypercube in their names... ;) a From minc-development@bic.mni.mcgill.ca Mon Jun 16 14:55:24 2003 From: minc-development@bic.mni.mcgill.ca (John G. Sled) Date: Mon, 16 Jun 2003 09:55:24 -0400 Subject: [MINC-development] Draft API for MINC 2.0 In-Reply-To: <20030614171729.A375388@shadow.bic.mni.mcgill.ca>; from stever@bic.mni.mcgill.ca on Sat, Jun 14, 2003 at 05:17:29PM -0400 References: <20030613164231.E9376@sickkids.ca> <20030614171729.A375388@shadow.bic.mni.mcgill.ca> Message-ID: <20030616095524.A19276@sickkids.ca> Hi Steve, > Is there a gentler introduction that outlines the concepts and > data types? For instance, what is a "group"? What is the "path" > argument that many functions take? Is this api layered on top of > hdf5? If so, is it necessary to understand it to read the new api > document? The plan is to have a top level document explaining the concepts, but it hasn't been written yet -- partly because some of the concepts are still fluid. With respect to layering, the plan is as follows. HDF5 is the bottom level layer which the programmer never sees or requires the documentation. The old libminc API is present with as much of its functionality retained as is consistent with the new libminc API (i.e. almost all of it). The new libminc API is what our new document describes. This is intended to replace the use of libminc and appeal to as broad a group of MINC programmers as possible. It is intended to provide the full power and flexibility of MINC while leaving the memory management issues to the programmer, hence the emphasis on hypercube related functions. VolumeIO will be updated to sit on top of the new libminc and keep its existing API perhaps with the namespace issues cleaned up. In the future we would like to produce a VolumeIO 2 that takes advantage of more of the features of libminc while continuing to provide memory management. With respect to groups and paths, the plan is to treat volume attributes (patient name etc.) as having a unix-file-system-like structure. In this scheme a group is analogous to a directory (eg. /patient_info) and a path is just that (eg. /patient_info/patient_name). > Can we add "extensible" to that list? I think we have left a few hooks for extending future revisions. We would welcome more suggestions though. It is not clear to me how to let users extend the format themselves without breaking the core tool set. Is there something you have in mind? cheers, John From minc-development@bic.mni.mcgill.ca Mon Jun 16 19:27:00 2003 From: minc-development@bic.mni.mcgill.ca (Robert VINCENT) Date: Mon, 16 Jun 2003 14:27:00 -0400 Subject: [MINC-development] Draft API for MINC 2.0 In-Reply-To: Message-ID: On Mon, 16 Jun 2003, Andrew Janke wrote: > Are you really really sure you want to add more data types? (COMPLEX, etc) I > for one was happy with the idea of a 'vector_dimension/complex_vector' for these > as it allowed a fair bit more flexibility. > My assumption was that adding some intrinsic support for complex data would be useful, and that we would ultimately allow arbitrarily-sized and -structured voxel values. So nothing would prevent you from continuing to use a vector type. Remember that 99% of the traditional MINC ways of accomplishing things should continue to work! > Do you return a pointer to a double and assume that double++ will contain the > second part of the complex data point? or do you return a struct? or do you > have a set of special functions like this: > > get_complex_voxel_value(starts[], double *real, double *imag) > I think we would standardize the layout of the complex data types (real first, imaginary second) so that a complex could reliably be returned as a "C" structure or an array of alternating values (real0, imag0, real1, imag1, etc...). Some flavor of get_voxel_value() will just take a void * and "do the right thing" based on the requested type. > > On a similar note, (and I don't know their real purpose yet), is there really a > good reason to introduce things such as "TALAIRACH" types into a data format? > these are head CT/MRI specific things are they not? By all means include them > but I would have thought such a thing was better included as a user attribute > using some C/L tool. Granted you have included it as what appears to be an > optional extra. > I don't know its true utility, but this is just a carryforward of the "spacetype" attribute that was already specified in MINC 1.0. MIspacetype, MI_TALAIRACH, MI_CALLOSAL etc. are already defined in minc.h -bert From minc-development@bic.mni.mcgill.ca Mon Jun 16 23:57:53 2003 From: minc-development@bic.mni.mcgill.ca (Andrew Janke) Date: Tue, 17 Jun 2003 08:57:53 +1000 Subject: [MINC-development] Draft API for MINC 2.0 In-Reply-To: <20030616095524.A19276@sickkids.ca> References: <20030613164231.E9376@sickkids.ca> <20030614171729.A375388@shadow.bic.mni.mcgill.ca> <20030616095524.A19276@sickkids.ca> Message-ID: On Mon, 16 Jun 2003, John G. Sled wrote: > With respect to groups and paths, the plan is to treat volume > attributes (patient name etc.) as having a unix-file-system-like > structure. In this scheme a group is analogous to a directory > (eg. /patient_info) and a path is just that > (eg. /patient_info/patient_name). nice. Are there plans to use XML or some other thingo for this representation? a From minc-development@bic.mni.mcgill.ca Tue Jun 17 00:07:33 2003 From: minc-development@bic.mni.mcgill.ca (Andrew Janke) Date: Tue, 17 Jun 2003 09:07:33 +1000 Subject: [MINC-development] Draft API for MINC 2.0 In-Reply-To: References: Message-ID: On Mon, 16 Jun 2003, Robert VINCENT wrote: > > Are you really really sure you want to add more data types? (COMPLEX, etc) I > > for one was happy with the idea of a 'vector_dimension/complex_vector' for these > > as it allowed a fair bit more flexibility. > > My assumption was that adding some intrinsic support for complex data > would be useful, and that we would ultimately allow arbitrarily-sized and > -structured voxel values. So nothing would prevent you from continuing to > use a vector type. Remember that 99% of the traditional MINC ways of > accomplishing things should continue to work! True. However if I were to write a viewer for all types of MINC data, it just got harder. Currently all I have to worry about are 3D and 4D scalar files, how does one view a complex file? or a structured file? to my mind this sort of notion introduces breakage further down the lines as each and every command line tool will have to be more complex (pun :). But don't let my rambling stop you!, you just might find yourselves re-writing mincresample, mincreshape, etc. ;) a From minc-development@bic.mni.mcgill.ca Tue Jun 17 08:49:11 2003 From: minc-development@bic.mni.mcgill.ca (Andrew Janke) Date: Tue, 17 Jun 2003 17:49:11 +1000 Subject: [MINC-development] minccmp Message-ID: Well this is what I have after about 2 hours this afternoon... /software/source/minc_dev/minccmp Sorry to those unable to access the BIC! but I think this is where the inital voldiff et al argument started (or was it the geeks list?) Anyhow, all it currently does is xcorr, so I am on the hunt for other objective functions that people use to compare volumes. I have zscore and variance ratio on the to-do list but they are fairly simple. I'm more after what stats within voldiff do people use? (and are preferably voxel-based). An equation for these might be nice too! :) Now that I think of it, sums of squares would seem an obvious omission. I have attempted to write minccmp in such a way that comparisons of similarity between more than 2 volumes should be possible, if the stat allows it of course!. Thoughts? (or should I just stop writing for MINC 1.x and wait for 2.x! ;) -- Andrew Janke ( rotor@cmr.uq.edu.au || www.cmr.uq.edu.au/~rotor ) Australia->University of Queensland->Centre for Magnetic Resonance Work: +61 7 3365 4100 || Home: +61 7 3800 4042 From minc-development@bic.mni.mcgill.ca Tue Jun 17 15:36:30 2003 From: minc-development@bic.mni.mcgill.ca (Alex ZIJDENBOS) Date: Tue, 17 Jun 2003 10:36:30 -0400 Subject: [MINC-development] minccmp In-Reply-To: ; from rotor@cmr.uq.edu.au on Tue, Jun 17, 2003 at 05:49:11PM +1000 References: Message-ID: <20030617103630.D540520@shadow.bic.mni.mcgill.ca> --IS0zKkzwUGydFO0o Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Jun 17, 2003 at 05:49:11PM +1000, Andrew Janke wrote: > > I'm more after what stats within voldiff do people use? (and are preferably > voxel-based). An equation for these might be nice too! :) voldiff mainly produces the kappa statistic, as well as confusion matrix, sensitivity, specificity, etc. See attached for sample output. Vasco describes most of these in his thesis, see http://www.bic.mni.mcgill.ca/~alex/docs/vasco_thesis.pdf As for AZSM (I'll let you figure out the acronym assigned by Vasco :), that comes from my theseis work. You can find that, and my Dec 94 TMI paper which summarizes it, in the same place (dissertation.pdf, zijdenbos_tmi_dec_1994.pdf). Hope this helps, -- Alex ========================================================================= | Alex P. Zijdenbos, Ph.D. | | | McConnell Brain Imaging Centre | Phone: [+1] 514 398-5220 (office) | | Montreal Neurological Institute | [+1] 514 398-1996 (dept.) | | 3801 University St., WB-208 | Fax: [+1] 514 398-8952 (office) | | Montreal, Quebec, H3A 2B4 | [+1] 708 810-3309 (private) | | CANADA | E-mail: alex@bic.mni.mcgill.ca | ========================================================================= --IS0zKkzwUGydFO0o Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="voldiff.txt" Confusion matrix for the following volumes : Volume1 (row-left) = 00097/classify/nih_chp_00097_cls_t1_classify-clean_csf-gm-wm.mnc.gz Volume2 (col-top) = 00094/classify/nih_chp_00094_cls_t1_classify-clean_csf-gm-wm.mnc.gz Confusion matrix of class distribution class 0 1 2 3 Total 0 2979755 203336 131910 106191 3421192 1 174444 382482 263093 92199 912218 2 62540 330494 852565 277640 1523239 3 81171 191183 452313 527821 1252488 Total 3297910 1107495 1699881 1003851 7109137 Collapsed confusion matrix statistics discribing different similarity measures: Class Kappa CKappa AZSM Sensit. Error Specif. Accuracy 0 0.7593 0.7857 0.8870 0.8710 0.1290 0.9137 0.8932 1 0.3121 0.2770 0.3787 0.4193 0.5807 0.8830 0.8235 2 0.4213 0.3915 0.5290 0.5597 0.4403 0.8483 0.7865 3 0.3263 0.3689 0.4679 0.4214 0.5786 0.9187 0.8311 Total 0.5109 0.5109 0.6844 0.6671 0.3329 Combined Kappa statistics: Total_Kappa=0.5109 Brain_Kappa=0.3593 Paren_Kappa=0.3756 --IS0zKkzwUGydFO0o-- From minc-development@bic.mni.mcgill.ca Tue Jun 17 18:07:38 2003 From: minc-development@bic.mni.mcgill.ca (Vicka Corey) Date: Tue, 17 Jun 2003 13:07:38 -0400 Subject: [MINC-development] ABS and SIGN In-Reply-To: <20030617103630.D540520@shadow.bic.mni.mcgill.ca>; from alex@bic.mni.mcgill.ca on Tue, Jun 17, 2003 at 10:36:30AM -0400 References: <20030617103630.D540520@shadow.bic.mni.mcgill.ca> Message-ID: <20030617130738.J4635@gate.nmr.mgh.harvard.edu> Hi -- small complaint time... We are using the 1.1 libraries, and two rather common names are defined: ABS and SIGN. Annoyingly, though, some other libraries that we use also define those same strings, and in different ways. Any chance we could get them renamed to say MNIABS and MNISIGN, or something similarly likely to be unique? thanks, --vicka Vicka Rael Corey, Ph.D. vicka@nmr.mgh.harvard.edu "More fun than a barrel of monkey wrenches!" From minc-development@bic.mni.mcgill.ca Tue Jun 17 18:24:54 2003 From: minc-development@bic.mni.mcgill.ca (Robert VINCENT) Date: Tue, 17 Jun 2003 13:24:54 -0400 Subject: [MINC-development] ABS and SIGN In-Reply-To: <20030617130738.J4635@gate.nmr.mgh.harvard.edu> Message-ID: Hi Vicka, While I know there are some "namespace pollution" issues with MINC, I'm a little surprised that this is causing a problem, since none of these symbols is defined in the public "minc.h" header file. Perhaps some header file we include defines ABS or SIGN on platforms other than those we routinely use here. Can you give me more specifics on the error or warning you're seeing? Is it during the compilation of MINC, or during the compilation of some other project? Certainly we will try to make this less likely in the future by using more uniquely defined names. Thanks for the feedback, -bert On Tue, 17 Jun 2003, Vicka Corey wrote: > Hi -- small complaint time... > > We are using the 1.1 libraries, and two rather common names are defined: > ABS and SIGN. Annoyingly, though, some other libraries that we use also > define those same strings, and in different ways. > > Any chance we could get them renamed to say MNIABS and MNISIGN, or something > similarly likely to be unique? > > thanks, > --vicka > > Vicka Rael Corey, Ph.D. vicka@nmr.mgh.harvard.edu > "More fun than a barrel of monkey wrenches!" > _______________________________________________ > MINC-development mailing list > MINC-development@bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development > From minc-development@bic.mni.mcgill.ca Tue Jun 17 19:00:30 2003 From: minc-development@bic.mni.mcgill.ca (Steve ROBBINS) Date: Tue, 17 Jun 2003 14:00:30 -0400 Subject: [MINC-development] ABS and SIGN In-Reply-To: ; from bert@bic.mni.mcgill.ca on Tue, Jun 17, 2003 at 01:24:54PM -0400 References: <20030617130738.J4635@gate.nmr.mgh.harvard.edu> Message-ID: <20030617140030.A549267@shadow.bic.mni.mcgill.ca> On Tue, Jun 17, 2003 at 01:24:54PM -0400, Robert VINCENT wrote: > Hi Vicka, > > While I know there are some "namespace pollution" issues with MINC, I'm a > little surprised that this is causing a problem, since none of these > symbols is defined in the public "minc.h" header file. Maybe they are using volume_io: SIGN is defined in . That header is one of the worst offenders: it's got MIN, MAX, TRUE, FALSE, PI, ON, etc etc. But on the topic of ABS: why not just replace it with fabs() or abs() as appropriate and do away with the define. SIGN is actually only used in one file that I can detect: progs/mincview/invert_raw_image.c. And that file has its own definition of SIGN anyway. So it could be removed from volume_io/basic.h with no ill effects for MINC per se. How about we make "clean up the namespace" a release goal for MINC 1.2? What needs some thought is providing backward compatibility for clients of the library who do use these symbols. Mainly the decision is: do we make current users do something special to define the symbols, or do we make future users do something special to get a clean namespace? Where "something special" is either "#define a symbol" or "#include a different header". -S From minc-development@bic.mni.mcgill.ca Tue Jun 17 21:16:27 2003 From: minc-development@bic.mni.mcgill.ca (Robert VINCENT) Date: Tue, 17 Jun 2003 16:16:27 -0400 Subject: [MINC-development] ABS and SIGN In-Reply-To: <20030617140030.A549267@shadow.bic.mni.mcgill.ca> Message-ID: On Tue, 17 Jun 2003, Steve ROBBINS wrote: > > How about we make "clean up the namespace" a release goal for MINC 1.2? What > needs some thought is providing backward compatibility for clients of the > library who do use these symbols. Mainly the decision is: do we make current > users do something special to define the symbols, or do we make future users > do something special to get a clean namespace? Where "something special" is > either "#define a symbol" or "#include a different header". > Sounds like a plan! -bert From minc-development@bic.mni.mcgill.ca Wed Jun 18 00:35:01 2003 From: minc-development@bic.mni.mcgill.ca (Andrew Janke) Date: Wed, 18 Jun 2003 09:35:01 +1000 Subject: [MINC-development] ABS and SIGN In-Reply-To: <20030617140030.A549267@shadow.bic.mni.mcgill.ca> References: <20030617130738.J4635@gate.nmr.mgh.harvard.edu> <20030617140030.A549267@shadow.bic.mni.mcgill.ca> Message-ID: On Tue, 17 Jun 2003, Steve ROBBINS wrote: > On Tue, Jun 17, 2003 at 01:24:54PM -0400, Robert VINCENT wrote: > > Hi Vicka, > > > > While I know there are some "namespace pollution" issues with MINC, I'm a > > little surprised that this is causing a problem, since none of these > > symbols is defined in the public "minc.h" header file. > > Maybe they are using volume_io: SIGN is defined in . That > header is one of the worst offenders: it's got MIN, MAX, TRUE, FALSE, PI, ON, > etc etc. This has come up a number of times before, my biggest whinge MAX, MIN et al aside is that #defines exist for X, Y and Z! (in volume_io/geom_structs.h). This means that should you wish to include volume_io and some GSL routines you can't as some of the arguments to functions in GSL are things like matrix *X! > How about we make "clean up the namespace" a release goal for MINC 1.2? What > needs some thought is providing backward compatibility for clients of the > library who do use these symbols. Mainly the decision is: do we make current > users do something special to define the symbols, or do we make future users > do something special to get a clean namespace? Where "something special" is > either "#define a symbol" or "#include a different header". My suggestion is to break volume_io in the new version and make old programs include something such as old_volume_io.h that includes one extra file: volume_io/broken_defines.h this should only be a problem for Dave Mc's proggies. I have never (knowingly) used the 'naughty' #defines in volume_io but will probably be proved wrong here. ;) Then we should prefix all current volume_io #defines with something like VOLIO_ (GNU'ish style). This should all be fine unless the "other" volio brain library comes into play with it's own #defines... re: http://eivind.imm.dtu.dk/staff/kjems/volio/ -- Andrew Janke ( rotor@cmr.uq.edu.au || www.cmr.uq.edu.au/~rotor ) Australia->University of Queensland->Centre for Magnetic Resonance Work: +61 7 3365 4100 || Home: +61 7 3800 4042 From minc-development@bic.mni.mcgill.ca Wed Jun 18 02:41:45 2003 From: minc-development@bic.mni.mcgill.ca (Rick Hoge) Date: Tue, 17 Jun 2003 21:41:45 -0400 Subject: [MINC-development] Draft API for MINC 2.0 In-Reply-To: <20030616095524.A19276@sickkids.ca> Message-ID: <04F1FD7A-A12E-11D7-8ED8-000393B3ACC6@nmr.mgh.harvard.edu> >> Is there a gentler introduction that outlines the concepts and >> data types? For instance, what is a "group"? What is the "path" >> argument that many functions take? Is this api layered on top of >> hdf5? If so, is it necessary to understand it to read the new api >> document? > > The plan is to have a top level document explaining the concepts, but > it hasn't been written yet -- partly because some of the concepts are > still fluid. With respect to layering, the plan is as follows. > > HDF5 is the bottom level layer which the programmer never sees or > requires the documentation. The old libminc API is present with as > much > of its functionality retained as is consistent with the new libminc > API (i.e. almost all of it). The new libminc API is what our new Will it still make sense to call it Medical Image NetCDF (MINC) when it's based on HDF? ______________________________________ Richard D. Hoge, Ph.D. Instructor, HMS Department of Radiology A. A. Martinos Center for Biomedical Imaging 149 13th St. Charlestown MA 02129 phone 617-726-6598 fax 617-726-7422 ______________________________________ From minc-development@bic.mni.mcgill.ca Wed Jun 18 02:48:12 2003 From: minc-development@bic.mni.mcgill.ca (Leila Baghdadi) Date: Tue, 17 Jun 2003 21:48:12 -0400 (EDT) Subject: [MINC-development] Draft API for MINC 2.0 In-Reply-To: <04F1FD7A-A12E-11D7-8ED8-000393B3ACC6@nmr.mgh.harvard.edu> Message-ID: Hi Rick Perhaps you are right about the naming convention but we are trying very hard to keep everything backwards compatible with original minc1.0 so we thought it is best to call it minc still so people have no confusion about what happens to minc1.0 file format once minc2.0 is in use. thanks Leila On Tue, 17 Jun 2003, Rick Hoge wrote: > > >> Is there a gentler introduction that outlines the concepts and > >> data types? For instance, what is a "group"? What is the "path" > >> argument that many functions take? Is this api layered on top of > >> hdf5? If so, is it necessary to understand it to read the new api > >> document? > > > > The plan is to have a top level document explaining the concepts, but > > it hasn't been written yet -- partly because some of the concepts are > > still fluid. With respect to layering, the plan is as follows. > > > > HDF5 is the bottom level layer which the programmer never sees or > > requires the documentation. The old libminc API is present with as > > much > > of its functionality retained as is consistent with the new libminc > > API (i.e. almost all of it). The new libminc API is what our new > > Will it still make sense to call it Medical Image NetCDF (MINC) when > it's based on HDF? > > ______________________________________ > Richard D. Hoge, Ph.D. > Instructor, HMS Department of Radiology > A. A. Martinos Center for Biomedical Imaging > 149 13th St. > Charlestown MA 02129 > phone 617-726-6598 > fax 617-726-7422 > ______________________________________ > > _______________________________________________ > MINC-development mailing list > MINC-development@bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development > > From minc-development@bic.mni.mcgill.ca Wed Jun 18 02:55:38 2003 From: minc-development@bic.mni.mcgill.ca (Andrew Janke) Date: Wed, 18 Jun 2003 11:55:38 +1000 Subject: [MINC-development] Draft API for MINC 2.0 In-Reply-To: References: Message-ID: On Tue, 17 Jun 2003, Leila Baghdadi wrote: > Perhaps you are right about the naming convention but we are trying very > hard to keep everything backwards compatible with original minc1.0 so we > thought it is best to call it minc still so people have no confusion about > what happens to minc1.0 file format once minc2.0 is in use. Although as it happens, netCDF 4.0 will (apparently if all goes to plan) use HDF as it's data storage layer anyhow. :) re: http://www.unidata.ucar.edu/packages/netcdf/whatsnew.html -> http://www.unidata.ucar.edu/proposals/NASA-AIST-2002/abstract.html -- Andrew Janke ( rotor@cmr.uq.edu.au || www.cmr.uq.edu.au/~rotor ) Australia->University of Queensland->Centre for Magnetic Resonance W: +61 7 3365 4100 || H: +61 7 3800 4042 || M: +61 4 2138 8581 From minc-development@bic.mni.mcgill.ca Wed Jun 18 03:35:42 2003 From: minc-development@bic.mni.mcgill.ca (Rick Hoge) Date: Tue, 17 Jun 2003 22:35:42 -0400 Subject: [MINC-development] Draft API for MINC 2.0 In-Reply-To: Message-ID: <8E4A2358-A135-11D7-8ED8-000393B3ACC6@nmr.mgh.harvard.edu> On Tuesday, June 17, 2003, at 09:55 PM, Andrew Janke wrote: > On Tue, 17 Jun 2003, Leila Baghdadi wrote: > >> Perhaps you are right about the naming convention but we are trying >> very >> hard to keep everything backwards compatible with original minc1.0 so >> we >> thought it is best to call it minc still so people have no confusion >> about >> what happens to minc1.0 file format once minc2.0 is in use. > > Although as it happens, netCDF 4.0 will (apparently if all goes to > plan) use HDF > as it's data storage layer anyhow. :) > > re: http://www.unidata.ucar.edu/packages/netcdf/whatsnew.html > -> > http://www.unidata.ucar.edu/proposals/NASA-AIST-2002/abstract.html More than good enough for me - just wondering. It sounded like reverse compatibility would be maintained (I mean it would have to, wouldn't it?). Thanks for the links! > > > -- > Andrew Janke ( rotor@cmr.uq.edu.au || www.cmr.uq.edu.au/~rotor ) > Australia->University of Queensland->Centre for Magnetic Resonance > W: +61 7 3365 4100 || H: +61 7 3800 4042 || M: +61 4 2138 8581 > _______________________________________________ > MINC-development mailing list > MINC-development@bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development > ______________________________________ Richard D. Hoge, Ph.D. Instructor, HMS Department of Radiology A. A. Martinos Center for Biomedical Imaging 149 13th St. Charlestown MA 02129 phone 617-726-6598 fax 617-726-7422 ______________________________________ From minc-development@bic.mni.mcgill.ca Wed Jun 18 15:26:04 2003 From: minc-development@bic.mni.mcgill.ca (John G. Sled) Date: Wed, 18 Jun 2003 10:26:04 -0400 Subject: [MINC-development] Draft API for MINC 2.0 In-Reply-To: ; from rotor@cmr.uq.edu.au on Tue, Jun 17, 2003 at 09:07:33AM +1000 References: Message-ID: <20030618102552.A21813@sickkids.ca> On Tue, Jun 17, 2003 at 09:07:33AM +1000, Andrew Janke wrote: > On Mon, 16 Jun 2003, Robert VINCENT wrote: > > > > Are you really really sure you want to add more data types? (COMPLEX, etc) I > > > for one was happy with the idea of a 'vector_dimension/complex_vector' for these > > > as it allowed a fair bit more flexibility. > > > > My assumption was that adding some intrinsic support for complex data > > would be useful, and that we would ultimately allow arbitrarily-sized and > > -structured voxel values. So nothing would prevent you from continuing to > > use a vector type. Remember that 99% of the traditional MINC ways of > > accomplishing things should continue to work! > > True. However if I were to write a viewer for all types of MINC data, it just > got harder. Currently all I have to worry about are 3D and 4D scalar files, how > does one view a complex file? or a structured file? to my mind this sort of > notion introduces breakage further down the lines as each and every command line > tool will have to be more complex (pun :). > > But don't let my rambling stop you!, you just might find yourselves re-writing > mincresample, mincreshape, etc. ;) > Hi Andrew, What do you think of having a mechanism to make the complex or structured data appear to be flat? Perhaps this could be specified when the file is opened and the MINC file could appear to have an extra dimension. I think mincreshape should be relatively easy to modify to handle complex data and structured data, possibly with some type conversion restrictions. It is not clear what mincresample should do in general with structured data. John From minc-development@bic.mni.mcgill.ca Wed Jun 18 18:13:51 2003 From: minc-development@bic.mni.mcgill.ca (Vicka Corey) Date: Wed, 18 Jun 2003 13:13:51 -0400 Subject: [MINC-development] namespaces Message-ID: <20030618131307.C16815@gate.nmr.mgh.harvard.edu> Some details on our namespace issues: This happens on our compilation of executables using with other libraries. volume_io.h includes #include and basic.h is the one with the commonly used names. In specific the ones we've had trouble with include: #define PI M_PI /* from math.h */ #define ABS( x ) ( ((x) > 0) ? (x) : (-(x)) ) #define FABS( x ) fabs( (double) x ) #define SIGN( x ) ( ((x) > 0) ? 1 : (((x) < 0) ? -1 : 0) ) #define FSIGN( x ) ( ((x) > 0.0) ? 1.0 : (((x) < 0.0) ? -1.0 : 0.0) .. thanks, --vicka From minc-development@bic.mni.mcgill.ca Thu Jun 19 00:29:17 2003 From: minc-development@bic.mni.mcgill.ca (Andrew Janke) Date: Thu, 19 Jun 2003 09:29:17 +1000 Subject: [MINC-development] namespaces In-Reply-To: <20030618131307.C16815@gate.nmr.mgh.harvard.edu> References: <20030618131307.C16815@gate.nmr.mgh.harvard.edu> Message-ID: On Wed, 18 Jun 2003, Vicka Corey wrote: > In specific the ones we've had trouble with include: > > #define PI M_PI /* from math.h */ > #define ABS( x ) ( ((x) > 0) ? (x) : (-(x)) ) > #define FABS( x ) fabs( (double) x ) > #define SIGN( x ) ( ((x) > 0) ? 1 : (((x) < 0) ? -1 : 0) ) > #define FSIGN( x ) ( ((x) > 0.0) ? 1.0 : (((x) < 0.0) ? -1.0 : 0.0) .. So is the general consensus to change just the problem #defines or the lot? $ grep \#define /usr/local/mni/include/volume_io/* | wc -l 234 All 234 of them at that. I'm all for adding a VOLIO_ prefix to the start of all of them, then creating a volume_io_old.h with all the old #defines in it. This will of course cause some carnage in the ensuing few weeks... ;) -- Andrew Janke ( rotor@cmr.uq.edu.au || www.cmr.uq.edu.au/~rotor ) Australia->University of Queensland->Centre for Magnetic Resonance W: +61 7 3365 4100 || H: +61 7 3800 4042 || M: +61 4 2138 8581 From minc-development@bic.mni.mcgill.ca Thu Jun 19 00:38:12 2003 From: minc-development@bic.mni.mcgill.ca (Andrew Janke) Date: Thu, 19 Jun 2003 09:38:12 +1000 Subject: [MINC-development] Draft API for MINC 2.0 In-Reply-To: <20030618102552.A21813@sickkids.ca> References: <20030618102552.A21813@sickkids.ca> Message-ID: On Wed, 18 Jun 2003, John G. Sled wrote: > What do you think of having a mechanism to make the complex or structured data > appear to be flat? Perhaps this could be specified when the file is opened > and the MINC file could appear to have an extra dimension. 'tis a good idea, this will make writing of generic tools more straightforward and devoid of big case statements. Will it be the default? :) If this comes to fruition then I assume a reserved dimension name will be used? > It is not clear what mincresample should do in general with structured data. It's not clear what any of the current mincxxx tools should do in my mind, apart from mincdiff! :) Will mincmath be doing complex multiplication/division for complex data files? Let's define a matrix type in MINC! whooo! a PS: I currently achieve complex division/adittion with a few little minccalc scripts.... From minc-development@bic.mni.mcgill.ca Mon Jun 23 23:11:03 2003 From: minc-development@bic.mni.mcgill.ca (Steve ROBBINS) Date: Mon, 23 Jun 2003 18:11:03 -0400 Subject: [MINC-development] ABS and SIGN In-Reply-To: ; from rotor@cmr.uq.edu.au on Wed, Jun 18, 2003 at 09:35:01AM +1000 References: <20030618131307.C16815@gate.nmr.mgh.harvard.edu> <20030617130738.J4635@gate.nmr.mgh.harvard.edu> <20030617140030.A549267@shadow.bic.mni.mcgill.ca> Message-ID: <20030623181103.B780015@shadow.bic.mni.mcgill.ca> On Wed, Jun 18, 2003 at 09:35:01AM +1000, Andrew Janke wrote: > On Tue, 17 Jun 2003, Steve ROBBINS wrote: > > How about we make "clean up the namespace" a release goal for MINC 1.2? What > > needs some thought is providing backward compatibility for clients of the > > library who do use these symbols. Mainly the decision is: do we make current > > users do something special to define the symbols, or do we make future users > > do something special to get a clean namespace? Where "something special" is > > either "#define a symbol" or "#include a different header". > > My suggestion is to break volume_io in the new version and make old programs > include something such as old_volume_io.h that includes one extra file: > volume_io/broken_defines.h I'm going to cast a vote for the more conservative option: Leave existing headers as-is, and create a new, cleaner header. Or, alternatively, new code that wants a cleaner namespace should #define MINC_USE_NAMESPACE (or similar), before including any MINC or volume_io header. > this should only be a problem for Dave Mc's proggies. > I have never (knowingly) used the 'naughty' #defines in volume_io but will > probably be proved wrong here. ;) The problem is: several of these (including ABS, MIN, and MAX) are listed in the volume_io documentation. Abruptly changing the published API (abhorrent though it may be) in a point release is probably *not* going to inspire confidence in the maintainance process of MINC... Perhaps we could introduce a symbol to clean up the namespace (e.g. the MINC_USE_NAMESPACE symbol suggested above) and document the old stuff as "deprecated". Also: encourage client programmers to move away from interfaces documented as deprecated. In a future release (2.0 for sure), the deprecated stuff can be moved to the special compatibility header as you suggest, or removed entirely. Mainly, we should give people time to adjust their code. > Then we should prefix all current volume_io #defines with something like > VOLIO_ (GNU'ish style). This should all be fine unless the "other" volio brain > library comes into play with it's own #defines... > > re: http://eivind.imm.dtu.dk/staff/kjems/volio/ That's a good reason to stay away from such a generic name. Perhaps we could use "MNI_VOLIO_" as the prefix. We have a more legitimate claim on "MNI" than on "VOLIO" as the top level of the hierarchy. On Thu, Jun 19, 2003 at 09:29:17AM +1000, Andrew Janke wrote: > On Wed, 18 Jun 2003, Vicka Corey wrote: > > > In specific the ones we've had trouble with include: > > > > #define PI M_PI /* from math.h */ > > #define ABS( x ) ( ((x) > 0) ? (x) : (-(x)) ) > > #define FABS( x ) fabs( (double) x ) > > #define SIGN( x ) ( ((x) > 0) ? 1 : (((x) < 0) ? -1 : 0) ) > > #define FSIGN( x ) ( ((x) > 0.0) ? 1.0 : (((x) < 0.0) ? -1.0 : 0.0) .. > > So is the general consensus to change just the problem #defines or the lot? > > $ grep \#define /usr/local/mni/include/volume_io/* | wc -l > 234 > > All 234 of them at that. I imagine that there should be no global symbols without a "MNI_VOLIO_" prefix. I suspect that some of those 234 symbols can simply be replaced: FABS --> fabs() for example. I think it is worth going through them on a case-by-case basis. Some might be able to be removed to the volume_io source files or to a header that is not installed. -Steve From minc-development@bic.mni.mcgill.ca Tue Jun 24 02:31:59 2003 From: minc-development@bic.mni.mcgill.ca (Andrew Janke) Date: Tue, 24 Jun 2003 11:31:59 +1000 Subject: [MINC-development] ABS and SIGN In-Reply-To: <20030623181103.B780015@shadow.bic.mni.mcgill.ca> References: <20030618131307.C16815@gate.nmr.mgh.harvard.edu> <20030617130738.J4635@gate.nmr.mgh.harvard.edu> <20030617140030.A549267@shadow.bic.mni.mcgill.ca> <20030623181103.B780015@shadow.bic.mni.mcgill.ca> Message-ID: On Mon, 23 Jun 2003, Steve ROBBINS wrote: > I'm going to cast a vote for the more conservative option: Leave existing > headers as-is, and create a new, cleaner header. Or, alternatively, new > code that wants a cleaner namespace should #define MINC_USE_NAMESPACE > (or similar), before including any MINC or volume_io header. > > Perhaps we could introduce a symbol to clean up the namespace (e.g. the > MINC_USE_NAMESPACE symbol suggested above) and document the old > stuff as "deprecated". Also: encourage client programmers to move > away from interfaces documented as deprecated. Aka the GTK 1.2 => 2.0 approach. ie: we could just wait untill 2.0 ;) And thus save us the trouble of re-writing code again for 2.0. a From minc-development@bic.mni.mcgill.ca Tue Jun 24 02:50:43 2003 From: minc-development@bic.mni.mcgill.ca (Andrew Janke) Date: Tue, 24 Jun 2003 11:50:43 +1000 Subject: [MINC-development] MINC 2.0 -- ParseArgv Message-ID: Are there plans to include ParseArgv in the "new" MINC? Reason I ask is that if anyone is feeling energetic I wouldn't mind range checking being included.. ie: a line in an arg table that used to look like this: {"-arb_path_coord_buffer", ARGV_INT, (char *)1, (char *)&ap_buff_size, "Size of arbitrary path co-ordinate buffer"}, would now look like this: {"-arb_path_coord_buffer", ARGV_INT, (char *)1, 0, 50000, (char *)&ap_buff_size, "Size of arbitrary path co-ordinate buffer"}, And would check that the input int is between 0 and 50000. obviously NULL could be used to signify that no checking is required. a From minc-development@bic.mni.mcgill.ca Wed Jun 25 16:28:52 2003 From: minc-development@bic.mni.mcgill.ca (Leila Baghdadi) Date: Wed, 25 Jun 2003 11:28:52 -0400 (EDT) Subject: [MINC-development] MINC 2.0 -- ParseArgv In-Reply-To: Message-ID: Hey Andrew I am not sure if we did discuss this while creating the first draft of the API but now that I think of it, I think it is a very good suggestion. I have included this in my list of _to_figure_out and will bring it up in our next meeting to see what everyone thinks. Thanks Leila On Tue, 24 Jun 2003, Andrew Janke wrote: > > Are there plans to include ParseArgv in the "new" MINC? Reason I ask is that if > anyone is feeling energetic I wouldn't mind range checking being included.. > > ie: a line in an arg table that used to look like this: > > {"-arb_path_coord_buffer", ARGV_INT, (char *)1, (char *)&ap_buff_size, > "Size of arbitrary path co-ordinate buffer"}, > > would now look like this: > > {"-arb_path_coord_buffer", ARGV_INT, (char *)1, 0, 50000, > (char *)&ap_buff_size, "Size of arbitrary path co-ordinate buffer"}, > > And would check that the input int is between 0 and 50000. obviously NULL could > be used to signify that no checking is required. > > > a > _______________________________________________ > MINC-development mailing list > MINC-development@bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development > > From minc-development@bic.mni.mcgill.ca Wed Jun 25 17:17:27 2003 From: minc-development@bic.mni.mcgill.ca (Jason Lerch) Date: 25 Jun 2003 12:17:27 -0400 Subject: [MINC-development] Draft API for MINC 2.0 In-Reply-To: <20030613164231.E9376@sickkids.ca> References: <20030613164231.E9376@sickkids.ca> Message-ID: <1056557846.13014.15.camel@dennis.bic.mni.mcgill.ca> Hello all, so after finally having had a chance to read that draft a few questions come to mind: * voxel loop - where did it go? I think Andrew already asked that question, but I have seen no answer as of yet. * voxel and world dimensions: all of the hypercube functions assume voxel dimensions - is there going to be an easy way to either call those functions with world dimensions, or some function to pass in world dimensions and get the corresponding voxel dims back? (This might already exist and I could have just missed it ... Cheers, Jason On Fri, 2003-06-13 at 16:42, John G. Sled wrote: > MINC developers, > > Bert, Leila, and I have put together a draft description of the API > for MINC 2.0. It can be assessed on the web at > > http://www.bic.mni.mcgill.ca/users/jgsled/outgoing/minc2.0/ > > Please read it over a let us know what you think. If you find any > loose ends please pull on them. We want the final API to > comprehensive, self-consistent, general, easy to understand, easy to > use and well documented. Post any suggestions, patches, new ideas, > old and overlooked ideas, additional functions and corrections back to > the list for discussion. > > cheers, > > John > > > _______________________________________________ > MINC-development mailing list > MINC-development@bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development From minc-development@bic.mni.mcgill.ca Thu Jun 26 16:24:21 2003 From: minc-development@bic.mni.mcgill.ca (Robert VINCENT) Date: Thu, 26 Jun 2003 11:24:21 -0400 Subject: [MINC-development] MINC 2.0 -- ParseArgv In-Reply-To: Message-ID: Andrew, The "new" MINC will continue to include the "old" libminc, which will be supported indefinitely. We probably should've been clearer about that. So ParseArgv isn't going anywhere. As to your suggested extension, I'm all for it, but I'd like to keep it backward-compatible if possible, and to make it work with one or more floating point or integer arguments: {"-arb_path_coord_buffer", ARGV_INT, (char *)1, (char *)&ap_buff_size, "Size of arbitrary path co-ordinate buffer"}, would become this: {"-arb_path_coord_buffer", ARGV_INT_RNGCHK, (char *)&rng_buf, (char *)&ap_buff_size, "Size of arbitrary path co-ordinate buffer"}, Where rng_buf is defined as: struct ArgvRangeInfo { int nargs; struct { double min; double max; } ranges[MI_MAX_RANGE_ARGS]; } rng_buf = { 1, { 0.0, 50000.0 } }; MI_MAX_RANGE_ARGS would be some large number (100 or so?), so that the structure doesn't have to be dynamically defined. If you don't like an arbitrary upper limit on the number of arguments that can be range-checked, we could probably come up with something more dynamic but more complicated. If min == max, no range checking would be performed on the corresponding argument. Any reaction? Is this overkill? -bert On Tue, 24 Jun 2003, Andrew Janke wrote: > > Are there plans to include ParseArgv in the "new" MINC? Reason I ask is that if > anyone is feeling energetic I wouldn't mind range checking being included.. > > ie: a line in an arg table that used to look like this: > > {"-arb_path_coord_buffer", ARGV_INT, (char *)1, (char *)&ap_buff_size, > "Size of arbitrary path co-ordinate buffer"}, > > would now look like this: > > {"-arb_path_coord_buffer", ARGV_INT, (char *)1, 0, 50000, > (char *)&ap_buff_size, "Size of arbitrary path co-ordinate buffer"}, > > And would check that the input int is between 0 and 50000. obviously NULL could > be used to signify that no checking is required. > > > a > _______________________________________________ > MINC-development mailing list > MINC-development@bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development > From minc-development@bic.mni.mcgill.ca Fri Jun 27 07:26:42 2003 From: minc-development@bic.mni.mcgill.ca (Andrew Janke) Date: Fri, 27 Jun 2003 16:26:42 +1000 Subject: [MINC-development] MINC 2.0 -- ParseArgv In-Reply-To: References: Message-ID: On Thu, 26 Jun 2003, Robert VINCENT wrote: > As to your suggested extension, I'm all for it, but I'd like to keep it > backward-compatible if possible, and to make it work with one or > more floating point or integer arguments: > > {"-arb_path_coord_buffer", ARGV_INT_RNGCHK, (char *)&rng_buf, > (char *)&ap_buff_size, "Size of arbitrary path co-ordinate buffer"}, > > struct ArgvRangeInfo { > int nargs; > struct { > double min; > double max; > } ranges[MI_MAX_RANGE_ARGS]; > } rng_buf = { > 1, > { 0.0, 50000.0 } > }; Looks good to me. This would at least keep code that initialises arguments somewhat tidy. If i can grok the above correctly it'll look something like this: int verbose; int clobber; ... int ap_buff_size = 2048; ArgvRangeInfo ap_buff_size_buf = {1, {0.0, 50000.0}}; float foovar[3] = {6.672e-23, 6.022045e23, 6.626176e-34}; ArgvRangeInfo foovar_buf = {3, {0, 10}, {0, lots}, {0, 0} /* no bounds for h(Js) */ } ... /* arg table */ ... yes? > MI_MAX_RANGE_ARGS would be some large number (100 or so?), so that the > structure doesn't have to be dynamically defined. If you don't like an > arbitrary upper limit on the number of arguments that can be > range-checked, we could probably come up with something more dynamic but > more complicated. I'm happy with a arbitrary limit. beyond 100 or so args you should no doubt be considering and input config file. > If min == max, no range checking would be performed on the corresponding > argument. This works too. > Any reaction? Is this overkill? I initally thought so, but after a day or so think it is the right approach to such a matter. a From minc-development@bic.mni.mcgill.ca Mon Jun 30 09:15:59 2003 From: minc-development@bic.mni.mcgill.ca (Andrew Janke) Date: Mon, 30 Jun 2003 18:15:59 +1000 Subject: [MINC-development] minccmp In-Reply-To: <20030617103630.D540520@shadow.bic.mni.mcgill.ca> References: <20030617103630.D540520@shadow.bic.mni.mcgill.ca> Message-ID: On Tue, 17 Jun 2003, Alex ZIJDENBOS wrote: > voldiff mainly produces the kappa statistic, as well as confusion > matrix, sensitivity, specificity, etc. See attached for sample > output. Vasco describes most of these in his thesis, see > > http://www.bic.mni.mcgill.ca/~alex/docs/vasco_thesis.pdf > > As for AZSM (I'll let you figure out the acronym assigned by Vasco :), > that comes from my theseis work. You can find that, and my Dec 94 TMI > paper which summarizes it, in the same place (dissertation.pdf, > zijdenbos_tmi_dec_1994.pdf). Ta for the two links, they appear to contain all that I need. The current version (without kappa stuff) of minccmp is in: /s/s/minc_dev/minccmp So far I have only included various grey-level comparison operators. I am a little unsure as to how to progress with the kappa stuff as it requires a binary input. My current thoughts are to simply assume if a -kappa type test is requested then to assume that the input is indeed binary. And thus fail is there are more than say 100 classes (by default). thoughts? a