From minc-development@bic.mni.mcgill.ca Fri Aug 1 21:04:26 2003 From: minc-development@bic.mni.mcgill.ca (John G. Sled) Date: Fri, 1 Aug 2003 16:04:26 -0400 Subject: [MINC-development] New version of API document for MINC 2.0 Message-ID: <20030801160426.C2882@sickkids.ca> Hello everyone, A new version of the API documentation is available for MINC 2.0 at this location http://www.bic.mni.mcgill.ca/software/minc2/api_doc-2003-07-25/index.html The new document fills most all the gaps in the previous document and addresses some the feedback that has appeared on the list. We haven't yet written a top level document outlining the various concepts and abstractions, but that is in the works. Some of the things that are new and updated in this version: handling of structure datatypes setting an apparent dimension order volume creation -- blocking and compression hypercube reading and writing Please send your comments to the list. I will be away this month, but Bert and Leila are keen to start coding and would appreciate any help in tying up loose ends and identifying inconsistencies. cheers, John From minc-development@bic.mni.mcgill.ca Mon Aug 4 07:07:10 2003 From: minc-development@bic.mni.mcgill.ca (Andrew Janke) Date: Mon, 4 Aug 2003 16:07:10 +1000 Subject: [MINC-development] New version of API document for MINC 2.0 In-Reply-To: <20030801160426.C2882@sickkids.ca> References: <20030801160426.C2882@sickkids.ca> Message-ID: On Fri, 1 Aug 2003, John G. Sled wrote: > http://www.bic.mni.mcgill.ca/software/minc2/api_doc-2003-07-25/index.html > > Some of the things that are new and updated in this version: > handling of structure datatypes > setting an apparent dimension order > volume creation -- blocking and compression > hypercube reading and writing It's looking more and more complete! :) Any word on inclusion of the "other" MINC types? * xfms (lin and non-linear and all their siblings) * tag files. Also whilst on inclusions, is this the release voxel_loop and other 'mighty usefull' functions will be included/incorporated into? (such as timestamp and the likes?) -- 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 Tue Aug 5 22:20:29 2003 From: minc-development@bic.mni.mcgill.ca (Yasunari Tosa) Date: 05 Aug 2003 17:20:29 -0400 Subject: [MINC-development] accuracy in mritotal. better tool? Message-ID: <1060118429.2122.76.camel@tosa-nb.nmr.mgh.harvard.edu> --=-MTMNSz2vzKXae07QG71B Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi, MINC people: I'm not getting the accuracy in mritotal results. I would appreciate it very much for your help in resolving the accuracy. mritotal -verbose -debug -clobber -protocol icbm orig.mnc talairach.xfm My test was to modify the world translation by a fixed amount and see how the result changes (therefore the image never changes). What I was surprized was the following: Even though the rotation and the scaling parts are quite stable, the translation part error is quite large (up to 1.48 mm). The original volume is 256^3 with 1 mm voxel. The last two column is the difference and the error from the original in translation The fourth column is the translation part. Original : world_translation is (0,0,0): ============================= 1.10129165649414 0.0375710912048817 -0.0232741367071867 0.884597778320312 -0.0363568961620331 1.05287253856659 -0.020708842203021 -6.91514205932617 0.0234725382179022 0.0233993344008923 1.14845287799835 8.22117519378662 world_translation is (10, 0, 0) ======================= diff error 1.10129165649414 0.0375710912048817 -0.0232741367071867 -10.1283187866211 11.0129165649414 10 1.01291656494141 -0.0363568961620331 1.05287253856659 -0.020708842203021 -6.55157375335693 -0.36356830596924 0 -0.36356830596924 0.0234725382179022 0.0233993344008923 1.14845287799835 7.98645114898682 0.234724044799799 0 0.234724044799799 world_translation is (0,10,0) ====================== diff error 1.10129177570343 0.0375712215900421 -0.0232741497457027 0.508886873722076 0.375710904598236 0 0.375710904598236 -0.0363569855690002 1.05287170410156 -0.0207088124006987 -17.4438610076904 10.5287189483642 10 0.528718948364231 0.0234725456684828 0.0233993232250214 1.14845287799835 7.98718357086182 0.233991622924799 0 0.233991622924799 world_translation is (0, 0, 10) ======================= diff error 1.10129165649414 0.0375710912048817 -0.0232741367071867 1.11733937263489 -0.232741594314578 0 -0.232741594314578 -0.0363568961620331 1.05287253856659 -0.020708842203021 -6.70805358886719 -0.20708847045898 0 -0.20708847045898 0.0234725382179022 0.0233993344008923 1.14845287799835 -3.26335191726685 11.4845271110535 10 1.48452711105347 -- Yasunari Tosa, Ph.D. R&D Enginner email: tosa@nmr.mgh.harvard.edu Mass. General Hospital NMR Center phone: Building 149-2301 13th Street fax : Charlestown, MA 02129 --=-MTMNSz2vzKXae07QG71B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Hi, MINC people:

I'm not getting the accuracy in mritotal results. 
I would appreciate it very much for your help in resolving the accuracy.

mritotal -verbose -debug -clobber -protocol icbm orig.mnc talairach.xfm

My test was to modify the world translation by a fixed amount and see how the result changes
(therefore the image never changes).

What I was surprized was the following:

Even though the rotation and the scaling parts are quite stable, the translation part error
is quite large (up to 1.48 mm).  

The original volume is 256^3 with 1 mm voxel.

The last two column is the difference and the error from the original in translation
The fourth column is the translation part.

Original : world_translation is (0,0,0):
=============================
1.10129165649414 0.0375710912048817 -0.0232741367071867 0.884597778320312
-0.0363568961620331 1.05287253856659 -0.020708842203021 -6.91514205932617
0.0234725382179022 0.0233993344008923 1.14845287799835 8.22117519378662

world_translation is (10, 0, 0)
=======================                                                    diff                   error
1.10129165649414 0.0375710912048817 -0.0232741367071867 -10.1283187866211 11.0129165649414 10 1.01291656494141
-0.0363568961620331 1.05287253856659 -0.020708842203021 -6.55157375335693 -0.36356830596924 0 -0.36356830596924
0.0234725382179022 0.0233993344008923 1.14845287799835 7.98645114898682 0.234724044799799 0 0.234724044799799

world_translation is (0,10,0)
======================                                                    diff                     error              
1.10129177570343 0.0375712215900421 -0.0232741497457027 0.508886873722076 0.375710904598236 0 0.375710904598236
-0.0363569855690002 1.05287170410156 -0.0207088124006987 -17.4438610076904 10.5287189483642 10 0.528718948364231
0.0234725456684828 0.0233993232250214 1.14845287799835 7.98718357086182 0.233991622924799 0 0.233991622924799

world_translation is (0, 0, 10)
=======================                                                   diff                   error
1.10129165649414 0.0375710912048817 -0.0232741367071867 1.11733937263489 -0.232741594314578 0 -0.232741594314578
-0.0363568961620331 1.05287253856659 -0.020708842203021 -6.70805358886719 -0.20708847045898 0 -0.20708847045898
0.0234725382179022 0.0233993344008923 1.14845287799835 -3.26335191726685 11.4845271110535 10 1.48452711105347

-- 
Yasunari Tosa, Ph.D.
R&D Enginner				email: tosa@nmr.mgh.harvard.edu
Mass. General Hospital NMR Center	phone:  		
Building 149-2301
13th Street			        fax  :
Charlestown, MA 02129
--=-MTMNSz2vzKXae07QG71B-- From minc-development@bic.mni.mcgill.ca Wed Aug 6 02:06:58 2003 From: minc-development@bic.mni.mcgill.ca (Peter NEELIN) Date: Tue, 5 Aug 2003 21:06:58 -0400 Subject: [MINC-development] accuracy in mritotal. better tool? In-Reply-To: <1060118429.2122.76.camel@tosa-nb.nmr.mgh.harvard.edu> Message-ID: On 5 Aug 2003, Yasunari Tosa wrote: > Even though the rotation and the scaling parts are quite stable, the > translation part error > is quite large (up to 1.48 mm). I'm not quite clear on how you are computing your differences, but you do need to be careful when comparing transformation matrices. If you simply take the difference of the translation part of the matrix, you can get large errors if the centre of the volume is displaced a long way from the origin (0,0,0), since the rotation is generally being done around the centre of the brain (roughly). Taking the translation part of the matrix gives a rotation around the origin, so the translation part can include a large component arising from rotational and scaling error, even though the error in the region of the brain is fairly small. Generally, you need to know where the brain lies in the coordinate system. At the very least, you need to know what the centre of the brain is. One way to estimate this is to simply load the volume into register and read off the initial coordinate. Another way is to find the dimension sizes with mincinfo and then use voxeltoworld. If, for example, you have a volume with 128 slices that are 256x256, then use voxeltoworld file.mnc 64 128 128 to get the centre of the volume. (A better approach would be to use something like mincstats to estimate the centroid.) Then use xfm2param: xfm2param file.xfm -center Use the same centre for both xfm files and you should be able to compare the translations. (I notice that xfm2param takes a minc file argument - Louis, does that estimate the centre of gravity or somesuch?) Anyway, as I said, I am not clear how you are estimating error, so perhaps you have taken this into account already, or your volumes are already centred about the origin. If so, then we'll see if Louis (Collins) has any suggestions as to why the results may be varying. Peter ---- Peter Neelin (neelin@bic.mni.mcgill.ca) From minc-development@bic.mni.mcgill.ca Tue Aug 12 14:43:40 2003 From: minc-development@bic.mni.mcgill.ca (Jacqueline Chen) Date: Tue, 12 Aug 2003 09:43:40 -0400 (EDT) Subject: [MINC-development] volume_stats/mincstats??? Message-ID: Hello! Peter Neelin suggested that I email my problem here...hope you can help! My data is here: /home/bic/chen/mincstats_dir the commands I used were: volume_stats lipst10_MT_to_e2.mnc.gz and mincstats lipst10_MT_to_e2.mnc.gz I have found a bug...specifically with the calculation of the median. Peter's message: "Send your message, along with the location of the file and the command-line to minc-development@bic.mni.mcgill.ca. Either Steve or Andrew should fix this. You can tell them that I said that the median calculation looks like it is not adding the histogram offset (centre of the zeroth bin). Someone should check all of the results when using a volume that has a significantly non-zero minimum (I suspect that Andrew, who wrote the code, did not use such a volume for testing)." here are my outputs: ===================== volume_stats output File: lipst10_MT_to_e2.mnc.gz # voxels: 2949120 % of total: 100 Volume (mm3): 8.84736e+06 Min: -114.595 Max: 85.3346 Sum: 1.57703e+07 Sum2: 4.93394e+08 Mean: 5.34745 Variance: 138.707 Stddev: 11.7774 ***************Median: -0.00774425****************** Majority: -0.00774425 BiModalT: 15.2738 PctT (-1.79769e+308): -114.619 85.359 Entropy: 3.13281 CoM_voxel: zspace:27.4898 yspace:135.843 xspace:96.4351 CoM_world: zspace:-29.6355 yspace:12.7787 xspace:1.77514 ============= mincstats output File: lipst10_MT_to_e2.mnc.gz Mask file: (null) Total voxels: 2949120 # voxels: 2949120 % of total: 100 Volume (mm3): 8847360 Min: -114.5949692 Max: 85.33459454 Sum: 15783756.65 Sum^2: 493391934.2 Mean: 5.35202252 Variance: 138.6573119 Stddev: 11.77528394 CoM_voxel(z,y,x): 27.49728313 135.8338074 96.43413711 CoM_real(x,y,z): 1.777973285 12.78375223 -29.61186191 Histogram: (null) Total voxels: 2949120 # voxels: 2949119 % of total: 99.99996609 ****************Median: 114.4969327*********** Majority: 0.01465323195 BiModalT: 84.88475037 PctT [ 0%]: 0 Entropy : 2.815999481 ============================ many thanks, Jacqueline From minc-development@bic.mni.mcgill.ca Tue Aug 12 19:11:31 2003 From: minc-development@bic.mni.mcgill.ca (Robert VINCENT) Date: Tue, 12 Aug 2003 14:11:31 -0400 Subject: [MINC-development] volume_stats/mincstats??? In-Reply-To: Message-ID: Hi, I've taken a look at this. If I follow Peter's comments and the program's logic, it looks as though the following line needs to be added to mincstats.c: Index: mincstats.c =================================================================== RCS file: /software/source/minc/cvsroot/minc/progs/mincstats/mincstats.c,v retrieving revision 1.11 diff -c -r1.11 mincstats.c *** mincstats.c 5 Sep 2002 00:41:57 -0000 1.11 --- mincstats.c 12 Aug 2003 18:09:54 -0000 *************** *** 618,623 **** --- 618,624 ---- else stats->median = ((double)median_bin + (0.5 - cdf[median_bin]) * pdf[median_bin + 1]) * hist_sep; + stats->median += hist_centre[0]; stats->majority = hist_centre[majority_bin]; stats->biModalT = hist_centre[bimodalt_bin]; Does this look correct? -bert On Tue, 12 Aug 2003, Jacqueline Chen wrote: > > Hello! > > Peter Neelin suggested that I email my problem here...hope you can help! > > My data is here: > > /home/bic/chen/mincstats_dir > > the commands I used were: > > volume_stats lipst10_MT_to_e2.mnc.gz > and > mincstats lipst10_MT_to_e2.mnc.gz > > I have found a bug...specifically with the calculation of the median. > > Peter's message: > > "Send your message, along with the location of the file and the > command-line to minc-development@bic.mni.mcgill.ca. Either Steve or Andrew > should fix this. You can tell them that I said that the median calculation > looks like it is not adding the histogram offset (centre of the zeroth > bin). Someone should check all of the results when using a volume that has > a significantly non-zero minimum (I suspect that Andrew, who wrote the > code, did not use such a volume for testing)." > > here are my outputs: > > ===================== > volume_stats output > > File: lipst10_MT_to_e2.mnc.gz > # voxels: 2949120 > % of total: 100 > Volume (mm3): 8.84736e+06 > Min: -114.595 > Max: 85.3346 > Sum: 1.57703e+07 > Sum2: 4.93394e+08 > Mean: 5.34745 > Variance: 138.707 > Stddev: 11.7774 > ***************Median: -0.00774425****************** > Majority: -0.00774425 > BiModalT: 15.2738 > PctT (-1.79769e+308): -114.619 85.359 > Entropy: 3.13281 > CoM_voxel: zspace:27.4898 yspace:135.843 xspace:96.4351 > CoM_world: zspace:-29.6355 yspace:12.7787 xspace:1.77514 > > ============= > mincstats output > > File: lipst10_MT_to_e2.mnc.gz > Mask file: (null) > Total voxels: 2949120 > # voxels: 2949120 > % of total: 100 > Volume (mm3): 8847360 > Min: -114.5949692 > Max: 85.33459454 > Sum: 15783756.65 > Sum^2: 493391934.2 > Mean: 5.35202252 > Variance: 138.6573119 > Stddev: 11.77528394 > CoM_voxel(z,y,x): 27.49728313 135.8338074 96.43413711 > CoM_real(x,y,z): 1.777973285 12.78375223 -29.61186191 > > Histogram: (null) > Total voxels: 2949120 > # voxels: 2949119 > % of total: 99.99996609 > ****************Median: 114.4969327*********** > Majority: 0.01465323195 > BiModalT: 84.88475037 > PctT [ 0%]: 0 > Entropy : 2.815999481 > > ============================ > > many thanks, > Jacqueline > > _______________________________________________ > 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 Aug 13 04:46:52 2003 From: minc-development@bic.mni.mcgill.ca (Andrew Janke) Date: Wed, 13 Aug 2003 13:46:52 +1000 Subject: [MINC-development] MINC musings. Message-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---2107239605-578346705-1060746412=:2664541 Content-Type: TEXT/PLAIN; charset=US-ASCII Whilst in the process of fixing the mincstats bug (patch to follow shortly) I noted that my CVS repo if MINC was waaay out of date and updated. I note the build process has been revamped again (Master Robbins no doubt :), for a while now building minc has required automake/autoconf et al and subsequently perl. Now correct me if I am wrong, but one of peter's inital musings as to why certain extras should never make it into the base minc distro was because they required perl! :) (enter stage right mincpik and minchistory) So I'll take it this restriction is now a thing of the past! that being the case what are the conditions that are going to be needed to be met to 'allow' a new addittion to the base MINC stable? Previously this sort of fell upon peter, him being the MINC grand-poo-bar and all that. A vote? anarchy? And while I'm on my soapbox, 3 other minor things: * Can someone (stever?) please remove the extra cvsroot directory! I know it causes no problems apart from RSI and Carpal Tunnel. * Can we remove mincexample{1,2} from the base install/build or shove them in a separate ./dev/ directory? Considering the executables appear to be now built in ./ * I'm the first to admit I don't indent (code) as others do. I'm also the first to admit that the indenting in both minccalc and mincstats is pretty ugly. So is it possible that we can define a default indenting style for all MINC code before it is submitted? I have attached my own .indent.pro file that I attempt to use for most of my other CVS code /s/s/minc_dev but sadly I didn't use indent on the mincstats, minccalc as I just mailed the initial hacks to peter and he included them. (although apparently jason does the same as I do with closing braces) (The other perl attachemnt - myindent - is what I use to make closing braces behave as I like, I am only suggesting we adopt something like .indent.pro, not myindent!) -- 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 ---2107239605-578346705-1060746412=:2664541 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=".indent.pro" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=".indent.pro" Ly8gLmluZGVudC5wcm8NCi8vIA0KLy8gQW5kcmV3IEphbmtlIC0gcm90b3JA Y21yLnVxLmVkdS5hdQ0KLy8gDQovLw0KDQovKiBnZW5lcmFsIHN0dWZmICov DQotLWxpbmUtbGVuZ3RoOTAgICAgICAgICAgICAgICAgICAgICAgICAgICAv LyAtbDkwDQotLWNvbW1lbnQtaW5kZW50YXRpb240MCAgICAgICAgICAgICAg ICAgICAvLyAtYzQwDQotLWRlY2xhcmF0aW9uLWNvbW1lbnQtY29sdW1uNDAg ICAgICAgICAgICAvLyAtY2Q0MA0KLS1kZWNsYXJhdGlvbi1pbmRlbnRhdGlv bjkgICAgICAgICAgICAgICAgLy8gLWRpOQ0KLS1kb250LWJyZWFrLXByb2Nl ZHVyZS10eXBlICAgICAgICAgICAgICAgLy8gLW5wc2wNCi0tY29udGludWUt YXQtcGFyZW50aGVzZXMgICAgICAgICAgICAgICAgIC8vIC1scA0KLS1ob25v dXItbmV3bGluZXMgICAgICAgICAgICAgICAgICAgICAgICAgLy8gLWhubA0K DQovKiBpbmRlbnQvdGFiIHNpemUgKi8NCi0tdGFiLXNpemUzICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIC8vIC10cyR0YWJzaXplDQotLWluZGVu dC1sZXZlbDMgICAgICAgICAgICAgICAgICAgICAgICAgICAvLyAtaSR0YWJz aXplDQotLW5vLXRhYnMgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAvLyAtbnV0DQoNCi8qIGJyYWNlcyAqLw0KLS1icmFjZXMtb24taWYtbGlu ZSAgICAgICAgICAgICAgICAgICAgICAgLy8gLWJyDQotLWJyYWNlcy1vbi1z dHJ1Y3QtZGVjbC1saW5lICAgICAgICAgICAgICAvLyAtYnJzDQoNCi8qIHdo aXRlc3BhY2UgKi8NCi0tbm8tc3BhY2UtYWZ0ZXItY2FzdHMgICAgICAgICAg ICAgICAgICAgIC8vIC1uY3MNCi0tbm8tc3BhY2UtYWZ0ZXItZm9yICAgICAg ICAgICAgICAgICAgICAgIC8vIC1uc2FmDQotLW5vLXNwYWNlLWFmdGVyLWZ1 bmN0aW9uLWNhbGwtbmFtZXMgICAgICAvLyAtbnBjcw0KLS1uby1zcGFjZS1h ZnRlci1pZiAgICAgICAgICAgICAgICAgICAgICAgLy8gLW5zYWkNCi0tbm8t c3BhY2UtYWZ0ZXItcGFyZW50aGVzZXMgICAgICAgICAgICAgIC8vIC1ucHJz DQotLW5vLXNwYWNlLWFmdGVyLXdoaWxlICAgICAgICAgICAgICAgICAgICAv LyAtbnNhdw0KLS1kb250LWN1ZGRsZS1kby13aGlsZSAgICAgICAgICAgICAg ICAgICAgLy8gLW5jZHcNCi0tZG9udC1jdWRkbGUtZWxzZSAgICAgICAgICAg ICAgICAgICAgICAgIC8vIC1uY2UNCi0tbm8tc3BhY2UtYWZ0ZXItY2FzdHMg ICAgICAgICAgICAgICAgICAgIC8vIC1uY3MNCg0KLyogYmxhbmsgbGluZXMg Ki8NCi0tYmxhbmstbGluZXMtYWZ0ZXItZGVjbGFyYXRpb25zICAgICAgICAg IC8vIC1iYWQNCi0tYmxhbmstbGluZXMtYWZ0ZXItcHJvY2VkdXJlcyAgICAg ICAgICAgIC8vIC1iYXANCi0tc3dhbGxvdy1vcHRpb25hbC1ibGFuay1saW5l cyAgICAgICAgICAgIC8vIC1zb2INCg== ---2107239605-578346705-1060746412=:2664541 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=myindent Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=myindent IyEvYmluL2VudiBwZXJsDQojDQojIEFuZHJldyBKYW5rZSAtIHJvdG9yQGJp Yy5tbmkubWNnaWxsLmNhDQojDQojIG15IGluZGVudGVyIE1LIDEuMCBjb3Mg J2luZGVudCcgZG9lc24ndCBoYXZlIGEgLW1lIG9wdGlvbg0KIw0KIyBUdWUg SmFuIDIyIDEyOjMzOjI5IEVTVCAyMDAyIC0gaW5pdGlhbCB2ZXJzaW9uDQoj IEZyaSBNYXIgIDggMjM6Mjg6NTIgRVNUIDIwMDIgLSBmaW5pc2hlZCBvZmYg U1RESU4vU1RET1VUIHN0dWZmDQojIE1vbiBKdW4gMzAgMTU6MjU6MjkgRVNU IDIwMDMgLSBhZGRlZCBtb3JlIG9wdGlvbnMgYW5kIHN1YnNlcXVlbnQgcmVt b3ZhbA0KIyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgb2Yg Y29kZSBmcm9tIHByb2Nlc3NfbGluZSgpDQoNCiRTSUd7X19ESUVfX30gPSBz dWIgeyAmY2xlYW51cDsgZGllICRfWzBdOyB9Ow0KY2hvbXAoJG1lID0gYGJh c2VuYW1lICQwYCk7DQokdG1wZmlsZSA9ICIvdG1wLyRtZS0kJCI7DQoNCiR0 YWJzaXplID0gMzsNCiR0YWJ0ZXh0ID0gJyAnIHggJHRhYnNpemU7DQoNCiMg LS0gdGhpcyBpcyBub3cgYWxsIGluICR7SE9NRX0vLmluZGVudC5wcm8NCiMg QGlfYXJncyA9ICgNCiMgICAgJy0tbGluZS1sZW5ndGg5MCcsICAgICAgICAg ICAgICAgICAgICMgLWw5MA0KIyAgICAnLS1jb21tZW50LWluZGVudGF0aW9u NDAnLCAgICAgICAgICAgIyAtYzQwDQojICAgICctLWRlY2xhcmF0aW9uLWNv bW1lbnQtY29sdW1uNDAnLCAgICAjIC1jZDQwDQojICAgICctLWRlY2xhcmF0 aW9uLWluZGVudGF0aW9uOScsICAgICAgICAjIC1kaTkNCiMgICAgJy0tZG9u dC1icmVhay1wcm9jZWR1cmUtdHlwZScsICAgICAgICMgLW5wc2wNCiMgICAg Jy0tY29udGludWUtYXQtcGFyZW50aGVzZXMnLCAgICAgICAgICMgLWxwDQoj ICAgICctLWhvbm91ci1uZXdsaW5lcycsICAgICAgICAgICAgICAgICAjIC1o bmwNCiMgDQojICAgICMgaW5kZW50L3RhYiBzaXplDQojICAgICItLXRhYi1z aXplJHRhYnNpemUiLCAgICAgICAgICAgICAgICAjIC10cyR0YWJzaXplDQoj ICAgICItLWluZGVudC1sZXZlbCR0YWJzaXplIiwgICAgICAgICAgICAjIC1p JHRhYnNpemUNCiMgICAgJy0tbm8tdGFicycsICAgICAgICAgICAgICAgICAg ICAgICAgICMgLW51dA0KIyANCiMgICAgIyBicmFjZXMNCiMgICAgJy0tYnJh Y2VzLW9uLWlmLWxpbmUnLCAgICAgICAgICAgICAgICMgLWJyDQojICAgICct LWJyYWNlcy1vbi1zdHJ1Y3QtZGVjbC1saW5lJywgICAgICAjIC1icnMNCiMg DQojICAgICMgd2hpdGVzcGFjZQ0KIyAgICAnLS1uby1zcGFjZS1hZnRlci1j YXN0cycsICAgICAgICAgICAgICAgICAgIyAtbmNzDQojICAgICctLW5vLXNw YWNlLWFmdGVyLWZvcicsICAgICAgICAgICAgICAgICAgICAjIC1uc2FmDQoj ICAgICctLW5vLXNwYWNlLWFmdGVyLWZ1bmN0aW9uLWNhbGwtbmFtZXMnLCAg ICAjIC1ucGNzDQojICAgICctLW5vLXNwYWNlLWFmdGVyLWlmJywgICAgICAg ICAgICAgICAgICAgICAjIC1uc2FpDQojICAgICctLW5vLXNwYWNlLWFmdGVy LXBhcmVudGhlc2VzJywgICAgICAgICAgICAjIC1ucHJzDQojICAgICctLW5v LXNwYWNlLWFmdGVyLXdoaWxlJywgICAgICAgICAgICAgICAgICAjIC1uc2F3 DQojICAgICctLWRvbnQtY3VkZGxlLWRvLXdoaWxlJywgICAgICAgICAgICAg ICAgICAjIC1uY2R3DQojICAgICctLWRvbnQtY3VkZGxlLWVsc2UnLCAgICAg ICAgICAgICAgICAgICAgICAjIC1uY2UNCiMgICAgJy0tbm8tc3BhY2UtYWZ0 ZXItY2FzdHMnLCAgICAgICAgICAgICAgICAgICMgLW5jcw0KIyANCiMgICAg IyBibGFuayBsaW5lcw0KIyAgICAnLS1ibGFuay1saW5lcy1hZnRlci1kZWNs YXJhdGlvbnMnLCAgICAgICAgIyAtYmFkDQojICAgICctLWJsYW5rLWxpbmVz LWFmdGVyLXByb2NlZHVyZXMnLCAgICAgICAgICAjIC1iYXANCiMgICAgJy0t c3dhbGxvdy1vcHRpb25hbC1ibGFuay1saW5lcycsICAgICAgICAgICMgLXNv Yg0KIyAgICApOw0KIw0KIyRpbmRlbnRfYXJncyA9IGpvaW4gKCcgJywgQGlf YXJncyk7DQokaW5kZW50X2FyZ3MgPSAnJzsNCg0KIyBjaGVjayBpZiB3ZSBh cmUgU1RESU4naW5nIG9yIGEgZmlsZQ0KaWYgKCFkZWZpbmVkKCRBUkdWWzBd KSB8fCAoJEFSR1ZbMF0gZXEgJy0nKSkgew0KDQogICAjIG9wZW4gdGhlIHRt cGZpbGUNCiAgIG9wZW4oVE1QRkgsICJ8IGluZGVudCAkaW5kZW50X2FyZ3Mg PiAkdG1wZmlsZSIpDQogICAgICB8fCBkaWUgIlVuYWJsZSB0byBvcGVuIFNU RElOOiAkIVxuIjsNCg0KICAgZm9yZWFjaCAoPFNURElOPikgew0KICAgICAg cHJpbnQgVE1QRkg7DQogICAgICB9DQogICBjbG9zZShUTVBGSCkgfHwgZGll Ow0KDQogICBvcGVuKFRNUEZILCAkdG1wZmlsZSkNCiAgICAgIHx8IGRpZSAi VW5hYmxlIHRvIG9wZW4gJHRtcGZpbGU6ICQhXG4iOw0KDQogICBmb3JlYWNo ICg8VE1QRkg+KSB7DQogICAgICAmcHJvY2Vzc19saW5lOw0KICAgICAgcHJp bnQgU1RET1VUOw0KICAgICAgfQ0KICAgY2xvc2UoVE1QRkgpIHx8IGRpZTsN CiAgIH0NCmVsc2Ugew0KDQogICAjIGZvciBlYWNoIGlucHV0IGZpbGUNCiAg IGZvcmVhY2ggJGluZmlsZSAoQEFSR1YpIHsNCg0KICAgICAgcHJpbnQgIiB8 IEluZGVudGluZyAkaW5maWxlXG4iOw0KDQogICAgICAjIGNoZWNrIGZvciB0 aGUgaW5maWxlDQogICAgICBpZiAoIS1lICRpbmZpbGUpIHsNCiAgICAgICAg IGRpZSAiJG1lOiBDb3VsZG4ndCBmaW5kICRpbmZpbGVcbiI7DQogICAgICAg ICB9DQoNCiAgICAgIGlmICgkaW5maWxlICF+IC9cLihjfGgpJC8pIHsNCiAg ICAgICAgIHdhcm4gIiRtZTogJGluZmlsZSBkb2Vucyd0IGFwcGVhciB0byBi ZSBhIEMgZmlsZVxuIjsNCiAgICAgICAgIH0NCg0KICAgICAgIyBtYWtlIHRo ZSBiYWNrdXAgY29weSwgb3BlbiBpdCBhbmQgdGhlIG9yaWdpbmFsIGZpbGUN CiAgICAgIHN5c3RlbSgnY3AnLCAkaW5maWxlLCAiJGluZmlsZS5vbGQiKSA9 PSAwIG9yIGRpZTsNCiAgICAgIG9wZW4oRkgsICJjYXQgJGluZmlsZS5vbGQg fCBpbmRlbnQgJGluZGVudF9hcmdzIHwiKQ0KICAgICAgICAgfHwgZGllICJV bmFibGUgdG8gcmVhZCBmcm9tIGluZGVudDogJCFcbiI7DQogICAgICBvcGVu KE9VVEZILCAiPiRpbmZpbGUiKQ0KICAgICAgICAgfHwgZGllICJVbmFibGUg dG8gb3BlbiAkaW5maWxlOiAkIVxuIjsNCg0KICAgICAgZm9yZWFjaCAoPEZI Pikgew0KICAgICAgICAgJnByb2Nlc3NfbGluZTsNCiAgICAgICAgIHByaW50 IE9VVEZIICRfOw0KICAgICAgICAgfQ0KDQogICAgICBjbG9zZShGSCkgICAg fHwgZGllOw0KICAgICAgY2xvc2UoT1VURkgpIHx8IGRpZTsNCiAgICAgIH0N CiAgIH0NCiZjbGVhbnVwOw0KDQojIGZpeCB1cCAneycgYW5kICd9JyB0byBo b3cgSSBsaWtlIHRoZW0gIEZJWCBJTkRFTlQgU09NRU9ORSEgOikNCnN1YiBw cm9jZXNzX2xpbmUgew0KDQogICBpZiAobS9eXCAqXH0vKSB7DQogICAgICBz L1x9LyR0YWJ0ZXh0XH0vZzsNCiAgICAgIH0NCiAgIHMvXClcIFx7L1wpXHsv ZzsNCiAgIH0NCg0Kc3ViIGNsZWFudXAgew0KICAgQGFyZ3MgPSAoJ3JtJywg Jy1yJywgJy1mJywgJHRtcGZpbGUpOw0KICAgc3lzdGVtIEBhcmdzOw0KICAg fQ0K ---2107239605-578346705-1060746412=:2664541-- From minc-development@bic.mni.mcgill.ca Wed Aug 13 05:28:29 2003 From: minc-development@bic.mni.mcgill.ca (Andrew Janke) Date: Wed, 13 Aug 2003 14:28:29 +1000 Subject: [MINC-development] volume_stats/mincstats??? In-Reply-To: References: Message-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---2107239605-2105447743-1060748909=:2664541 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 12 Aug 2003, Robert VINCENT wrote: > I've taken a look at this. If I follow Peter's comments and the program's > logic, it looks as though the following line needs to be added to > mincstats.c: > > *** 618,623 **** > --- 618,624 ---- > else > stats->median = ((double)median_bin + (0.5 - cdf[median_bin]) > * pdf[median_bin + 1]) * hist_sep; > + stats->median += hist_centre[0]; > > stats->majority = hist_centre[majority_bin]; > stats->biModalT = hist_centre[bimodalt_bin]; > > Does this look correct? >From what I can tell yes. I have a slightly more extensive diff (attached) of which the only change of consequence (I hope!) is the one above. Once I get a go-ahead WRT indenting I'll commit extensive indenting changes + the change above to CVS. Howver on this matter, those comparing mincstats and volume_stats should note that the output at least of histogramming is never going to be identical, this comes down to a fundamental "algorithmic mis-match" between what peter & I and Alex think the centre of a discrete minc histogram should be and also how many default bins should be used for a discrete minc file. :) In order to more closely replicate the behaviour of volume_stats with mincstats on a discrete (non float or double) minc file, mincstats should be used as such: $ mincstats -discrete_histogram file.mnc (see the mincstats man page for the gory details of this) -- 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 ---2107239605-2105447743-1060748909=:2664541 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=diff Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=diff SW5kZXg6IG1pbmNzdGF0cy5jDQo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpS Q1MgZmlsZTogL3NvZnR3YXJlL3NvdXJjZS9taW5jL2N2c3Jvb3QvbWluYy9w cm9ncy9taW5jc3RhdHMvbWluY3N0YXRzLmMsdg0KcmV0cmlldmluZyByZXZp c2lvbiAxLjExDQpkaWZmIC11IC1iIC1CIC1yMS4xMSBtaW5jc3RhdHMuYw0K LS0tIG1pbmNzdGF0cy5jIDUgU2VwIDIwMDIgMDA6NDE6NTcgLTAwMDAgICAg ICAgMS4xMQ0KKysrIG1pbmNzdGF0cy5jIDEzIEF1ZyAyMDAzIDA0OjIwOjIx IC0wMDAwDQpAQCAtNTcyLDEwICs1NzIsMTAgQEANCiANCiAgICAgICAgICAg ICBmb3IgKGM9MDsgYyA8IGhpc3RfYmluczsgYysrKSB7DQogICAgICAgICAg ICAgICAgaGlzdF9jZW50cmVbY10gPSAoYypoaXN0X3NlcCkgKyBoaXN0X3Jh bmdlWzBdICsgKGhpc3Rfc2VwLzIpOw0KLSAgICAgICAgICAgICAgIHBkZltj XSA9IChzdGF0cy0+aHZveGVscyA+IDApID8gDQotICAgICAgICAgICAgICAg ICAgc3RhdHMtPmhpc3RvZ3JhbVtjXS9zdGF0cy0+aHZveGVscyA6IDAuMDsN Ci0gICAgICAgICAgICAgICBpZiAoYyA9PSAwKSB7IGNkZltjXSA9IHBkZltj XTsgICAgICAgICAgICB9DQotICAgICAgICAgICAgICAgZWxzZSAgICAgICAg eyBjZGZbY10gPSBjZGZbYy0xXSArIHBkZltjXTsgfQ0KKyAgICAgICAgICAg ICAgIA0KKyAgICAgICAgICAgICAgIC8qIFByb2JhYmlsaXR5IGFuZCBDdW11 bGF0aXZlIGRlbnNpdHkgZnVuY3Rpb25zICovDQorICAgICAgICAgICAgICAg cGRmW2NdID0gKHN0YXRzLT5odm94ZWxzID4gMCkgPw0Kc3RhdHMtPmhpc3Rv Z3JhbVtjXS9zdGF0cy0+aHZveGVscyA6IDAuMDsNCisgICAgICAgICAgICAg ICBjZGZbY10gPSAoYyA9PSAwKSA/IHBkZltjXSA6IGNkZltjLTFdICsgcGRm W2NdOw0KIA0KICAgICAgICAgICAgICAgIC8qIE1ham9yaXR5ICovDQogICAg ICAgICAgICAgICAgaWYgKHN0YXRzLT5oaXN0b2dyYW1bY10gPiBzdGF0cy0+ aGlzdG9ncmFtW21ham9yaXR5X2Jpbl0pIHsNCkBAIC02MTMsMjEgKzYxMywy NiBAQA0KICAgICAgICAgICAgIH0NCiAgICAgICAgICANCiAgICAgICAgICAg ICAvKiBtZWRpYW4gKi8NCi0gICAgICAgICAgICBpZiAobWVkaWFuX2JpbiA9 PSAwKQ0KKyAgICAgICAgICAgIGlmIChtZWRpYW5fYmluID09IDApew0KICAg ICAgICAgICAgICAgIHN0YXRzLT5tZWRpYW4gPSAwLjUgKiBwZGZbbWVkaWFu X2Jpbl0gKiAgaGlzdF9zZXA7DQotICAgICAgICAgICAgZWxzZQ0KKyAgICAg ICAgICAgICAgIH0NCisgICAgICAgICAgICBlbHNlew0KICAgICAgICAgICAg ICAgIHN0YXRzLT5tZWRpYW4gPSAoKGRvdWJsZSltZWRpYW5fYmluICsgKDAu NSAtIGNkZlttZWRpYW5fYmluXSkgDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAqIHBkZlttZWRpYW5fYmluICsgMV0pICogIGhpc3Rfc2Vw Ow0KKyAgICAgICAgICAgICAgIH0NCisgICAgICAgICAgICBzdGF0cy0+bWVk aWFuICs9IGhpc3RfY2VudHJlWzBdOw0KICAgICAgIA0KICAgICAgICAgICAg IHN0YXRzLT5tYWpvcml0eSA9IGhpc3RfY2VudHJlW21ham9yaXR5X2Jpbl07 DQogICAgICAgICAgICAgc3RhdHMtPmJpTW9kYWxUID0gaGlzdF9jZW50cmVb Ymltb2RhbHRfYmluXTsNCiAgICAgICANCiAgICAgICAgICAgICAvKiBwY3Qg VGhyZXNob2xkICovDQotICAgICAgICAgICAgaWYgKHBjdHRfYmluID09IDAp DQorICAgICAgICAgICAgaWYgKHBjdHRfYmluID09IDApew0KICAgICAgICAg ICAgICAgIHN0YXRzLT5wY3RfVCA9IHBjdFQgKiBwZGZbcGN0dF9iaW5dICog IGhpc3Rfc2VwOw0KLSAgICAgICAgICAgIGVsc2UNCisgICAgICAgICAgICAg ICB9DQorICAgICAgICAgICAgZWxzZXsNCiAgICAgICAgICAgICAgICBzdGF0 cy0+cGN0X1QgPSAoKGRvdWJsZSlwY3R0X2JpbiArIChwY3RUIC0gY2RmW3Bj dHRfYmluXSkgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICog cGRmW3BjdHRfYmluICsgMV0pICogIGhpc3Rfc2VwOw0KKyAgICAgICAgICAg ICAgIH0NCiAgICAgICANCiAgICAgICAgICAgICAvKiBvdXRwdXQgdGhlIGhp c3RvZ3JhbSAqLw0KICAgICAgICAgICAgIGlmIChoaXN0X2ZpbGUgIT0gTlVM TCkgew0KQEAgLTcyNCw4ICs3MjksOSBAQA0KICAgIH0gICAvKiBFbmQgb2Yg bG9vcCBvdmVyIHJhbmdlcyAqLw0KIA0KICAgIC8qIENsb3NlIHRoZSBoaXN0 b2dyYW0gZmlsZSAqLw0KLSAgIGlmIChGUCAhPSBOVUxMKQ0KKyAgIGlmIChG UCAhPSBOVUxMKXsNCiAgICAgICh2b2lkKSBmY2xvc2UoRlApOw0KKyAgICAg fQ0KIA0KICAgIC8qIEZyZWUgdGhpbmdzIHVwICovDQogICAgZm9yIChpcmFu Z2U9MDsgaXJhbmdlIDwgbnVtX3JhbmdlczsgaXJhbmdlKyspIHsNCkBAIC04 MzYsNyArODQyLDkgQEANCiAgICAgICBpZiAoSGlzdCAmJiAodmFsdWUgPj0g aGlzdF9yYW5nZVswXSkgJiYgKHZhbHVlIDw9IGhpc3RfcmFuZ2VbMV0pKSB7 DQogICAgICAgICAgLypsb3dlciBsaW1pdCA8PSB2YWx1ZSA8IHVwcGVyIGxp bWl0ICovDQogICAgICAgICAgaGlzdF9pbmRleCA9IChpbnQpZmxvb3IoKHZh bHVlIC0gaGlzdF9yYW5nZVswXSkvaGlzdF9zZXApOw0KLSAgICAgICAgIGlm IChoaXN0X2luZGV4ID49IGhpc3RfYmlucykgaGlzdF9pbmRleCA9IGhpc3Rf Ymlucy0xOw0KKyAgICAgICAgIGlmIChoaXN0X2luZGV4ID49IGhpc3RfYmlu cyl7DQorICAgICAgICAgICAgaGlzdF9pbmRleCA9IGhpc3RfYmlucy0xOw0K KyAgICAgICAgICAgIH0NCiAgICAgICAgICBzdGF0cy0+aGlzdG9ncmFtW2hp c3RfaW5kZXhdKys7DQogICAgICAgICAgc3RhdHMtPmh2b3hlbHMrKzsNCiAg ICAgICB9DQoNCg== ---2107239605-2105447743-1060748909=:2664541-- From minc-development@bic.mni.mcgill.ca Wed Aug 13 14:07:27 2003 From: minc-development@bic.mni.mcgill.ca (Steve ROBBINS) Date: Wed, 13 Aug 2003 09:07:27 -0400 Subject: [MINC-development] MINC musings. In-Reply-To: ; from rotor@cmr.uq.edu.au on Wed, Aug 13, 2003 at 01:46:52PM +1000 References: Message-ID: <20030813090727.F1927446@shadow.bic.mni.mcgill.ca> On Wed, Aug 13, 2003 at 01:46:52PM +1000, Andrew Janke wrote: > > Whilst in the process of fixing the mincstats bug (patch to follow shortly) I > noted that my CVS repo if MINC was waaay out of date and updated. > > I note the build process has been revamped again (Master Robbins no doubt :), It was Bert who did the major work in automakification; I helped out where I could. For one example, I've added a few more test cases to ensure fixed bugs don't reoccur. > for a while now building minc has required automake/autoconf et al and > subsequently perl. No. Building MINC requires none of the above. You, as a developer using CVS, need to have automake, autoconf, and libtool. The end-user of the tarball requires none of these. > what are the conditions that are going to be needed to be met to 'allow' a new > addittion to the base MINC stable? Previously this sort of fell upon peter, > him being the MINC grand-poo-bar and all that. > > A vote? anarchy? I expect that, if someone made a specific proposal, we could come to consensus on this list. We've been more or less doing that for the minor bug fixes over the last while. Before we get to your soapbox speech, let me insert two of my own: 1. ChangeLog! It's a great help for future MINC coders if you include a ChangeLog entry with every change. Standard practice on other lists is to prepend your diff by the (NON DIFF) ChangeLog entry. The idea is that the change log should give the reader the context in which to understand the diff. (Otherwise, noone is likely to read and comment on it). 2. Test cases. Automake has some machinery to automatically run a test suite ("make check"). When a bug has been identified, it is good practice to first write a test that exposes the bug. Wrap it in a shell script that returns an error code (nonzero). Then fix the bug and run "make check" to ensure it is gone. The beauty of the test suite is that -- since the developers always run make check before committing, right?? --- if the bug is ever accidentally reintroduced, it will be caught immediately. > * Can we remove mincexample{1,2} from the base install/build or > shove them in a separate ./dev/ directory? Considering the > executables appear to be now built in ./ The examples aren't installed. Are you objecting to having them merely built in the toplevel directory? > * I'm the first to admit I don't indent (code) as others do. I'm > also the first to admit that the indenting in both minccalc and > mincstats is pretty ugly. So is it possible that we can define > a default indenting style for all MINC code before it is submitted? > I have attached my own .indent.pro file that I attempt to use for > most of my other CVS code /s/s/minc_dev but sadly I didn't use > indent on the mincstats, minccalc as I just mailed the initial > hacks to peter and he included them. I'm only going to say two things about this can of worms. 1. indentations must be 4 spaces per level (or 8 spaces per level). It's just too hard to tell the difference between 2/4/6 or 3/6/9 when there are 20 or more lines of text in between 2. If you're going to reindent things, YOU MUST make it a separate cvs commit. Do not include other changes along with indentation changes: it is way too hard to read the diffs to figure out what is going on. YOU MUST put a clear statement in the ChangeLog and in the cvs commit message to the effect that this is only a change in indentation. -S From minc-development@bic.mni.mcgill.ca Wed Aug 13 19:35:44 2003 From: minc-development@bic.mni.mcgill.ca (Jacqueline Chen) Date: Wed, 13 Aug 2003 14:35:44 -0400 (EDT) Subject: [MINC-development] volume_stats/mincstats??? In-Reply-To: Message-ID: Many thanks! Appreciatively, Jacqueline On Wed, 13 Aug 2003, Andrew Janke wrote: > On Tue, 12 Aug 2003, Robert VINCENT wrote: > > > I've taken a look at this. If I follow Peter's comments and the program's > > logic, it looks as though the following line needs to be added to > > mincstats.c: > > > > *** 618,623 **** > > --- 618,624 ---- > > else > > stats->median = ((double)median_bin + (0.5 - cdf[median_bin]) > > * pdf[median_bin + 1]) * hist_sep; > > + stats->median += hist_centre[0]; > > > > stats->majority = hist_centre[majority_bin]; > > stats->biModalT = hist_centre[bimodalt_bin]; > > > > Does this look correct? > > >From what I can tell yes. I have a slightly more extensive diff (attached) of > which the only change of consequence (I hope!) is the one above. Once I get a > go-ahead WRT indenting I'll commit extensive indenting changes + the change > above to CVS. > > Howver on this matter, those comparing mincstats and volume_stats should note > that the output at least of histogramming is never going to be identical, this > comes down to a fundamental "algorithmic mis-match" between what peter & I and > Alex think the centre of a discrete minc histogram should be and also how many > default bins should be used for a discrete minc file. :) > > In order to more closely replicate the behaviour of volume_stats with mincstats > on a discrete (non float or double) minc file, mincstats should be used as such: > > $ mincstats -discrete_histogram file.mnc > > (see the mincstats man page for the gory details of this) > > -- > 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 Aug 14 01:25:50 2003 From: minc-development@bic.mni.mcgill.ca (Andrew Janke) Date: Thu, 14 Aug 2003 10:25:50 +1000 Subject: [MINC-development] MINC musings. In-Reply-To: <20030813090727.F1927446@shadow.bic.mni.mcgill.ca> References: <20030813090727.F1927446@shadow.bic.mni.mcgill.ca> Message-ID: On Wed, 13 Aug 2003, Steve ROBBINS wrote: > > for a while now building minc has required automake/autoconf et al and > > subsequently perl. > > No. Building MINC requires none of the above. > > You, as a developer using CVS, need to have automake, autoconf, and libtool. > The end-user of the tarball requires none of these. Ah, IC. The light finally dawns. > 1. ChangeLog! It's a great help for future MINC coders if you > include a ChangeLog entry with every change. Standard practice on > other lists is to prepend your diff by the (NON DIFF) ChangeLog > entry. The idea is that the change log should give the reader > the context in which to understand the diff. (Otherwise, noone > is likely to read and comment on it). So you want a changelog entry posted before a CVS commit? Sounds reasonable enough to me. > 2. Test cases. Automake has some machinery to automatically run > a test suite ("make check"). When a bug has been identified, it > is good practice to first write a test that exposes the bug. Wrap > it in a shell script that returns an error code (nonzero). Then > fix the bug and run "make check" to ensure it is gone. The beauty > of the test suite is that -- since the developers always run > make check before committing, right?? --- if the bug is ever > accidentally reintroduced, it will be caught immediately. Testing? Shmesting! :) Orright, orright, I'll have a hack at writing a test suite for mincstats. > > * Can we remove mincexample{1,2} from the base install/build or > > shove them in a separate ./dev/ directory? Considering the > > executables appear to be now built in ./ > > The examples aren't installed. Are you objecting to having them > merely built in the toplevel directory? Not really, just wondering how many people who build MINC realise they are even there. At least if they were in a ./dev directory (and if I ever get to finishing my other voxel-loop examples) their purpose IMHO would be more obvious. > > indenting. > > I'm only going to say two things about this can of worms. > > 1. indentations must be 4 spaces per level (or 8 spaces per level). > It's just too hard to tell the difference between 2/4/6 or 3/6/9 > when there are 20 or more lines of text in between I can live with this. > 2. If you're going to reindent things, YOU MUST make it a separate > cvs commit. Do not include other changes along with indentation changes: > it is way too hard to read the diffs to figure out what is going on. > YOU MUST put a clear statement in the ChangeLog and in the cvs commit > message to the effect that this is only a change in indentation. Done deal. So do I make the changes to mincstats? (After I figure out how to write a test case! ) -- 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