From giovanna.pellecchia at camhpet.ca Tue Nov 1 10:43:53 2011 From: giovanna.pellecchia at camhpet.ca (Giovanna Pellecchia) Date: Tue, 01 Nov 2011 10:43:53 -0400 Subject: [MINC-users] [MINC-development] GLUT colours In-Reply-To: References: <3A53A56C-954C-4AB8-856A-AF1F9B6E280F@phenogenomics.ca> <3E5A7A72-A770-451E-8A67-8D2227795460@phenogenomics.ca> Message-ID: <4EB005A9.8050201@camhpet.ca> Hi there, I am not sure about Mac OSX, however the problems which afflicted both register and Display on Ubuntu 10.04 //"Could not get requested colour_map_mode(0), got(1,256)" //can be resolved by installing an earlier version of freeglut (2.4.0_61 worked for me) instead of the current version in the repository (I think it might be 3 now?), as reported earlier: http://www.bic.mni.mcgill.ca/pipermail/minc-users/2010-March/002684.html Giovanna. Haz-Edine Assemlal wrote: > I confirm this issue, I had the same artefact on OS 10.6. It is my understanding that those problems come from the GLUT library. Also it seems that there are similar issues when compiling Display on newer versions of Ubuntu. > > Regards, > Haz-Edine > > On 2011-10-30, at 3:30 PM, Jason Lerch wrote: > > From assemlal at cim.mcgill.ca Wed Nov 2 16:52:23 2011 From: assemlal at cim.mcgill.ca (Haz-Edine Assemlal) Date: Wed, 02 Nov 2011 16:52:23 -0400 Subject: [MINC-users] [MINC-development] GLUT colours In-Reply-To: References: <3A53A56C-954C-4AB8-856A-AF1F9B6E280F@phenogenomics.ca> <3E5A7A72-A770-451E-8A67-8D2227795460@phenogenomics.ca> Message-ID: <1320267143.2330.13.camel@talos> Hi Andrew, It seems that Display 1.4.x is not affected by this issue. The differences with Display 1.5.x are mainly in the file Graphics/GLUT_windows/glut_windows.c. It looks like that v1.4.x was aware of this bug and found a hackish way to go around it. In particular, it includes its own freeglut_std.h and glut.h. Display 1.5.x does the things properly but then relies on a correct implementation of GLUT in the drivers. Is there any significant feature or improvement from Display 1.4.x to 1.5.x? Best, Haz-Edine On Wed, 2011-11-02 at 01:00 +1000, Andrew Janke wrote: > Hi Jason (And others), > > > I was rebuilding all the MINCy goodness on OS 10.7, and am running into some > > fun psychedelic colours with Display and register (see attached). Anybody > > have any hints about where to look to solve this? I remember a message from > > Jim a few months/years ago which appeared to suggest that this issue was > > somehow tied into MINC versions, supposedly patched in 2.0.19. I'm using > > 2.1, in case that is indeed the issue; if anyone remembers where in the MINC > > codebase that colourful output was created I can look to see if it's still > > there or has somehow returned ... > > As Giovanna mentioned it seems to be a chance in freeglut that (in my > experience) causes some conflict with nvidia drivers. At least this is > the problem I see on the one Ubuntu system on which I can make this > happen. If I then remove the nvidia driver and use nv, the problem > goes away. > > You'll also find that other GLUT packages are also having this issue > "out there" via our friend google. To test what is going on with your > machine (this bug seems to have multiple incarnations) try this little > bit of code: > > #include > > /* compile with: gcc -o test test.c -lglut */ > > void display(void) { > glClear(GL_COLOR_BUFFER_BIT); > glFlush(); > } > > int main(int argc, char **argv) { > glutInit(&argc, argv); > glutCreateWindow("test"); > glutDisplayFunc(display); > glutMainLoop(); > return 0; > } > > On some systems this will result in a pretty colours others a black > background (as would be expected). Some also have this little bit of > test code whinging "Could not get requested colour_map_mode(0), > got(1,256)". > > So, that's where I've got with this so far! ie: nowhere really given > that I can reproduce the buggy behavior without MINC! > > My only thought for this is to finish off/trim down viewnup and put > the point based registration code into it as it doesn't seem to suffer > this issue. So that's what I've been doing in the last few weeks as > this one doesn't seem to want to go away. > > here's hoping you find some magick little hack to get around this. > > :) > > > a > _______________________________________________ > MINC-development mailing list > MINC-development at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development From a.janke at gmail.com Thu Nov 3 08:24:17 2011 From: a.janke at gmail.com (Andrew Janke) Date: Thu, 3 Nov 2011 22:24:17 +1000 Subject: [MINC-users] [MINC-development] GLUT colours In-Reply-To: <1320267143.2330.13.camel@talos> References: <3A53A56C-954C-4AB8-856A-AF1F9B6E280F@phenogenomics.ca> <3E5A7A72-A770-451E-8A67-8D2227795460@phenogenomics.ca> <1320267143.2330.13.camel@talos> Message-ID: > It seems that Display 1.4.x is not affected by this issue. The > differences with Display 1.5.x are mainly in the file > Graphics/GLUT_windows/glut_windows.c. > > It looks like that v1.4.x was aware of this bug and found a hackish way > to go around it. In particular, it includes its own freeglut_std.h and > glut.h. > > Display 1.5.x does the things properly but then relies on a correct > implementation of GLUT in the drivers. > > Is there any significant feature or improvement from Display 1.4.x to > 1.5.x? Nope, no feature changes. These changes (ironically) were to solve other problems with colourmap issues when using Display/register remotely.... Meaning if we change it back GLUT will start breaking in other places for others. Odds are there is no one combination that will work for everyone so we might have to go down the heady path of a few more C/L switches (register {-rgb,-mac,-lut} ...) to keep everyone happy. a From Paul.Rasser at newcastle.edu.au Fri Nov 4 00:03:56 2011 From: Paul.Rasser at newcastle.edu.au (Paul Rasser) Date: Fri, 04 Nov 2011 15:03:56 +1100 Subject: [MINC-users] classify_clean Message-ID: <4EB3FED60200001F00046BB9@WINDOMPRD00.newcastle.edu.au> Dear all, I'm looking to use classify_clean to classify volumes in native space and was hoping for suggestions/concerns with respect to using it in the following way: #find nl transformation nlfit_smr subj.mnc nl.xfm -model colin27_t1_tal_lin #invert transformation xfminvert nl.xfm nl_inv.xfm #invert .tag files to subject's native space transform_tags ~/ntags_1000_prob_90_nobg.tag nl_inv.xfm ntags_1000_prob_90_nobg.tag transform_tags ~/ntags_1000_bg.tag nl_inv.xfm ntags_1000_bg.tag #apply classfy_clean to subject in native space classify_clean -clean_tags subj.mnc subj_seg.mnc Also, is the best reference for classify_clean and nlfit_smr: Zijdenbos, A. P., Forghani, R. and Evans, A. C. (2002) Automatic "pipeline" analysis of 3-D MRI data for clinical trials: application to multiple sclerosis. IEEE Trans Med Imaging 21, 1280-1291? Thanks for any help, Paul From a.janke at gmail.com Fri Nov 4 01:43:40 2011 From: a.janke at gmail.com (Andrew Janke) Date: Fri, 4 Nov 2011 15:43:40 +1000 Subject: [MINC-users] classify_clean In-Reply-To: <4EB3FED60200001F00046BB9@WINDOMPRD00.newcastle.edu.au> References: <4EB3FED60200001F00046BB9@WINDOMPRD00.newcastle.edu.au> Message-ID: Hi Paul, On 4 November 2011 14:03, Paul Rasser wrote: > I'm looking to use classify_clean to classify volumes in native space and was hoping for suggestions/concerns with respect to using it in the following way: I generally always do tissue classification in model space but I can't see any reason as to why this approach won't work. > #find nl transformation > nlfit_smr subj.mnc nl.xfm -model colin27_t1_tal_lin > > #invert transformation > xfminvert nl.xfm ?nl_inv.xfm > > #invert .tag files to subject's native space > transform_tags ~/ntags_1000_prob_90_nobg.tag nl_inv.xfm ntags_1000_prob_90_nobg.tag > transform_tags ~/ntags_1000_bg.tag nl_inv.xfm ntags_1000_bg.tag > > #apply classfy_clean to subject in native space > classify_clean -clean_tags subj.mnc subj_seg.mnc I take it you also supply -tagfile -bgtagfile arguments so that your custom tags are used? Either that or you can always skip transforming the tags and instead supply a -tag_transform argument. a From Paul.Rasser at newcastle.edu.au Sun Nov 6 19:33:22 2011 From: Paul.Rasser at newcastle.edu.au (Paul Rasser) Date: Mon, 07 Nov 2011 11:33:22 +1100 Subject: [MINC-users] classify_clean Message-ID: <4EB7C1F40200001F00046CD5@WINDOMPRD00.newcastle.edu.au> Thanks Andrew. re: -tagfile -bgtagfile, in a way yes, as I have tested with -tagdir to point to the custom inverted tags (which I call ntags_1000_bg.tag and ntags_1000_prob_90_nobg.tag) , but -tag_transform looks like it might be a better option. Also, any help with the reference for classify_clean and nlfit_smr would be greatly appreciated. Thanks again, Paul >>> Andrew Janke 04/11/11 4:51 PM >>> Hi Paul, On 4 November 2011 14:03, Paul Rasser wrote: > I'm looking to use classify_clean to classify volumes in native space and was hoping for suggestions/concerns with respect to using it in the following way: I generally always do tissue classification in model space but I can't see any reason as to why this approach won't work. > #find nl transformation > nlfit_smr subj.mnc nl.xfm -model colin27_t1_tal_lin > > #invert transformation > xfminvert nl.xfm nl_inv.xfm > > #invert .tag files to subject's native space > transform_tags ~/ntags_1000_prob_90_nobg.tag nl_inv.xfm ntags_1000_prob_90_nobg.tag > transform_tags ~/ntags_1000_bg.tag nl_inv.xfm ntags_1000_bg.tag > > #apply classfy_clean to subject in native space > classify_clean -clean_tags subj.mnc subj_seg.mnc I take it you also supply -tagfile -bgtagfile arguments so that your custom tags are used? Either that or you can always skip transforming the tags and instead supply a -tag_transform argument. a _______________________________________________ MINC-users at bic.mni.mcgill.ca http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users From zijdenbos at gmail.com Mon Nov 7 11:53:52 2011 From: zijdenbos at gmail.com (Alex Zijdenbos) Date: Mon, 7 Nov 2011 11:53:52 -0500 Subject: [MINC-users] minctracc -est_rotations Message-ID: Hi all, I was wondering if anybody knows why the command-line option -est_rotations was removed from minctracc? It is commented out in the code, but still there in the man page. -- A From a.janke at gmail.com Mon Nov 7 21:54:51 2011 From: a.janke at gmail.com (Andrew Janke) Date: Tue, 8 Nov 2011 12:54:51 +1000 Subject: [MINC-users] minctracc -est_rotations In-Reply-To: References: Message-ID: Hi Alex, On 8 November 2011 02:53, Alex Zijdenbos wrote: > I was wondering if anybody knows why the command-line option > -est_rotations was removed from minctracc? It is commented out in the > code, but still there in the man page. It was commented out by Patricia Lenezet years ago ('92) when adding the quaternion rotation options to minctracc. If my memory serves me correctly the reason was that it never worked properly in the first place! Louis may remember more details though. Still you are right, it should be removed from the man page. ta a From mishkind at gmail.com Mon Nov 7 23:21:27 2011 From: mishkind at gmail.com (Mishkin Derakhshan) Date: Mon, 7 Nov 2011 23:21:27 -0500 Subject: [MINC-users] classify_clean In-Reply-To: <4EB7C1F40200001F00046CD5@WINDOMPRD00.newcastle.edu.au> References: <4EB7C1F40200001F00046CD5@WINDOMPRD00.newcastle.edu.au> Message-ID: Hi Paul, Below is how I referenced the minc tools and classify_clean. Perhaps we should have a page with a list of references and how to reference the tools on the bic website (or the Minc wikibook) much like the folks at FSL and freesurfer. hth, mishkin Medical Imaging NetCDF (MINC) is a medical imaging data format and associated set of tools and libraries developed at the Montreal Neurological Institute (MNI) and freely available online (http://www. bic.mni.mcgill.ca/ServicesSoftware). The tool classify_clean, which is used to classify stereotaxic MINC volumes, involves a Bayesian labeling scheme and a set of standard sample points to compute an initial volume classification. This classification is then employed to purge incorrect tag points from the standard set, yielding a custom set of labels for the particular subject. Finally, this tag point set is used by an artificial neural net classifier to classify the volume (Zijdenbos et al., 1998). Zijdenbos, A., Forghani, R., Evans, A., 1998. Automatic quantification of MS lesions in 3D MRI brain data sets: validation of INSECT. Medical Image Computing and Computer-Assisted Interventation?MICCAI'98, pp. 439?448 On Sun, Nov 6, 2011 at 7:33 PM, Paul Rasser wrote: > Thanks Andrew. > > re: -tagfile -bgtagfile, in a way yes, as I have tested with -tagdir to point to the custom inverted tags (which I call ntags_1000_bg.tag and ntags_1000_prob_90_nobg.tag) , but ?-tag_transform looks like it might be a better option. > > Also, any help with the ?reference for classify_clean and nlfit_smr would be greatly appreciated. > > Thanks again, > Paul > > >>>> Andrew Janke 04/11/11 4:51 PM >>> > Hi Paul, > > On 4 November 2011 14:03, Paul Rasser wrote: >> I'm looking to use classify_clean to classify volumes in native space and was hoping for suggestions/concerns with respect to using it in the following way: > > I generally always do tissue classification in model space but I can't > see any reason as to why this approach won't work. > >> #find nl transformation >> nlfit_smr subj.mnc nl.xfm -model colin27_t1_tal_lin >> >> #invert transformation >> xfminvert nl.xfm ?nl_inv.xfm >> >> #invert .tag files to subject's native space >> transform_tags ~/ntags_1000_prob_90_nobg.tag nl_inv.xfm ntags_1000_prob_90_nobg.tag >> transform_tags ~/ntags_1000_bg.tag nl_inv.xfm ntags_1000_bg.tag >> >> #apply classfy_clean to subject in native space >> classify_clean -clean_tags subj.mnc subj_seg.mnc > > I take it you also supply -tagfile -bgtagfile arguments so that your > custom tags are used? ?Either that or you can always skip transforming > the tags and instead supply a ?-tag_transform > argument. > > > > a > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > From a.janke at gmail.com Tue Nov 8 00:36:27 2011 From: a.janke at gmail.com (Andrew Janke) Date: Tue, 8 Nov 2011 15:36:27 +1000 Subject: [MINC-users] classify_clean In-Reply-To: References: <4EB7C1F40200001F00046CD5@WINDOMPRD00.newcastle.edu.au> Message-ID: Hi Mishkin, On 8 November 2011 14:21, Mishkin Derakhshan wrote: > Below is how I referenced the minc tools and classify_clean. Perhaps > we should have a page with a list of references and how to reference > the tools on the bic website (or the Minc wikibook) much like the > folks at FSL and freesurfer. I definitely agree. There is no time like the present so I have borrowed your text above and immortalised it here: http://en.wikibooks.org/wiki/MINC/Authors Hope you don't mind! Other tool authors feel free to add your own text/headings in there. I seem to remember that classify also includes code from Louis Collins, Vasco Kollkinan(sp?) and Chris Cocosco (and probably others!) so I'll leave it up to them to get the text up to date. a From a.janke at gmail.com Thu Nov 17 11:51:01 2011 From: a.janke at gmail.com (Andrew Janke) Date: Fri, 18 Nov 2011 02:51:01 +1000 Subject: [MINC-users] autocrop/MincUtilties and step precision In-Reply-To: References: Message-ID: Hi Alex, > I have stumbled on something I might consider a bug in autocrop; > although it is somewhat intricate. It turns out that if one uses the > 'v' specification to for instance expand a volume with a certain > number of voxels, like so: > > ? autocrop -isoexpand 1v > > the actual expansion may be 2 voxels instead of one. Hrm. > ? $count[$i] = round ($extent->[$i] / $step->[$i] - 1e-6, 1, +1); > > thus leaving a tiny bit of slack for precision trouble To me this seems like an issue with how mincinfo handles values internally. > PS Re: precision: > > $ minc_modify_header -dinsert zspace:step=0.006 test.mnc > $ mincinfo -attvalue zspace:step test.mnc > 0.0060000000000000001249 > > I assume this reflects the inherent precision of the variable storage > in... HDF5? This seems to be the same problem as the autocrop issue. I'll punt that autocrop uses mincinfo internally. Certainly it makes no difference if the file is netcdf or HDF5 using your test case. The internal value certainly is 0.006: mincreshape -dimrange zspace=0,1 \ -dimrange yspace=0,1 -dimrange xspace=0,1 \ test.mnc smaller.mnc h5dump smaller.mnc | grep 06 (0): 0.006 So to me the change needs to be in mincinfo? a From zijdenbos at gmail.com Thu Nov 17 12:22:09 2011 From: zijdenbos at gmail.com (Alex Zijdenbos) Date: Thu, 17 Nov 2011 12:22:09 -0500 Subject: [MINC-users] autocrop/MincUtilties and step precision In-Reply-To: References: Message-ID: Hi Andrew, Yes I agree. Many scripted tools use 'mincinfo -attvalue' for getting at parameters, so if (in this case) mincinfo reports 0.0060000000000000001249 while hd5dump reports 0.06 exactly, I would say the problem is with mincinfo. Of course a 1e-20 precision is hardly sensical for most applications, but clearly when you start to do math with these values it can still bite you. Would it make sense to limit the precision with which mincinfo -attvalue reports output? Either 'hard', or under user control? Equivalent to the -m option to hd5dump perhaps (e.g., something like "mincinfo -fp_format '%.6f' -attvalue xspace:step ...")? -- A On Thu, Nov 17, 2011 at 11:51 AM, Andrew Janke wrote: > Hi Alex, > >> I have stumbled on something I might consider a bug in autocrop; >> although it is somewhat intricate. It turns out that if one uses the >> 'v' specification to for instance expand a volume with a certain >> number of voxels, like so: >> >> ? autocrop -isoexpand 1v >> >> the actual expansion may be 2 voxels instead of one. > > Hrm. > >> ? $count[$i] = round ($extent->[$i] / $step->[$i] - 1e-6, 1, +1); >> >> thus leaving a tiny bit of slack for precision trouble > > To me this seems like an issue with how mincinfo handles values internally. > >> PS Re: precision: >> >> $ minc_modify_header -dinsert zspace:step=0.006 test.mnc >> $ mincinfo -attvalue zspace:step test.mnc >> 0.0060000000000000001249 >> >> I assume this reflects the inherent precision of the variable storage >> in... HDF5? > > This seems to be the same problem as the autocrop issue. I'll punt > that autocrop uses mincinfo internally. ?Certainly it makes no > difference if the file is netcdf or HDF5 using your test case. ?The > internal value certainly is 0.006: > > ? mincreshape -dimrange zspace=0,1 \ > ? ? ?-dimrange yspace=0,1 -dimrange xspace=0,1 \ > ? ? ?test.mnc smaller.mnc > > ? h5dump smaller.mnc | grep 06 > ? ? ? ? ? ? ? ? ?(0): 0.006 > > > So to me the change needs to be in mincinfo? > > > a > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > >