From schwarzd@feec.vutbr.cz Mon Nov 1 04:03:04 2004 From: schwarzd@feec.vutbr.cz (Daniel Schwarz) Date: Mon Nov 1 04:03:04 2004 Subject: [MINC-users] mritotal results depend on the filetype? In-Reply-To: References: <417903BC.6020107@feec.vutbr.cz> Message-ID: <4185FB8E.8090704@feec.vutbr.cz> Yes, I use mincreshape for converting the file between the different data types. I was very confused, because of big differencies between resulting transformations. The big differencies occured when the volume was cropped too much (I did some mistakes in cropping - my fault) and the registration process was therefore unsuccessful. Now, my data are getting registered well. There are still some differencies in resulting transformations (depending on the data type), but there are very small and unimportant, I guess... Daniel Schwarz Andrew Janke napsal(a): > On Fri, 22 Oct 2004, Daniel Schwarz wrote: > >> I am getting different results from mritotal when trying to register >> the same image. The results differs when I change data type from >> signed short to unsigned byte. >> I tried it with XCORR and MI too. In the both cases I am getting 2 >> different transformations for byte and int inputs (2 different >> results for the same objective function and the same input image, >> only the depths are different.). Isn't it a bug? >> In the case of INT data, mritotal is displaying info "source volume >> not UNSIGNED_BYTE, will do conversion now"....so why there are >> different results if I do the conversion before the registration >> process starts? >> >> I use mni_autoreg-0.98r (I got different results with 0.98d too). >> My images are short int with range 0..4095. >> I use default model average_305.mnc and I haven't changed anything in >> the mritotal. > > > Daniel, > > Without looking at the data, one of the guesses I would be making is > that the threshold seelction is getting confused with the changes in > datatype. How are you converting the file between the different data > types? with mincreshape? > > > -- > Andrew Janke (andrew_janke@iinet.net DOT au || > www.cmr.uq.edu.au/~rotor) Australia->Brisbane H: +61 7 3390 > 6332 || M: +61 4 2138 8581 From schwarzd@feec.vutbr.cz Tue Nov 2 08:02:05 2004 From: schwarzd@feec.vutbr.cz (Daniel Schwarz) Date: Tue Nov 2 08:02:05 2004 Subject: [MINC-users] other models Message-ID: <4187850B.5030102@feec.vutbr.cz> Dear minc users, if I want to register my data with another model than the average_305, what steps do I have to do? I downloaded ICBM_template.mnc and ran the script make_model, which crashed due to missing mask file for this template. Do I have to create the mask file for ICBM_template (or any others) or is it somewhere available? I guess I will also need the headmask for later nonlinear registration... Thanx for any feedback. Daniel Schwarz From yves.roy@umontreal.ca Fri Nov 5 12:29:05 2004 From: yves.roy@umontreal.ca (Roy Yves) Date: Fri Nov 5 12:29:05 2004 Subject: [MINC-users] REPRIC fMRI Courses and Workshops - Registration now ! Message-ID: Dear BIC-users: REPRIC COURSES AND WORKSHOPS ON fMRI - January 6, 7, 8 2005 ====================================================== It is time to register for the REPRIC courses and workshops on fMRI data analysis. The courses and workshops will take place on January 6, 7, 8 2005 (details to be given to you shortly). Since places are limited, you are asked to register as soon as possible (for the courses, workshops and for the lunch) using the form on the REPRIC web site: http://www.rsmnq.ca/repric/en/repric_fmri_workshops.htm There is no registration fee (event sponsored by the REPRIC) but a contribution (<$10 per meal) will be asked for the lunch on the site. For more information, please contact: irmf-repric@psy.umontreal.ca. Organisers: Pascal Belin (U. Montreal) et Jorge Armony (McGill) Coordination REPRIC: Yves Roy From yves.roy@umontreal.ca Mon Nov 8 00:27:05 2004 From: yves.roy@umontreal.ca (Roy Yves) Date: Mon Nov 8 00:27:05 2004 Subject: [MINC-users] REPRIC Workshops DTI ***Last day to register*** Message-ID: Dear BIC and MINC users: This is the **last day** to register for the REPRIC Workshop on Diffusion Tensor Imaging (DTI) to be held on November 12 2004 from 8 AM to 5 PM at the Montreal Neurological Institute, Jeanne Timmins Amphitheatre. Register using the online form on the REPRIC web site: http://www.rsmnq.ca/repric/en/repric_dti_workshop.htm In order to help us plan the event, we would also like to know if you will eat lunch and /or attend the cocktail at the end of the day. For more information, please contact Mariève Potvin: marieve.potvin@umontreal.ca. You are all welcome ! _________________________________ There will be 4 invited speakers: Peter Basser (National Institute of Child Health and Human Development NICHD/NIH) Susumu Mori (John Hopkins University) David Tuch (Martinos Center for Biomedical Imaging, Masachusetts General Hospital) Michael Zwanger (SIEMENS AG, Allemagne) A 1-day course on "how it works". From mhough@fmrib.ox.ac.uk Tue Nov 9 04:27:05 2004 From: mhough@fmrib.ox.ac.uk (Morgan Hough) Date: Tue Nov 9 04:27:05 2004 Subject: [MINC-users] Reference request Message-ID: <1099992008.4301.11.camel@dhania.fmrib.ox.ac.uk> I hope this isn't too off topic but I was wondering what reference(s) describe the creation of the MNI 152 average datasets. The website cites the 2001 ICBM paper because, I think, it was adopted by ICBM but the paper itself does not describe details of its construction. Thanks in advance. Cheers, -Morgan -- Morgan Hough DPhil student FMRIB, John Radcliffe Hospital, Headington, Oxford OX3 9DU, UK mhough@fmrib.ox.ac.uk www.fmrib.ox.ac.uk/~mhough tel +44 (0) 1865 222545 fax +44 (0) 1865 222717 From yves.roy@umontreal.ca Tue Nov 9 15:17:04 2004 From: yves.roy@umontreal.ca (Roy Yves) Date: Tue Nov 9 15:17:04 2004 Subject: [MINC-users] De-mozaicise a 4D minc file Message-ID: Hi: I have a 4D minc file in mosaic format (i.e. all slices shown in the same plan). How can I demozaicise it (which minc tool and how to use it)? Thanks Yves From andrew_janke@iinet.net.au Tue Nov 9 17:19:05 2004 From: andrew_janke@iinet.net.au (Andrew Janke) Date: Tue Nov 9 17:19:05 2004 Subject: [MINC-users] De-mozaicise a 4D minc file In-Reply-To: References: Message-ID: On Tue, 9 Nov 2004, Roy Yves wrote: > I have a 4D minc file in mosaic format (i.e. all slices shown in the same plan). > > How can I demozaicise it (which minc tool and how to use it)? The easiest solution would be (Assuming you have the original dicom images and they are from a siemens) would be to use siemens_mosaic2mnc. Thiss will then ensure that the original positioning information is retained. However if you don't have access to this, then you could just pinch the central bit of this perl script that makes a number of calls to mincreshape and mincconcat. If you don't have the original dicom data, reply to this and I'll write a quick script for you to do this. (but you will have to manually input the number of mosaic frames.) -- Andrew Janke (andrew_janke@iinet.net DOT au || www.cmr.uq.edu.au/~rotor) Australia->Brisbane H: +61 7 3390 6332 || M: +61 4 2138 8581 From andrew_janke@iinet.net.au Tue Nov 9 17:21:06 2004 From: andrew_janke@iinet.net.au (Andrew Janke) Date: Tue Nov 9 17:21:06 2004 Subject: [MINC-users] other models In-Reply-To: <4187850B.5030102@feec.vutbr.cz> References: <4187850B.5030102@feec.vutbr.cz> Message-ID: On Tue, 2 Nov 2004, Daniel Schwarz wrote: > if I want to register my data with another model than the average_305, what > steps do I have to do? > I downloaded ICBM_template.mnc and ran the script make_model, which crashed > due to missing mask file for this template. Do I have to create the mask file > for ICBM_template (or any others) or is it somewhere available? I guess I > will also need the headmask for later nonlinear registration... the make_model script requires two masks. a cortex mask (_mask.mnc) and a headmask for possible non-linear fitting (_headmask.mnc>). You should be able to mincresample the average_305 masks for your purposes as these two models are essentially in the same space albeit with different sampling. -- Andrew Janke (andrew_janke@iinet.net DOT au || www.cmr.uq.edu.au/~rotor) Australia->Brisbane H: +61 7 3390 6332 || M: +61 4 2138 8581 From andrew_janke@iinet.net.au Tue Nov 9 17:23:04 2004 From: andrew_janke@iinet.net.au (Andrew Janke) Date: Tue Nov 9 17:23:04 2004 Subject: [MINC-users] Reference request In-Reply-To: <1099992008.4301.11.camel@dhania.fmrib.ox.ac.uk> References: <1099992008.4301.11.camel@dhania.fmrib.ox.ac.uk> Message-ID: On Tue, 9 Nov 2004, Morgan Hough wrote: > I hope this isn't too off topic but I was wondering what reference(s) > describe the creation of the MNI 152 average datasets. The website cites > the 2001 ICBM paper because, I think, it was adopted by ICBM but the > paper itself does not describe details of its construction. Thanks in > advance. You could always look at the original 305 paper, the procedure was (to my knowledge) identical to what was used for the icbm 152. Evans AC, Collins DL, Mills SR, Brown ED, Kelly RL, Peters TM. 3D statistical neuroanatomical models from 305 MRI volumes. Proceedings of the IEEE-Nuclear Science Symposium and Medical Imaging Conference. 1993;1813-1817. -- Andrew Janke (andrew_janke@iinet.net DOT au || www.cmr.uq.edu.au/~rotor) Australia->Brisbane H: +61 7 3390 6332 || M: +61 4 2138 8581 From andrew_janke@iinet.net.au Tue Nov 9 17:25:04 2004 From: andrew_janke@iinet.net.au (Andrew Janke) Date: Tue Nov 9 17:25:04 2004 Subject: [MINC-users] mritotal results depend on the filetype? In-Reply-To: <4185FB8E.8090704@feec.vutbr.cz> References: <417903BC.6020107@feec.vutbr.cz> <4185FB8E.8090704@feec.vutbr.cz> Message-ID: On Mon, 1 Nov 2004, Daniel Schwarz wrote: > Yes, I use mincreshape for converting the file between the different data > types. > I was very confused, because of big differencies between resulting > transformations. The big differencies occured when the volume was cropped too > much (I did some mistakes in cropping - my fault) and the registration > process was therefore unsuccessful. > Now, my data are getting registered well. There are still some differencies > in resulting transformations (depending on the data type), but there are very > small and unimportant, I guess... >From a closer look at the code, during the mutual information registration, louis does a fairly explicit cast so there may be a small problem here. However as you say, the differences are minor. Do you happen to know if the same small differences occur when using xcorr? I'd be suprised/worried if they do... :) -- Andrew Janke (andrew_janke@iinet.net DOT au || www.cmr.uq.edu.au/~rotor) Australia->Brisbane H: +61 7 3390 6332 || M: +61 4 2138 8581 From m.audette@aist.go.jp Wed Nov 10 01:42:06 2004 From: m.audette@aist.go.jp (Michel Audette) Date: Wed Nov 10 01:42:06 2004 Subject: [MINC-users] voxel_loop-like hard-disk access for arbitrary voxel positions Message-ID: <003301c4c7b8$31f92d20$07751d96@surgsim5> Hi everyone, I had the following question for Peter Neelin, and he suggested I put it to this group. Are you familiar with Level-set and Fast Marching Level-Set surface models? Basically, it involves an evolving front, and I'm trying to figure out a way to implement something like this with voxel_loop-like management (i.e.: use as little RAM as possible). In other words, it does not process the whole volume at once, but iterates an evolving surface based on a moving shell surrounding the surface at the previous simulated time iteration. Wondering if this is feasible under MINC, in a manner comparable to voxel_loop... In other words, I need to be able to access specific voxels of a given volume on disk.... Can anyone comment? I need to process MR volumes that have been resampled to CT-density, actually greater than normal CT-density, in the sense that I first resample CT data to be isotropic, typically .5mm resolution, and do the same for MR. I need to do this with a 32-bit Linux machine, hence the problem. Michel Michel Audette, Ph.D., Research Fellow, Surgical Simulation, Surgical Assist Group, AIST, Namiki 1-2, Tsukuba, Japan, 305-8564 From schwarzd@feec.vutbr.cz Thu Nov 11 05:36:03 2004 From: schwarzd@feec.vutbr.cz (Daniel Schwarz) Date: Thu Nov 11 05:36:03 2004 Subject: [MINC-users] other models In-Reply-To: References: <4187850B.5030102@feec.vutbr.cz> Message-ID: <41934055.3020901@feec.vutbr.cz> Thank you for your reply. I used the average_305 masks, but did not the resampling as I guess that the world coordinates stay the same. ...or am I wrong? Daniel Schwarz Andrew Janke napsal(a): > On Tue, 2 Nov 2004, Daniel Schwarz wrote: > >> if I want to register my data with another model than the >> average_305, what steps do I have to do? >> I downloaded ICBM_template.mnc and ran the script make_model, which >> crashed due to missing mask file for this template. Do I have to >> create the mask file for ICBM_template (or any others) or is it >> somewhere available? I guess I will also need the headmask for later >> nonlinear registration... > > > the make_model script requires two masks. a cortex mask > (_mask.mnc) and a headmask for possible non-linear fitting > (_headmask.mnc>). > > You should be able to mincresample the average_305 masks for your > purposes as these two models are essentially in the same space albeit > with different sampling. > > > -- > Andrew Janke (andrew_janke@iinet.net DOT au || > www.cmr.uq.edu.au/~rotor) Australia->Brisbane H: +61 7 3390 > 6332 || M: +61 4 2138 8581 > _______________________________________________ > MINC-users@bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users From andrew_janke@iinet.net.au Thu Nov 11 08:30:04 2004 From: andrew_janke@iinet.net.au (Andrew Janke) Date: Thu Nov 11 08:30:04 2004 Subject: [MINC-users] other models In-Reply-To: <41934055.3020901@feec.vutbr.cz> References: <4187850B.5030102@feec.vutbr.cz> <41934055.3020901@feec.vutbr.cz> Message-ID: You will need to resample the masks to the icbm space. ie: mincresample -like average_305_mask.mnc icbm_model_mask.mnc a On Thu, 11 Nov 2004, Daniel Schwarz wrote: > I used the average_305 masks, but did not the resampling as I guess that the > world coordinates stay the same. ...or am I wrong? > > Daniel Schwarz > > > Andrew Janke napsal(a): > >> On Tue, 2 Nov 2004, Daniel Schwarz wrote: >> >>> if I want to register my data with another model than the average_305, >>> what steps do I have to do? >>> I downloaded ICBM_template.mnc and ran the script make_model, which >>> crashed due to missing mask file for this template. Do I have to create >>> the mask file for ICBM_template (or any others) or is it somewhere >>> available? I guess I will also need the headmask for later nonlinear >>> registration... >> >> >> the make_model script requires two masks. a cortex mask (_mask.mnc) >> and a headmask for possible non-linear fitting (_headmask.mnc>). >> >> You should be able to mincresample the average_305 masks for your purposes >> as these two models are essentially in the same space albeit with different >> sampling. >> >> >> -- >> Andrew Janke (andrew_janke@iinet.net DOT au || www.cmr.uq.edu.au/~rotor) >> Australia->Brisbane H: +61 7 3390 6332 || M: +61 4 2138 8581 >> _______________________________________________ >> MINC-users@bic.mni.mcgill.ca >> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > > > -- Andrew Janke (andrew_janke@iinet.net DOT au || www.cmr.uq.edu.au/~rotor) Australia->Brisbane H: +61 7 3390 6332 || M: +61 4 2138 8581 From schwarzd@feec.vutbr.cz Fri Nov 12 08:08:04 2004 From: schwarzd@feec.vutbr.cz (Daniel Schwarz) Date: Fri Nov 12 08:08:04 2004 Subject: [MINC-users] troubles with mincmakescalar Message-ID: <4194B586.3050108@feec.vutbr.cz> Dear minc users, My mincmakescalar does not seem to work properly. I wanted to use it to split vector image (result of mritotal -nonlinear) into 3 scalar images (step by step). Result of mincmakescalar is again a vector image...:-( [schwarzd@localhost Experiment]$ mincinfo A2.nonlinear_grid_0.mnc file: A2.nonlinear_grid_0.mnc image: signed__ short -32766 to 32766 image dimensions: vector_dimension zspace yspace xspace dimension name length step start -------------- ------ ---- ----- vector_dimension 3 unknown unknown zspace 18 4 -1 yspace 20 4 5 xspace 20 4 3 [schwarzd@localhost Experiment]$ [schwarzd@localhost Experiment]$ mincmakescalar -linear 1,0,0 A2.nonlinear_grid_0.mnc test.mnc Processing:......................................................Done [schwarzd@localhost Experiment]$ mincinfo test.mnc file: test.mnc image: signed__ short -32766 to 32766 image dimensions: vector_dimension zspace yspace xspace dimension name length step start -------------- ------ ---- ----- vector_dimension 3 unknown unknown zspace 18 4 -1 yspace 20 4 5 xspace 20 4 3 ....I have minc-1.3... Thanks in advance for any reply (somebody might know how to split the vector image into three components in another way).... Daniel Schwarz From jason@bic.mni.mcgill.ca Fri Nov 12 09:44:04 2004 From: jason@bic.mni.mcgill.ca (Jason Lerch) Date: Fri Nov 12 09:44:04 2004 Subject: [MINC-users] troubles with mincmakescalar In-Reply-To: <4194B586.3050108@feec.vutbr.cz> References: <4194B586.3050108@feec.vutbr.cz> Message-ID: <31B27449-34B9-11D9-A6C9-000A95DBBFD8@bic.mni.mcgill.ca> Hi Daniel, if you just want to extract the individual components of the vector the program mincreshape ought to do the trick for you. Something like: mincreshape -clobber -start 0,0,0,0 -count 0,100,128,112 old.mnc new_dim0.mnc mincreshape -clobber -start 1,0,0,0 -count 0,100,128,112 old.mnc new_dim1.mnc mincreshape -clobber -start 2,0,0,0 -count 0,100,128,112 old.mnc new_dim2.mnc Somebody correct me if I'm wrong here ... Jason On Nov 12, 2004, at 8:07 AM, Daniel Schwarz wrote: > Dear minc users, > > My mincmakescalar does not seem to work properly. I wanted to use it > to split vector image (result of mritotal -nonlinear) into 3 scalar > images (step by step). Result of mincmakescalar is again a vector > image...:-( > > [schwarzd@localhost Experiment]$ mincinfo A2.nonlinear_grid_0.mnc > file: A2.nonlinear_grid_0.mnc > image: signed__ short -32766 to 32766 > image dimensions: vector_dimension zspace yspace xspace > dimension name length step start > -------------- ------ ---- ----- > vector_dimension 3 unknown unknown > zspace 18 4 -1 > yspace 20 4 5 > xspace 20 4 3 > [schwarzd@localhost Experiment]$ > [schwarzd@localhost Experiment]$ mincmakescalar -linear 1,0,0 > A2.nonlinear_grid_0.mnc test.mnc > Processing:......................................................Done > [schwarzd@localhost Experiment]$ mincinfo test.mnc > file: test.mnc > image: signed__ short -32766 to 32766 > image dimensions: vector_dimension zspace yspace xspace > dimension name length step start > -------------- ------ ---- ----- > vector_dimension 3 unknown unknown > zspace 18 4 -1 > yspace 20 4 5 > xspace 20 4 3 > > ....I have minc-1.3... > Thanks in advance for any reply (somebody might know how to split the > vector image into three components in another way).... > > Daniel Schwarz > > _______________________________________________ > MINC-users@bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users From bert@bic.mni.mcgill.ca Fri Nov 12 10:35:04 2004 From: bert@bic.mni.mcgill.ca (Robert VINCENT) Date: Fri Nov 12 10:35:04 2004 Subject: [MINC-users] troubles with mincmakescalar In-Reply-To: <4194B586.3050108@feec.vutbr.cz> Message-ID: Daniel, Thanks for the report. I believe that you've found a limitation (bug) of the mincmakescalar program. What you attempted appears to work only if the vector_dimension is the fastest-varying dimension in the file. Jason's suggestion appears to work properly. Alternatively, you can reorder the dimensions once with mincreshape: mincreshape -dimorder zspace,yspace,xspace,vector_dimension in.mnc out.mnc After doing this, mincmakescalar should work as you expect. I'll look into fixing mincmakescalar for the next release... -bert On Fri, 12 Nov 2004, Daniel Schwarz wrote: > Dear minc users, > > My mincmakescalar does not seem to work properly. I wanted to use it to > split vector image (result of mritotal -nonlinear) into 3 scalar images > (step by step). Result of mincmakescalar is again a vector image...:-( > > [schwarzd@localhost Experiment]$ mincinfo A2.nonlinear_grid_0.mnc > file: A2.nonlinear_grid_0.mnc > image: signed__ short -32766 to 32766 > image dimensions: vector_dimension zspace yspace xspace > dimension name length step start > -------------- ------ ---- ----- > vector_dimension 3 unknown unknown > zspace 18 4 -1 > yspace 20 4 5 > xspace 20 4 3 > [schwarzd@localhost Experiment]$ > [schwarzd@localhost Experiment]$ mincmakescalar -linear 1,0,0 > A2.nonlinear_grid_0.mnc test.mnc > Processing:......................................................Done > [schwarzd@localhost Experiment]$ mincinfo test.mnc > file: test.mnc > image: signed__ short -32766 to 32766 > image dimensions: vector_dimension zspace yspace xspace > dimension name length step start > -------------- ------ ---- ----- > vector_dimension 3 unknown unknown > zspace 18 4 -1 > yspace 20 4 5 > xspace 20 4 3 > > ....I have minc-1.3... > Thanks in advance for any reply (somebody might know how to split the > vector image into three components in another way).... > > Daniel Schwarz > > _______________________________________________ > MINC-users@bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > From tosa@nmr.mgh.harvard.edu Fri Nov 12 15:02:04 2004 From: tosa@nmr.mgh.harvard.edu (Yasunari Tosa) Date: Fri Nov 12 15:02:04 2004 Subject: [MINC-users] mincmath problem under minc-1.2 and minc-1.3 Message-ID: <419516A3.4040404@nmr.mgh.harvard.edu> Hi, I'm having problems with N3-1.09 "make check", failing at #14. Today I finally chased the problem to "mincmath" for both minc-1.2 and minc-1.3 source build on SuSE 9.1 and RHEL. This does not occur for RH9 build. Here is the routine "nu_estimate_np_and_em" does (I just removed /usr/tmp/... from filenames): $ mincmath -clobber -verbose -short -signed -and ./chunk_mask.mnc ./chunk_bkg.mnc ./chunk_mask.mnc where chunk_mask.mnc becomes single colored (under register). When I change the output file to something else(not the same filename), then it works fine. I tried compiling under -g, but mincmath problem stayed. Have you seen anything like this? Thank you. Tosa -- Yasunari Tosa, Ph.D. Email: tosa@nmr.mgh.harvard.edu NMR Ctr, Mass. General Hospital TEL: 617-726-4050 Building 149, 13th Street Charlestown, MA 02129 USA From bert@bic.mni.mcgill.ca Fri Nov 12 16:42:03 2004 From: bert@bic.mni.mcgill.ca (Robert VINCENT) Date: Fri Nov 12 16:42:03 2004 Subject: [MINC-users] mincmath problem under minc-1.2 and minc-1.3 In-Reply-To: <419516A3.4040404@nmr.mgh.harvard.edu> Message-ID: Hi Tosa, This may not be the issue, but can you check the version of netCDF that is installed on these systems? If you type: ncdump -X The last line printed should include the netcdf library version. -bert On Fri, 12 Nov 2004, Yasunari Tosa wrote: > Hi, > > I'm having problems with N3-1.09 "make check", failing at #14. > > Today I finally chased the problem to "mincmath" for both minc-1.2 and > minc-1.3 > source build on SuSE 9.1 and RHEL. This does not occur for RH9 build. > > Here is the routine "nu_estimate_np_and_em" does (I just removed > /usr/tmp/... from filenames): > > $ mincmath -clobber -verbose -short -signed -and ./chunk_mask.mnc > ./chunk_bkg.mnc ./chunk_mask.mnc > > where chunk_mask.mnc becomes single colored (under register). > When I change the output file to something else(not the same filename), > then it works fine. > > I tried compiling under -g, but mincmath problem stayed. > > Have you seen anything like this? > > Thank you. > > Tosa > > -- > Yasunari Tosa, Ph.D. Email: tosa@nmr.mgh.harvard.edu > NMR Ctr, Mass. General Hospital TEL: 617-726-4050 > Building 149, 13th Street > Charlestown, MA 02129 > USA > > _______________________________________________ > MINC-users@bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > From Peter Neelin Mon Nov 15 08:39:07 2004 From: Peter Neelin (Peter Neelin) Date: Mon Nov 15 08:39:07 2004 Subject: [MINC-users] troubles with mincmakescalar In-Reply-To: References: <4194B586.3050108@feec.vutbr.cz> Message-ID: On Fri, 12 Nov 2004 10:34:59 -0500, Robert VINCENT wrote: > > Thanks for the report. I believe that you've found a limitation (bug) of > the mincmakescalar program. What you attempted appears to work only if > the vector_dimension is the fastest-varying dimension in the file. In the original definition of minc (I don't know if that has changed now), only files having vector_dimension as the fastest-varying dimension are considered vector datasets (in other words, it is not a bug, but rather by design). All of the generic tools handle files in this way (or they did), particularly since voxel_loop treats files in this manner. Some poorly behaved applications write out files in reverse order, causing this confusion (volume_io tends to be fairly liberal about dimension ordering which may help give rise to these situations). If the minc maintainers want to change this, then they should review all of the tools in the core package, as well as the library, since the assumption of adherence to this convention is quite widespread. Peter From redwing21trident@hotmail.com Mon Nov 15 08:41:02 2004 From: redwing21trident@hotmail.com (Christopher) Date: Mon Nov 15 08:41:02 2004 Subject: [MINC-users] Cailis for cheap! Message-ID: <1100345787-2056@excite.com>

Generíc Cíalís, at cheap príces.

Most places charge $20, we charge $5.
Quíte a dífference.

Cíalís ís known as a Super-Víagra or
Weekend-Víagra because íts effects
start sooner and last much longer.

Shípped worldwíde.

Your easy-to-use solutíon ís here:







REM0VE tequila dirkfireball wolverin volley redrum warriorstina malcolm tina wright guess kramer dgj sylvie hello1 qwerty12 cobrazeppelin sbdc church dickhead butch jared caesar futurebird khan volley october fugazisarah1 cookies pirate raptor johnson wanker From bert@bic.mni.mcgill.ca Mon Nov 15 08:53:04 2004 From: bert@bic.mni.mcgill.ca (Robert VINCENT) Date: Mon Nov 15 08:53:04 2004 Subject: [MINC-users] troubles with mincmakescalar In-Reply-To: Message-ID: Hi Peter, Thanks for the note. I've noticed the discrepancy between the MINC specifications and some of the tools with respect to vector_dimension position. I think the main issue from my perspective is that mincmakescalar fails without informing the user that it can't handle the input file. So the solution may just be to add a helpful message! -bert On Fri, 12 Nov 2004, Peter Neelin wrote: > On Fri, 12 Nov 2004 10:34:59 -0500, Robert VINCENT > wrote: > > > > Thanks for the report. I believe that you've found a limitation (bug) of > > the mincmakescalar program. What you attempted appears to work only if > > the vector_dimension is the fastest-varying dimension in the file. > > In the original definition of minc (I don't know if that has changed > now), only files having vector_dimension as the fastest-varying > dimension are considered vector datasets (in other words, it is not a > bug, but rather by design). All of the generic tools handle files in > this way (or they did), particularly since voxel_loop treats files in > this manner. Some poorly behaved applications write out files in > reverse order, causing this confusion (volume_io tends to be fairly > liberal about dimension ordering which may help give rise to these > situations). > > If the minc maintainers want to change this, then they should review > all of the tools in the core package, as well as the library, since > the assumption of adherence to this convention is quite widespread. > > Peter > _______________________________________________ > MINC-users@bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > From dwagne@bic.mni.mcgill.ca Mon Nov 15 21:36:03 2004 From: dwagne@bic.mni.mcgill.ca (Dylan WAGNER) Date: Mon Nov 15 21:36:03 2004 Subject: [MINC-users] Mincextract to get voxel values and coordinates? Message-ID: Hi all, I'm trying to get a table of voxel values and coordinates above a certain threshold. Which tool would be most appropriate for this? find_peaks with the distance set to 0 still doesn't give me every single voxel (I know this because mincstats tells me I have 11,000 voxels above threshold and find_pos only gives me about 90). Mincextract seems like it could do the job, but I'm not entirely sure how to wield it. In particular, where/how would I set a threshold? Lastly, where is mincbet? It's listed in the wiki. Seems useful. Thanks, From jason@bic.mni.mcgill.ca Mon Nov 15 22:20:04 2004 From: jason@bic.mni.mcgill.ca (Jason Lerch) Date: Mon Nov 15 22:20:04 2004 Subject: [MINC-users] Mincextract to get voxel values and coordinates? In-Reply-To: References: Message-ID: <3B6420C6-377E-11D9-A6C9-000A95DBBFD8@bic.mni.mcgill.ca> On Nov 15, 2004, at 9:35 PM, Dylan WAGNER wrote: > > > Hi all, > > I'm trying to get a table of voxel values and coordinates above a > certain threshold. Which tool would be most appropriate for this? > > find_peaks with the distance set to 0 still doesn't give me every > single > voxel (I know this because mincstats tells me I have 11,000 voxels > above > threshold and find_pos only gives me about 90). Try: minctotag input.mnc output.tag min_threshold max_threshold The coordinates will be world coordinates. It should be very straightforward to turn the tags into a table (it's a text file). > > Mincextract seems like it could do the job, but I'm not entirely > sure > how to wield it. In particular, where/how would I set a threshold? > > Lastly, where is mincbet? It's listed in the wiki. Seems useful. ~rotor/opt/irix_bin/mincbet (Andrew, this might be a hint to move it to a more convenient place ;-)) Jason > > Thanks, > > > > _______________________________________________ > MINC-users@bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users From schwarzd@feec.vutbr.cz Tue Nov 16 09:00:04 2004 From: schwarzd@feec.vutbr.cz (Daniel Schwarz) Date: Tue Nov 16 09:00:04 2004 Subject: [MINC-users] looking for more atlases Message-ID: <419A07CD.7010908@feec.vutbr.cz> Dear minc users, playing with mritotal linear and nonlinear, I would like to try my data with more atlases. So far I have tried - average_305.mnc (for which I have no label volume), - ICBM_single-subject-0.5mm (for which the label volume is available) and the brainweb_phantom_1mm (for which the tissue classes are available). I am looking for more atlases with the anatomical labels. There's a lot of posts concerning the ICBM_template_152 here. Is it available anywhere? I have looked for it unsuccessfully... Thank you for any replies/suggestions... Daniel Schwarz From andrew_janke@iinet.net.au Tue Nov 16 09:26:04 2004 From: andrew_janke@iinet.net.au (Andrew Janke) Date: Tue Nov 16 09:26:04 2004 Subject: [MINC-users] looking for more atlases In-Reply-To: <419A07CD.7010908@feec.vutbr.cz> References: <419A07CD.7010908@feec.vutbr.cz> Message-ID: On Tue, 16 Nov 2004, Daniel Schwarz wrote: > playing with mritotal linear and nonlinear, I would like to try my data with > more atlases. So far I have tried > - average_305.mnc (for which I have no label volume), > - ICBM_single-subject-0.5mm (for which the label volume is available) > and the brainweb_phantom_1mm (for which the tissue classes are available). > > I am looking for more atlases with the anatomical labels. There's a lot of > posts concerning the ICBM_template_152 here. Is it available anywhere? I have > looked for it unsuccessfully... A long time ago (and to this day I see) you could get the ICBM template from here: ftp://ftp.bic.mni.mcgill.ca/pub/avgbrain/ -- Andrew Janke (andrew_janke@iinet.net DOT au || www.cmr.uq.edu.au/~rotor) Australia->Brisbane H: +61 7 3390 6332 || M: +61 4 2138 8581 From andrew_janke@iinet.net.au Tue Nov 16 09:30:04 2004 From: andrew_janke@iinet.net.au (Andrew Janke) Date: Tue Nov 16 09:30:04 2004 Subject: [MINC-users] Mincextract to get voxel values and coordinates? In-Reply-To: <3B6420C6-377E-11D9-A6C9-000A95DBBFD8@bic.mni.mcgill.ca> References: <3B6420C6-377E-11D9-A6C9-000A95DBBFD8@bic.mni.mcgill.ca> Message-ID: On Mon, 15 Nov 2004, Jason Lerch wrote: >> Lastly, where is mincbet? It's listed in the wiki. Seems useful. > > ~rotor/opt/irix_bin/mincbet > > (Andrew, this might be a hint to move it to a more convenient place ;-)) Well on this one I am of two minds. Do I: a) update my version of the I/O module of FSL so that MINC just "works" in FSL or b) Write a more complte stand alone mincbet by just using the approriate bits of bet. I _like_ (a), but this could introduce a world of headaches (more AFNI-ANALYZE-NIFTI-MINC conversion/orientation problems). Does anyone else out there wish to cast their vote? I have a working version of a) for a previous version of FSL. I don't see why it would work with the new version but haven't checked. -- Andrew Janke (andrew_janke@iinet.net DOT au || www.cmr.uq.edu.au/~rotor) Australia->Brisbane H: +61 7 3390 6332 || M: +61 4 2138 8581 From sridar@mrs.mni.mcgill.ca Tue Nov 16 13:32:04 2004 From: sridar@mrs.mni.mcgill.ca (Sridar Narayanan) Date: Tue Nov 16 13:32:04 2004 Subject: [MINC-users] FSL and MINC In-Reply-To: <200411161701.iAGH15bK4991708@shadow.bic.mni.mcgill.ca> Message-ID: > > On Mon, 15 Nov 2004, Jason Lerch wrote: > >>> Lastly, where is mincbet? It's listed in the wiki. Seems useful. >> >> ~rotor/opt/irix_bin/mincbet >> >> (Andrew, this might be a hint to move it to a more convenient place ;-)) > > Well on this one I am of two minds. > > Do I: > > a) update my version of the I/O module of FSL so that MINC just "works" > in FSL > > or > > b) Write a more complte stand alone mincbet by just using the approriate > bits of bet. > > I _like_ (a), but this could introduce a world of headaches (more > AFNI-ANALYZE-NIFTI-MINC conversion/orientation problems). > > Does anyone else out there wish to cast their vote? I have a working version > of > a) for a previous version of FSL. I don't see why it would work with the new > version but haven't checked. Andrew, if you can devise a general solution that allows all of FSL (bet, FEAT, SIENA, etc.) to "just work" on MINC files, that would be extremely useful to a number of people in our lab. I suppose the main question is how much effort would it be to stay in sync with new versions of FSL? Also, would you be updating the I/O module of FSL such that the constituent programs could *write" MINC as well as read? Sridar From alex@bic.mni.mcgill.ca Tue Nov 16 14:01:03 2004 From: alex@bic.mni.mcgill.ca (Alex ZIJDENBOS) Date: Tue Nov 16 14:01:03 2004 Subject: [MINC-users] Mincextract to get voxel values and coordinates? In-Reply-To: References: <3B6420C6-377E-11D9-A6C9-000A95DBBFD8@bic.mni.mcgill.ca> Message-ID: <20041116190032.GA5002012@shadow.bic.mni.mcgill.ca> On Wed, Nov 17, 2004 at 12:28:58AM +1000, Andrew Janke wrote: > Do I: > > a) update my version of the I/O module of FSL so that MINC just "works" > in FSL > > or > > b) Write a more complte stand alone mincbet by just using the approriate > bits of bet. > > I _like_ (a), but this could introduce a world of headaches (more > AFNI-ANALYZE-NIFTI-MINC conversion/orientation problems). > > Does anyone else out there wish to cast their vote? I have a working > version of a) for a previous version of FSL. I don't see why it would work > with the new version but haven't checked. Say - if enough MINC users want this, would that convince Steve Smith to add a MINC I/O abilities to FSL?! Seems like that would by far the easiest and most elegant solution? -- Alex From dwagne@bic.mni.mcgill.ca Tue Nov 16 14:10:04 2004 From: dwagne@bic.mni.mcgill.ca (Dylan WAGNER) Date: Tue Nov 16 14:10:04 2004 Subject: [MINC-users] Mincextract to get voxel values and coordinates? In-Reply-To: <3B6420C6-377E-11D9-A6C9-000A95DBBFD8@bic.mni.mcgill.ca> Message-ID: Hi Jason, Thanks for the response. I wasn't aware of minctotag, and after sniffing around, wow there's a lot more minc apps than on the wiki or bic pages alone. I suppose that sounds a bit naive. I stumbled across a list at http://www.bic.mni.mcgill.ca/~stever/software_map.html As I use some of these I'll try and add them to the wiki. A few questions regarding minctotag. So far it works great, however: Voxel intensities are integers? The same minc in register gives me a fair bit more precision. However for my purposes integers are fine, I'm just curious why. Also thank you for the location of mincbet. So now I'm confronted with three choices. Mincbet, skullstrip and the preprocessing method on on the wiki page for VBM. It's a bloody buffet of skullstripping methods! Any reason why one would be better? The method on the VBM seems more tailored to each individual subject, though longer to carry out. Best, DDW From bert@bic.mni.mcgill.ca Tue Nov 16 14:47:04 2004 From: bert@bic.mni.mcgill.ca (Robert VINCENT) Date: Tue Nov 16 14:47:04 2004 Subject: [MINC-users] Mincextract to get voxel values and coordinates? In-Reply-To: Message-ID: Hi Dylan, Hmmm... I took a look at the code, and minctotag rounds the voxel data values before writing them to the tag file. I have no idea why, but that seems to be how the author defined the tag file format. It it becomes a nuisance it would be easy enough to fix, or to offer an alternative through mincextract. -bert On Tue, 16 Nov 2004, Dylan WAGNER wrote: > > > > Hi Jason, > > Thanks for the response. I wasn't aware of minctotag, and after > sniffing around, wow there's a lot more minc apps than on the wiki or bic > pages alone. I suppose that sounds a bit naive. I stumbled across a list > at http://www.bic.mni.mcgill.ca/~stever/software_map.html > As I use some of these I'll try and add them to the wiki. > > A few questions regarding minctotag. > > So far it works great, however: > > Voxel intensities are integers? The same minc in register gives me a > fair bit more precision. However for my purposes integers are fine, I'm > just curious why. > > > Also thank you for the location of mincbet. So now I'm confronted > with three choices. Mincbet, skullstrip and the preprocessing method on > on the wiki page for VBM. It's a bloody buffet of skullstripping methods! > Any reason why one would be better? The method on the VBM seems more > tailored to each individual subject, though longer to carry out. > > Best, > DDW > > > _______________________________________________ > MINC-users@bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > From jason@bic.mni.mcgill.ca Tue Nov 16 15:37:04 2004 From: jason@bic.mni.mcgill.ca (Jason Lerch) Date: Tue Nov 16 15:37:04 2004 Subject: [MINC-users] Mincextract to get voxel values and coordinates? In-Reply-To: References: Message-ID: <3C40309C-380F-11D9-A6C9-000A95DBBFD8@bic.mni.mcgill.ca> On Nov 16, 2004, at 2:46 PM, Robert VINCENT wrote: > Hi Dylan, > > Hmmm... I took a look at the code, and minctotag rounds the voxel data > values before writing them to the tag file. I have no idea why, but > that > seems to be how the author defined the tag file format. The reason is that it expects to work with label volumes. But I suppose adding a switch telling the app whether to round or not might not be too bad an idea. Jason > > It it becomes a nuisance it would be easy enough to fix, or to offer an > alternative through mincextract. > > -bert > > On Tue, 16 Nov 2004, Dylan WAGNER wrote: > >> >> >> >> Hi Jason, >> >> Thanks for the response. I wasn't aware of minctotag, and after >> sniffing around, wow there's a lot more minc apps than on the wiki or >> bic >> pages alone. I suppose that sounds a bit naive. I stumbled across a >> list >> at http://www.bic.mni.mcgill.ca/~stever/software_map.html >> As I use some of these I'll try and add them to the wiki. >> >> A few questions regarding minctotag. >> >> So far it works great, however: >> >> Voxel intensities are integers? The same minc in register gives >> me a >> fair bit more precision. However for my purposes integers are fine, >> I'm >> just curious why. >> >> >> Also thank you for the location of mincbet. So now I'm >> confronted >> with three choices. Mincbet, skullstrip and the preprocessing method >> on >> on the wiki page for VBM. It's a bloody buffet of skullstripping >> methods! >> Any reason why one would be better? The method on the VBM seems more >> tailored to each individual subject, though longer to carry out. >> >> Best, >> DDW >> >> >> _______________________________________________ >> MINC-users@bic.mni.mcgill.ca >> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users >> > > _______________________________________________ > MINC-users@bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users From jason@bic.mni.mcgill.ca Tue Nov 16 15:42:04 2004 From: jason@bic.mni.mcgill.ca (Jason Lerch) Date: Tue Nov 16 15:42:04 2004 Subject: [MINC-users] Mincextract to get voxel values and coordinates? In-Reply-To: References: Message-ID: On Nov 16, 2004, at 2:09 PM, Dylan WAGNER wrote: > > > > Also thank you for the location of mincbet. So now I'm confronted > with three choices. Mincbet, skullstrip and the preprocessing method on > on the wiki page for VBM. It's a bloody buffet of skullstripping > methods! > Any reason why one would be better? The method on the VBM seems more > tailored to each individual subject, though longer to carry out. The basic answer: they all suck. I think that the method on the VBM pages sucks least of the lot, but I know that others disagree. There has never been a study which compared all these methods, though this paper here might help (it does not compare our cortical_surface method that is described in the VBM pages): Boesen K, Rehm K, Schaper K, Stoltzner S, Woods R, Luders E, Rottenberg D. Quantitative comparison of four brain extraction algorithms. Neuroimage. 2004 Jul;22(3):1255-61. Cheers, Jason > Best, > DDW > From thompson@loni.ucla.edu Tue Nov 16 15:51:04 2004 From: thompson@loni.ucla.edu (Paul Thompson) Date: Tue Nov 16 15:51:04 2004 Subject: [MINC-users] Mincextract to get voxel values and coordinates? In-Reply-To: References: Message-ID: <203CA2AF-3811-11D9-B427-000D93C1CC6C@loni.ucla.edu> --Apple-Mail-26--75548820 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Hello Jason, Andrew, Dylan, and everyone, also here's another new paper comparing skull-stripping methods, it also combines results of them all using a statistical key (a nice idea, as there was not one algorithm that was uniformly better than all others): Rex DE, Shattuck DW, Woods RP, Narr KL, Luders E, Rehm K, Stolzner SE, Rottenberg DA, Toga AW. A meta-algorithm for brain extraction in MRI. Neuroimage. 2004 Oct;23(2):625-37. See you, Paul http://www.loni.ucla.edu/~thompson/thompson.html On Nov 16, 2004, at 12:41 PM, Jason Lerch wrote: > > On Nov 16, 2004, at 2:09 PM, Dylan WAGNER wrote: >> >> >> >> Also thank you for the location of mincbet. So now I'm >> confronted >> with three choices. Mincbet, skullstrip and the preprocessing method >> on >> on the wiki page for VBM. It's a bloody buffet of skullstripping >> methods! >> Any reason why one would be better? The method on the VBM seems more >> tailored to each individual subject, though longer to carry out. > > The basic answer: they all suck. I think that the method on the VBM > pages sucks least of the lot, but I know that others disagree. There > has never been a study which compared all these methods, though this > paper here might help (it does not compare our cortical_surface method > that is described in the VBM pages): > > Boesen K, Rehm K, Schaper K, Stoltzner S, Woods R, Luders E, > Rottenberg D. > Quantitative comparison of four brain extraction algorithms. > Neuroimage. 2004 Jul;22(3):1255-61. > > Cheers, > > Jason > >> Best, >> DDW >> > > _______________________________________________ > MINC-users@bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > --Apple-Mail-26--75548820 Content-Transfer-Encoding: 7bit Content-Type: text/enriched; charset=US-ASCII Hello Jason, Andrew, Dylan, and everyone, also here's another new paper comparing skull-stripping methods, it also combines results of them all using a statistical key (a nice idea, as there was not one algorithm that was uniformly better than all others): Times New Roman0000,3331,CCCARex DE, Shattuck DW, Woods RP, Narr KL, Luders E, Rehm K, Stolzner SE, Rottenberg DA, Toga AW.Times New Roman A meta-algorithm for brain extraction in MRI. Neuroimage. 2004 Oct;23(2):625-37. See you, Paul http://www.loni.ucla.edu/~thompson/thompson.html On Nov 16, 2004, at 12:41 PM, Jason Lerch wrote: On Nov 16, 2004, at 2:09 PM, Dylan WAGNER wrote: Also thank you for the location of mincbet. So now I'm confronted with three choices. Mincbet, skullstrip and the preprocessing method on on the wiki page for VBM. It's a bloody buffet of skullstripping methods! Any reason why one would be better? The method on the VBM seems more tailored to each individual subject, though longer to carry out. The basic answer: they all suck. I think that the method on the VBM pages sucks least of the lot, but I know that others disagree. There has never been a study which compared all these methods, though this paper here might help (it does not compare our cortical_surface method that is described in the VBM pages): Boesen K, Rehm K, Schaper K, Stoltzner S, Woods R, Luders E, Rottenberg D. Quantitative comparison of four brain extraction algorithms. Neuroimage. 2004 Jul;22(3):1255-61. Cheers, Jason Best, DDW _______________________________________________ MINC-users@bic.mni.mcgill.ca http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users --Apple-Mail-26--75548820-- From najma@bic.mni.mcgill.ca Tue Nov 16 16:01:04 2004 From: najma@bic.mni.mcgill.ca (Najmeh Khalili M.) Date: Tue Nov 16 16:01:04 2004 Subject: [MINC-users] Mincextract to get voxel values and coordinates? In-Reply-To: Message-ID: I just want to throw in my two cents in defense of mincbet: what I like about it is that it is somewhat more generous (especially in frontal areas) than the method on WIKI. Also, it allows you to strip the skull prior to classification, which in my experience, improves the classification. I should add, that I have never quantified my former statement about bet's frontal generosity; I have just come to this conclusion by eyeballing many many images. :) Najma On Tue, 16 Nov 2004, Jason Lerch wrote: > > On Nov 16, 2004, at 2:09 PM, Dylan WAGNER wrote: > > > > > > > > Also thank you for the location of mincbet. So now I'm confronted > > with three choices. Mincbet, skullstrip and the preprocessing method on > > on the wiki page for VBM. It's a bloody buffet of skullstripping > > methods! > > Any reason why one would be better? The method on the VBM seems more > > tailored to each individual subject, though longer to carry out. > > The basic answer: they all suck. I think that the method on the VBM > pages sucks least of the lot, but I know that others disagree. There > has never been a study which compared all these methods, though this > paper here might help (it does not compare our cortical_surface method > that is described in the VBM pages): > > Boesen K, Rehm K, Schaper K, Stoltzner S, Woods R, Luders E, Rottenberg > D. > Quantitative comparison of four brain extraction algorithms. > Neuroimage. 2004 Jul;22(3):1255-61. > > Cheers, > > Jason > > > Best, > > DDW > > > > _______________________________________________ > MINC-users@bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > From andrew_janke@iinet.net.au Tue Nov 16 16:44:04 2004 From: andrew_janke@iinet.net.au (Andrew Janke) Date: Tue Nov 16 16:44:04 2004 Subject: [MINC-users] Mincextract to get voxel values and coordinates? In-Reply-To: References: Message-ID: On Tue, 16 Nov 2004, Robert VINCENT wrote: > Hmmm... I took a look at the code, and minctotag rounds the voxel data > values before writing them to the tag file. I have no idea why, but that > seems to be how the author defined the tag file format. > > It it becomes a nuisance it would be easy enough to fix, or to offer an > alternative through mincextract. Or perhaps mincsample in /s/s/minc_dev/mincsample This new minc tool has been written to do these sorts of things. I just haven't added the bit to extract co-ordinate values along with the voxel data. This may be better than breaking the existing functionality of minctotag. I suspect something like this would do the trick: mincsample -ascii -coords -mask point-mask.mnc stats_file.mnc (note -coords doesn't exist as an option yet, but would be very easy to add) -- Andrew Janke (andrew_janke@iinet.net DOT au || www.cmr.uq.edu.au/~rotor) Australia->Brisbane H: +61 7 3390 6332 || M: +61 4 2138 8581 From andrew_janke@iinet.net.au Tue Nov 16 16:47:04 2004 From: andrew_janke@iinet.net.au (Andrew Janke) Date: Tue Nov 16 16:47:04 2004 Subject: [MINC-users] FSL and MINC In-Reply-To: References: Message-ID: On Tue, 16 Nov 2004, Sridar Narayanan wrote: > Andrew, if you can devise a general solution that allows all of FSL (bet, > FEAT, SIENA, etc.) to "just work" on MINC files, that would be extremely > useful to a number of people in our lab. I'll take that as a "yes" for a). > I suppose the main question is how much effort would it be to stay in sync > with new versions of FSL? Also, would you be updating the I/O module of FSL > such that the constituent programs could *write" MINC as well as read? SHouldn't be much as digging in the code I note that they have already (now) added a lot of code for reading minc. Nothing that actually reads it up the support is there. Thus they obviously have plans to support it in the future. Call it evolution... :) a From andrew_janke@iinet.net.au Tue Nov 16 16:49:03 2004 From: andrew_janke@iinet.net.au (Andrew Janke) Date: Tue Nov 16 16:49:03 2004 Subject: [MINC-users] Mincextract to get voxel values and coordinates? In-Reply-To: <20041116190032.GA5002012@shadow.bic.mni.mcgill.ca> References: <3B6420C6-377E-11D9-A6C9-000A95DBBFD8@bic.mni.mcgill.ca> <20041116190032.GA5002012@shadow.bic.mni.mcgill.ca> Message-ID: On Tue, 16 Nov 2004, Alex ZIJDENBOS wrote: > Say - if enough MINC users want this, would that convince Steve Smith > to add a MINC I/O abilities to FSL?! Seems like that would by far the > easiest and most elegant solution? ;) Whilst steve may not be amenable. His (justified) approach from what I have heard/know to this sort of thing is "get your data in ANALYZE/NIFTI" and then come talk to me. There are others on the FSL team however who have a different view. Christian Beckmann for instance. I'll email the FSL list to guage interest/support. If we can do it with their belssing all the better. If not well we'll just have to market/sell it as an add-on. -- Andrew Janke (andrew_janke@iinet.net DOT au || www.cmr.uq.edu.au/~rotor) Australia->Brisbane H: +61 7 3390 6332 || M: +61 4 2138 8581 From dwagne@bic.mni.mcgill.ca Tue Nov 16 19:26:04 2004 From: dwagne@bic.mni.mcgill.ca (Dylan WAGNER) Date: Tue Nov 16 19:26:04 2004 Subject: [MINC-users] Mincextract to get voxel values and coordinates? In-Reply-To: Message-ID: Hi all, On the minctotag issue: The more I think about it, the more it seems necessary for me to have the true voxel values rather than rounded to the nearest integer. Reason being is I'm correlating voxel intensities between two sessions in the same subject. I'm hoping to generate a scatterplot of every voxel in the first session against the same voxels in the 2nd session (both in mni space). For whole brain, integers aren't so bad and with 900,000 voxel it won't affect the shape of the distribution much. But once I do the same for smaller ROIs I'm going to run into trouble if everything is integers. So! Anyone have any other methods? Since I'm correlating voxels I need both coordinates and values. I presume it wouldn't be rocket science to modify minctotag, however I honnestly would have no idea how to compile it afterwards. Thanks, > Hi Dylan, > > Hmmm... I took a look at the code, and minctotag rounds the voxel data > values before writing them to the tag file. I have no idea why, but that > seems to be how the author defined the tag file format. > > It it becomes a nuisance it would be easy enough to fix, or to offer an > alternative through mincextract. > > -bert > > On Tue, 16 Nov 2004, Dylan WAGNER wrote: > > > > > > > > > Hi Jason, > > > > Thanks for the response. I wasn't aware of minctotag, and after > > sniffing around, wow there's a lot more minc apps than on the wiki or bic > > pages alone. I suppose that sounds a bit naive. I stumbled across a list > > at http://www.bic.mni.mcgill.ca/~stever/software_map.html > > As I use some of these I'll try and add them to the wiki. > > > > A few questions regarding minctotag. > > > > So far it works great, however: > > > > Voxel intensities are integers? The same minc in register gives me a > > fair bit more precision. However for my purposes integers are fine, I'm > > just curious why. > > > > > > Also thank you for the location of mincbet. So now I'm confronted > > with three choices. Mincbet, skullstrip and the preprocessing method on > > on the wiki page for VBM. It's a bloody buffet of skullstripping methods! > > Any reason why one would be better? The method on the VBM seems more > > tailored to each individual subject, though longer to carry out. > > > > Best, > > DDW > > > > > > _______________________________________________ > > MINC-users@bic.mni.mcgill.ca > > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > > > > _______________________________________________ > MINC-users@bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > From dwagne@bic.mni.mcgill.ca Tue Nov 16 21:23:04 2004 From: dwagne@bic.mni.mcgill.ca (Dylan WAGNER) Date: Tue Nov 16 21:23:04 2004 Subject: [MINC-users] Mincextract to get voxel values and coordinates? In-Reply-To: Message-ID: Hi, I've used find_peaks a fair bit, I was hoping with low threshold and 0 distance I could coax it to give me all the voxels and their coordinates (as I didn't know about minctotag at the time). However I see from what you said that no amount of bullying would have forced it to deliver the goods. Alas. From k.h.kho@azu.nl Wed Nov 17 04:39:04 2004 From: k.h.kho@azu.nl (Kuan H. Kho) Date: Wed Nov 17 04:39:04 2004 Subject: [MINC-users] FSL and MINC In-Reply-To: References: Message-ID: It would be extremely useful for people in other labs as well!!! I am in favor!! Kuan (Utrecht-NL) >On Tue, 16 Nov 2004, Sridar Narayanan wrote: > >>Andrew, if you can devise a general solution that allows all of FSL (bet, >>FEAT, SIENA, etc.) to "just work" on MINC files, that would be extremely >>useful to a number of people in our lab. > >I'll take that as a "yes" for a). > >>I suppose the main question is how much effort would it be to stay >>in sync with new versions of FSL? Also, would you be updating the >>I/O module of FSL such that the constituent programs could *write" >>MINC as well as read? > >SHouldn't be much as digging in the code I note that they have >already (now) added a lot of code for reading minc. Nothing that >actually reads it up the support is there. Thus they obviously have >plans to support it in the future. Call it evolution... :) From Peter Neelin Wed Nov 17 08:50:04 2004 From: Peter Neelin (Peter Neelin) Date: Wed Nov 17 08:50:04 2004 Subject: [MINC-users] Mincextract to get voxel values and coordinates? In-Reply-To: References: Message-ID: On Mon, 15 Nov 2004 21:35:59 -0500, Dylan WAGNER wrote: > > I'm trying to get a table of voxel values and coordinates above a > certain threshold. Which tool would be most appropriate for this? > > find_peaks with the distance set to 0 still doesn't give me every single > voxel (I know this because mincstats tells me I have 11,000 voxels above > threshold and find_pos only gives me about 90). find_peaks was designed to do exactly this task. mincstats is telling you how many voxels are above the threshold. find_peaks tells you how many peaks are above threshold (a peak is a voxel that is greater than all of its neighbours). Most voxels above threshold are not interesting - they are on the side of the mountain, so to speak. Generally, one is only interested in the peaks, unless you want to evaluate something like the area of the peak. If your input data is fairly smooth, then having only 90 peaks above threshold is not surprising. Having 11000 voxels above threshold tells you something about the area above threshold, not the peaks. The only weirdness that I can recall in the output of find_peaks is the handling of plateaus (a flat peak). I think that all of the edge voxels are identified as peaks. You should not usually see this type of structure in fMRI or PET data, however. Note also that by default find_peaks suppresses edge peaks, since these are generally not true peaks, but artifacts of the volume boundary. You can change this behaviour with the -include_edges flag. You can persuade yourself that find_peaks is in fact working by loading the tag file into register with the original volume (I cannot remember if you have to give two volumes). Set the lookup table minimum to your threshold and then step through the list of peaks (with the down arrow), or simply stack through the volume. You should see that all visible peaks have a corresponding circle (identifying a tag). The intensity value of the volume at the peak is given as the label of the tag (the string at the end of each tag line). Peter From schwarzd@feec.vutbr.cz Thu Nov 18 04:03:05 2004 From: schwarzd@feec.vutbr.cz (Schwarz Daniel) Date: Thu Nov 18 04:03:05 2004 Subject: [MINC-users] (no subject) Message-ID: <1100768560.419c6530053d2@email.fit.vutbr.cz> I am afraid that the ICBM files at ftp://ftp.bic.mni.mcgill.ca/pub/avgbrain/ are harmed.... Having 4kB, they do not seem to contain any data. What about the lables for templates? Is it possible to download anywhere the labeled volumes? So far I have got only the labels for ICBM_single-subject-0.5mm. Daniel Schwarz Andrew Janke wrote: > On Tue, 16 Nov 2004, Daniel Schwarz wrote: > >> playing with mritotal linear and nonlinear, I would like to try my data with more atlases. So far I have tried >> - average_305.mnc (for which I have no label volume), >> - ICBM_single-subject-0.5mm (for which the label volume is available) >> and the brainweb_phantom_1mm (for which the tissue classes are available). >> >> I am looking for more atlases with the anatomical labels. There's a lot of posts concerning the ICBM_template_152 here. Is it available anywhere? I have looked for it unsuccessfully... > > > A long time ago (and to this day I see) you could get the ICBM template from here: > > ftp://ftp.bic.mni.mcgill.ca/pub/avgbrain/ > > -- > Andrew Janke (andrew_janke@iinet.net DOT au || www.cmr.uq.edu.au/~rotor) Australia->Brisbane H: +61 7 3390 6332 || M: +61 4 2138 8581 > _______________________________________________ > MINC-users@bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users From andrew_janke@iinet.net.au Thu Nov 18 05:52:04 2004 From: andrew_janke@iinet.net.au (Andrew Janke) Date: Thu Nov 18 05:52:04 2004 Subject: [MINC-users] FSL and MINC In-Reply-To: References: Message-ID: On Wed, 17 Nov 2004, Kuan H. Kho wrote: > It would be extremely useful for people in other labs as well!!! > I am in favor!! Well it would appear that the good folks in oxford already have plans with respect to this: http://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind0411&L=fsl&T=0&F=&S=&P=10644 a From alex@bic.mni.mcgill.ca Thu Nov 18 10:06:04 2004 From: alex@bic.mni.mcgill.ca (Alex ZIJDENBOS) Date: Thu Nov 18 10:06:04 2004 Subject: [MINC-users] (no subject) In-Reply-To: <1100768560.419c6530053d2@email.fit.vutbr.cz> References: <1100768560.419c6530053d2@email.fit.vutbr.cz> Message-ID: <20041118150529.GA5048893@shadow.bic.mni.mcgill.ca> On Thu, Nov 18, 2004 at 10:02:40AM +0100, Schwarz Daniel wrote: > I am afraid that the ICBM files at ftp://ftp.bic.mni.mcgill.ca/pub/avgbrain/ are > harmed.... Having 4kB, they do not seem to contain any data. That is both correct and incorrect - indeed they contain no data, but they are not harmed either :) These are minc files without data segments, i.e., header only. Their only purpose is to define a standard sampling space at a number of different reolutions, and I believe their only proper place is behind a '-like' option. > What about the lables for templates? Is it possible to download anywhere the > labeled volumes? So far I have got only the labels for > ICBM_single-subject-0.5mm. I think Louis Collins is working on making these available. -- A -- ========================================================================= | 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 | ========================================================================= From pelletj@videotron.ca Sun Nov 21 19:33:05 2004 From: pelletj@videotron.ca (Julie Pelletier) Date: Sun Nov 21 19:33:05 2004 Subject: [MINC-users] Compile the minc librairies to work on Windows Message-ID: <000801c4cd76$6d998870$6e4c8342@pavilion> This is a multi-part message in MIME format. --Boundary_(ID_UXqhOi/UXsbfu4+OXJ/d/A) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hello, Is there any version of the minc librairies compiled for Visual C++ or any instruction to do it Julie Pelletier pelletj@bic.mni.mcgill.ca --Boundary_(ID_UXqhOi/UXsbfu4+OXJ/d/A) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
Hello,
 
Is there any version of the minc librairies compiled for Visual C++ or any instruction to do it 
 
Julie Pelletier
pelletj@bic.mni.mcgill.ca
--Boundary_(ID_UXqhOi/UXsbfu4+OXJ/d/A)-- From ayelet.akselrod-ballin@weizmann.ac.il Mon Nov 22 00:43:05 2004 From: ayelet.akselrod-ballin@weizmann.ac.il (Ayelet) Date: Mon Nov 22 00:43:05 2004 Subject: [MINC-users] viewing & transforming minc files Message-ID: <000201c4d055$a8e11f60$a3514c84@math107pc> This is a multi-part message in MIME format. ------=_NextPart_000_0003_01C4D066.6C69EF60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello, I received the brain atlas from ICBM in ICBM_0.5mm.mnc format How can I view the files? How can I transform them to .img .hdr, or extract the header information and use the binary content? Thanks, Ayelet ------=_NextPart_000_0003_01C4D066.6C69EF60 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

I received the brain atlas from ICBM in = ICBM_0.5mm.mnc format

How can I view the files?

How can I transform them to .img .hdr, or extract the = header information and use the binary content?

 

Thanks,

Ayelet

------=_NextPart_000_0003_01C4D066.6C69EF60-- From mhough@fmrib.ox.ac.uk Mon Nov 22 04:28:05 2004 From: mhough@fmrib.ox.ac.uk (Morgan Hough) Date: Mon Nov 22 04:28:05 2004 Subject: [MINC-users] viewing & transforming minc files In-Reply-To: <000201c4d055$a8e11f60$a3514c84@math107pc> References: <000201c4d055$a8e11f60$a3514c84@math107pc> Message-ID: <1101115449.16095.14.camel@dhania.fmrib.ox.ac.uk> Ayelet, I don't have any experience with the MNI Display program although I believe you can use that to see the data if you want a MNI tool for this. There are many packages that are MINC compatible as well. If you like MATLAB then you might try EMMA. If you are already an AFNI user then you could use its viewer. There are others too. mincheader will print the header and mincinfo will give you basic information about the file. Using the binary content again is a question of what you want to do and what tools/languages you are interested in using. For MINC to Analyze format conversion you can try ana2mnc from: http://www.cmr.uq.edu.au/~rotor/software/ where there is more information about all MINC related topics. A quick google search would bring this stuff up and more. Hope this helps. Cheers, -Morgan -- Morgan Hough DPhil student FMRIB, John Radcliffe Hospital, Headington, Oxford OX3 9DU, UK mhough@fmrib.ox.ac.uk www.fmrib.ox.ac.uk/~mhough tel +44 (0) 1865 222545 fax +44 (0) 1865 222717 On Mon, 2004-11-22 at 05:39, Ayelet wrote: > Hello, > > > > I received the brain atlas from ICBM in ICBM_0.5mm.mnc format > > How can I view the files? > > How can I transform them to .img .hdr, or extract the header > information and use the binary content? > > > > Thanks, > > Ayelet > From andrew_janke@iinet.net.au Mon Nov 22 08:18:03 2004 From: andrew_janke@iinet.net.au (Andrew Janke) Date: Mon Nov 22 08:18:03 2004 Subject: [MINC-users] Compile the minc librairies to work on Windows In-Reply-To: <000801c4cd76$6d998870$6e4c8342@pavilion> References: <000801c4cd76$6d998870$6e4c8342@pavilion> Message-ID: On Thu, 18 Nov 2004, Julie Pelletier wrote: > Is there any version of the minc librairies compiled for Visual C++ or any instruction to do it Yes, Gibby koldenhof has been maintaining a w32 build of minc here: http://sourceforge.net/projects/mni-minc-win32/ a From andrew_janke@iinet.net.au Mon Nov 22 08:25:03 2004 From: andrew_janke@iinet.net.au (Andrew Janke) Date: Mon Nov 22 08:25:03 2004 Subject: [MINC-users] voxel_loop-like hard-disk access for arbitrary voxel positions In-Reply-To: <003301c4c7b8$31f92d20$07751d96@surgsim5> References: <003301c4c7b8$31f92d20$07751d96@surgsim5> Message-ID: On Wed, 10 Nov 2004, Michel Audette wrote: Michel, I have been giving this a bit of thought over the past few days and here is what I can come up with... > Are you familiar with Level-set and Fast Marching Level-Set surface models? Yup. > Basically, it involves an evolving front, and I'm trying to figure out a way > to implement something like this with voxel_loop-like management (i.e.: use > as little RAM as possible). In other words, it does not process the whole > volume at once, but iterates an evolving surface based on a moving shell > surrounding the surface at the previous simulated time iteration. Wondering > if this is feasible under MINC, in a manner comparable to voxel_loop... In > other words, I need to be able to access specific voxels of a given volume > on disk.... ok... > Can anyone comment? I need to process MR volumes that have been resampled to > CT-density, actually greater than normal CT-density, in the sense that I > first resample CT data to be isotropic, typically .5mm resolution, and do > the same for MR. I need to do this with a 32-bit Linux machine, hence the > problem. The best solution I can think of is the data blocking features of HDF (minc 2.0) I don't know just how much of this has been implmented in minc 2.0 as of yet, but at least you could load a set of sub-blocks using a prioritised list of local neighbouring blocks. There is no sensical way that I can think of where you are going to be able to prdict where your front will evolve to and thus approaches like voxel_loop are doomed to fail IMHO. ;( But given that you are iterating, (not recursing) what is the possibility that you could evolve your front with sub-blocks of the volume, and write your results out as you go? The simplest approach would be to take the volume in 8 chunks to begin with first. -- Andrew Janke (andrew_janke@iinet.net DOT au || www.cmr.uq.edu.au/~rotor) Australia->Brisbane H: +61 7 3390 6332 || M: +61 4 2138 8581 From bert@bic.mni.mcgill.ca Mon Nov 22 10:41:04 2004 From: bert@bic.mni.mcgill.ca (Robert VINCENT) Date: Mon Nov 22 10:41:04 2004 Subject: [MINC-users] Compile the minc librairies to work on Windows In-Reply-To: Message-ID: Hi Julie, This is something I plan to release with MINC 1.4 and other future MINC releases. In the meantime, the link Andrew gave is probably your best option. Which parts of MINC do you plan to use on Windows? What applications will you be running? -bert On Mon, 22 Nov 2004, Andrew Janke wrote: > On Thu, 18 Nov 2004, Julie Pelletier wrote: > > > Is there any version of the minc librairies compiled for Visual C++ or any instruction to do it > > Yes, Gibby koldenhof has been maintaining a w32 build of minc here: > > http://sourceforge.net/projects/mni-minc-win32/ > > > a > _______________________________________________ > MINC-users@bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > From schwarzd@feec.vutbr.cz Tue Nov 23 10:50:04 2004 From: schwarzd@feec.vutbr.cz (Daniel Schwarz) Date: Tue Nov 23 10:50:04 2004 Subject: [MINC-users] labeling Message-ID: <41A35BFC.6000908@feec.vutbr.cz> Dear minc-users, I would like to ask one thing, just tu make sure I don't do nonsense. Is this labeling? mincresample -nearest_neighbour -invert_transform -transform nonlinear.xfm -like image.mnc phantom_labels.mnc labeled_image.mnc where: - image.mnc is the image I want to segment/label. - nonlinear.xfm is file containing the affine transform and the name of the file with displacement field. I have got it with MRITOTAL and MRITOTAL -nonlinear, where the model was phantom_template. - phantom_labels.mnc is segmented phantom_template.mnc - labeled_image.mnc is the expected segmented/labeled image.mnc Thanks a lot for your answers/corrections/notices. Daniel Schwarz From louis.collins@mcgill.ca Tue Nov 23 17:38:04 2004 From: louis.collins@mcgill.ca (D. Louis Collins) Date: Tue Nov 23 17:38:04 2004 Subject: [MINC-users] labeling In-Reply-To: <41A35BFC.6000908@feec.vutbr.cz> Message-ID: Daniel, You have it exactly - this step customizes a standard set of labels (phantom_labels.mnc) to your subject. The script stx_segment uses this as a basic step, but combines the result with classsification results and heuristic rules to minimize errors. -Louis On 11/23/04 10:49 AM, "Daniel Schwarz" wrote: > Dear minc-users, > > I would like to ask one thing, just tu make sure I don't do nonsense. > Is this labeling? > > mincresample -nearest_neighbour -invert_transform -transform > nonlinear.xfm -like image.mnc phantom_labels.mnc labeled_image.mnc > > where: > > - image.mnc is the image I want to segment/label. > > - nonlinear.xfm is file containing the affine transform and the name of > the file with displacement field. I have got it with MRITOTAL and > MRITOTAL -nonlinear, where the model was phantom_template. > > - phantom_labels.mnc is segmented phantom_template.mnc > > - labeled_image.mnc is the expected segmented/labeled image.mnc > > > Thanks a lot for your answers/corrections/notices. > > Daniel Schwarz > > > > _______________________________________________ > MINC-users@bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users From schwarzd@feec.vutbr.cz Wed Nov 24 02:25:04 2004 From: schwarzd@feec.vutbr.cz (Daniel Schwarz) Date: Wed Nov 24 02:25:04 2004 Subject: [MINC-users] labeling In-Reply-To: References: Message-ID: <41A43733.8030307@feec.vutbr.cz> Thank you very much, Louis. Minimizing the errors = my next step. I would like to try your stx_segment, I am waiting patiently for the time, when it is available for public. I am also trying some other methods to find deformation field which may yield better fit. Could you please explain briefly the role of the "heuristic rules" in stx_segment? Thank you. Daniel D. Louis Collins napsal(a): >Daniel, > >You have it exactly - this step customizes a standard set of labels >(phantom_labels.mnc) to your subject. > >The script stx_segment uses this as a basic step, but combines the result >with classsification results and heuristic rules to minimize errors. > >-Louis > > >On 11/23/04 10:49 AM, "Daniel Schwarz" wrote: > > > >>Dear minc-users, >> >>I would like to ask one thing, just tu make sure I don't do nonsense. >>Is this labeling? >> >>mincresample -nearest_neighbour -invert_transform -transform >>nonlinear.xfm -like image.mnc phantom_labels.mnc labeled_image.mnc >> >>where: >> >>- image.mnc is the image I want to segment/label. >> >>- nonlinear.xfm is file containing the affine transform and the name of >>the file with displacement field. I have got it with MRITOTAL and >>MRITOTAL -nonlinear, where the model was phantom_template. >> >>- phantom_labels.mnc is segmented phantom_template.mnc >> >>- labeled_image.mnc is the expected segmented/labeled image.mnc >> >> >>Thanks a lot for your answers/corrections/notices. >> >>Daniel Schwarz >> >> >> >>_______________________________________________ >>MINC-users@bic.mni.mcgill.ca >>http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users >> >> > > > From cogilvie@ualberta.ca Wed Nov 24 17:10:06 2004 From: cogilvie@ualberta.ca (Catherine Ogilvie) Date: Wed Nov 24 17:10:06 2004 Subject: [MINC-users] basic tools Message-ID: <41A88C05@webmail.ualberta.ca> Hi all. I am wondering how one would go about getting the "basic tools" (as referred to on the bic software toolbox webpage - http://www.bic.mni.mcgill.ca/software/), such as mincmath, mincinfo, mincaverage, etc.? Thank-you Catherine Ogilvie MSc Candidate University of Alberta Department of Psychiatry 3068 Research Transition Facility Edmonton, AB T6G 2V2 780 407 6626 Ph From bert@bic.mni.mcgill.ca Wed Nov 24 17:20:04 2004 From: bert@bic.mni.mcgill.ca (Robert VINCENT) Date: Wed Nov 24 17:20:04 2004 Subject: [MINC-users] basic tools In-Reply-To: <41A88C05@webmail.ualberta.ca> Message-ID: Hi Catherine, You would want to install the core MINC package. The source distribution is available here: http://www.bic.mni.mcgill.ca/software/distribution/packages/minc-1.3.tar.gz It should compile and build on most UNIX, Linux, or Mac OS X platforms. You will need to install the netCDF package. It is available from our website here: http://www.bic.mni.mcgill.ca/software/distribution/packages/netcdf-3.5.0.tar.gz Binary versions of these are available if you prefer. If you have any other questions, please don't hesitate to contact me directly. -bert On Tue, 23 Nov 2004, Catherine Ogilvie wrote: > Hi all. > > I am wondering how one would go about getting the "basic tools" (as referred > to on the bic software toolbox webpage - > http://www.bic.mni.mcgill.ca/software/), such as mincmath, mincinfo, > mincaverage, etc.? > > Thank-you > Catherine Ogilvie > > MSc Candidate > University of Alberta > Department of Psychiatry > 3068 Research Transition Facility > Edmonton, AB T6G 2V2 > 780 407 6626 Ph > > _______________________________________________ > MINC-users@bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > From m.audette@aist.go.jp Thu Nov 25 02:07:03 2004 From: m.audette@aist.go.jp (Michel Audette) Date: Thu Nov 25 02:07:03 2004 Subject: [MINC-users] voxel_loop-like hard-disk access for arbitrary voxel positions References: Message-ID: <002a01c4d2bf$de4d7060$196f1d96@surgsim2> Hi Louis, Max worked with me this past summer as a JSPS fellow, and I have his code, but he didn't do the Level Set part of his research with voxel loop. He did pre and post-processing with voxel loop, which involved sequential processing of whole volumes, for which it is suited. Anyhow, I'm also leaning more and more towards a Linux with Large File Support capabilities. That should also address the problem, shouldn't it? Michel Michel Audette, Ph.D., Research Fellow, Surgical Simulation, Surgical Assist Technology Group, AIST, Namiki 1-2, Tsukuba, Japan, 305-8564. -------------------------------------------------------- "If you think you can do it, you're right. If you think you can't do it, you're still right." - Henry Ford ----- Original Message ----- From: "D. Louis Collins" To: "Andrew Janke" ; "Michel Audette" Cc: "Maxime Descoteaux" Sent: Monday, November 22, 2004 10:46 PM Subject: Re: [MINC-users] voxel_loop-like hard-disk access for arbitrary voxel positions > > Hi guys, > > A student of Kaleem worked a bit on this during his MSc (Maxime Descoteau) > for vessel segmentation using level sets. I was under the impression (but > not sure) that he used voxel loop to do his processing since he was using > ~512^3 volumes. Michel, do you know if Max used this? > > He is currently in southeast asia until Xmas. He starts a PhD in Nice in > January. > > I think that he is reading mail from time-to-time... > > -Louis > > On 11/22/04 8:24 AM, "Andrew Janke" wrote: > > > On Wed, 10 Nov 2004, Michel Audette wrote: > > > > Michel, I have been giving this a bit of thought over the past few days and > > here > > is what I can come up with... > > > >> Are you familiar with Level-set and Fast Marching Level-Set surface models? > > > > Yup. > > > >> Basically, it involves an evolving front, and I'm trying to figure out a way > >> to implement something like this with voxel_loop-like management (i.e.: use > >> as little RAM as possible). In other words, it does not process the whole > >> volume at once, but iterates an evolving surface based on a moving shell > >> surrounding the surface at the previous simulated time iteration. Wondering > >> if this is feasible under MINC, in a manner comparable to voxel_loop... In > >> other words, I need to be able to access specific voxels of a given volume > >> on disk.... > > > > ok... > > > >> Can anyone comment? I need to process MR volumes that have been resampled to > >> CT-density, actually greater than normal CT-density, in the sense that I > >> first resample CT data to be isotropic, typically .5mm resolution, and do > >> the same for MR. I need to do this with a 32-bit Linux machine, hence the > >> problem. > > > > The best solution I can think of is the data blocking features of HDF (minc > > 2.0) > > I don't know just how much of this has been implmented in minc 2.0 as of yet, > > but at least you could load a set of sub-blocks using a prioritised list of > > local neighbouring blocks. > > > > There is no sensical way that I can think of where you are going to be able to > > prdict where your front will evolve to and thus approaches like voxel_loop are > > doomed to fail IMHO. ;( > > > > But given that you are iterating, (not recursing) what is the possibility that > > you could evolve your front with sub-blocks of the volume, and write your > > results out as you go? The simplest approach would be to take the volume in 8 > > chunks to begin with first. > > > > > > > > -- > > Andrew Janke (andrew_janke@iinet.net DOT au || www.cmr.uq.edu.au/~rotor) > > Australia->Brisbane H: +61 7 3390 6332 || M: +61 4 2138 8581 > > _______________________________________________ > > MINC-users@bic.mni.mcgill.ca > > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > > From cjb@pet.auh.dk Fri Nov 26 05:32:04 2004 From: cjb@pet.auh.dk (Christopher Bailey) Date: Fri Nov 26 05:32:04 2004 Subject: [MINC-users] PET analysis on MINC files Message-ID: <1101465108.18360.107.camel@kafka.pet.auh.dk> Dear list, and PET-users in particular. I would be grateful for advice, comments, pointers, anything, on how best to analyse CBF "activation" studies (15-O-water). People here in Aarhus (DK) have been using dot since the mid 90's. I joined this year, after some experience in amongst others the FMRI world. It seems to me that dot has fallen a little out of date. We are running version 1.8.0, which according to the manual is from 1998. I take it dot is no longer supported? Though a t-test will always be a t-test, whatever the year, I would like to see us use the more advanced inference methods available in, for example, FSL, SPM and even FMRIstat. Is that in fact what is happening; MINC PET's convert their data into Analyze/NifTi and use e.g. SPM? Or is the community still sticking to dot? Personally, I like FSL (the filosophy of which does resemble that of dot, no?) and would like to use it both for FMRI and PET. However, I would prefer sticking to a single file format. I noticed Andrew has put some pressure on the Oxford guys to include MINC in the read/write file formats of FSL. As noted before on the list, they already have a skeleton of MINC routines in their IO library. Is it the Master Plan of the MINC Executive Decision Committee (!?!) to lobby the inclusion of MINC into, e.g., FSL (soon!), or is there an Alternative Plan to update dot to the status quo of analysis methods? Is there a version of dot anywhere that is (easily) compilable/compiled for linux? Best regards, Chris -- Christopher Bailey PET Centre and Center for Functionally Integrative Neuroscience Aarhus University Hospital, Denmark http://www.cfin.au.dk/ From cjb@pet.auh.dk Fri Nov 26 05:34:05 2004 From: cjb@pet.auh.dk (Christopher Bailey) Date: Fri Nov 26 05:34:05 2004 Subject: [MINC-users] Pretty Pictures of MINC files Message-ID: <1101465148.18360.111.camel@kafka.pet.auh.dk> Hi again, Following up on my PET-post, I would like to address the related issue of production of Pretty Pictures for publications. Now that FreeSurfer, Caret/SureFit and Brainvoyager are churning out inflated/flattened maps at an alarming rate, the Marching Cubes of Display seems a bit quaint. I think the MINC community would embrace something that could produce, say, an Anatomic Segmentation using Proximities................. Again, converters can be used to flip-flop between file formats. However, keeping track of 2 coordinate system transformations (3D and 2D) could become a hassle. Sticking to MINC all the way though an analysis would in the case of cortical inflation, I think, be quite beneficial. Best regards, Chris -- Christopher Bailey PET Centre and Center for Functionally Integrative Neuroscience Aarhus University Hospital, Denmark http://www.cfin.au.dk/ From cjb@pet.auh.dk Fri Nov 26 05:38:04 2004 From: cjb@pet.auh.dk (Christopher Bailey) Date: Fri Nov 26 05:38:04 2004 Subject: [MINC-users] Anatomical labelling of MINC files Message-ID: <1101465471.18360.118.camel@kafka.pet.auh.dk> Hi again, again, Though the issue of automagically assigning anatomical labels to MR's is a hot potato, I'm curious to know how much such functionality will be included in the MINC tools in the future? There are obvious dangers of mis- and abuse related to labelling, but it seems to me to be a potentially useful tool if used appropriately. Surfing around MINC pages on the net one often stumbles on "internal" documents referring to such things. Are there plans to externalise beyond what's included in dot (1.8.0)? Best regards (this is the last mail, I promise!), Chris -- Christopher Bailey PET Centre and Center for Functionally Integrative Neuroscience Aarhus University Hospital, Denmark http://www.cfin.au.dk/ From jason@bic.mni.mcgill.ca Fri Nov 26 10:40:04 2004 From: jason@bic.mni.mcgill.ca (Jason Lerch) Date: Fri Nov 26 10:40:04 2004 Subject: [MINC-users] Anatomical labelling of MINC files In-Reply-To: <1101465471.18360.118.camel@kafka.pet.auh.dk> References: <1101465471.18360.118.camel@kafka.pet.auh.dk> Message-ID: <5148BED6-3FC1-11D9-8B6E-000A95DBBFD8@bic.mni.mcgill.ca> --Apple-Mail-13-769783031 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Hello Chris, here's an attempt to answer some of your questions: On Nov 26, 2004, at 5:37 AM, Christopher Bailey wrote: > > Hi again, again, > > Though the issue of automagically assigning anatomical labels to MR's > is > a hot potato, I'm curious to know how much such functionality will be > included in the MINC tools in the future? We do have automatic labelling, and have had it since the mid nineties in the ANIMAL package. Collins, D. L., C. J. Holmes, T. M. Peters and A. C. Evanc (1995). "Automatic 3D model-based neuroanatomical segmentation." Human Brain Mapping 3(3): 190-208. As I understand it, the missing pieces will be available for download soon (they just have to be packaged up). > > Following up on my PET-post, I would like to address the related issue > of production of Pretty Pictures for publications. Now that FreeSurfer, > Caret/SureFit and Brainvoyager are churning out inflated/flattened maps > at an alarming rate, the Marching Cubes of Display seems a bit quaint. > I > think the MINC community would embrace something that could produce, > say, an Anatomic Segmentation using Proximities................. I'm not quite sure what you mean - we certainly have the ability to generate surfaces, we have the ability to inflate those surfaces, and we have a ray-tracer available to generate pictures from all the above. No flat-maps, though one can argue about their usefulness anyway. What in particular did you find missing? As for the state of dot - I hope somebody else answers that, as I don't know much about PET analysis. Cheers, Jason --Apple-Mail-13-769783031 Content-Transfer-Encoding: 7bit Content-Type: text/enriched; charset=US-ASCII Hello Chris, here's an attempt to answer some of your questions: On Nov 26, 2004, at 5:37 AM, Christopher Bailey wrote: Hi again, again, Though the issue of automagically assigning anatomical labels to MR's is a hot potato, I'm curious to know how much such functionality will be included in the MINC tools in the future? We do have automatic labelling, and have had it since the mid nineties in the ANIMAL package. Geneva Collins, D. L., C. J. Holmes, T. M. Peters and A. C. Evanc (1995). "Automatic 3D model-based neuroanatomical segmentation." Human Brain Mapping 3(3): 190-208. As I understand it, the missing pieces will be available for download soon (they just have to be packaged up). Following up on my PET-post, I would like to address the related issue of production of Pretty Pictures for publications. Now that FreeSurfer, Caret/SureFit and Brainvoyager are churning out inflated/flattened maps at an alarming rate, the Marching Cubes of Display seems a bit quaint. I think the MINC community would embrace something that could produce, say, an Anatomic Segmentation using Proximities................. I'm not quite sure what you mean - we certainly have the ability to generate surfaces, we have the ability to inflate those surfaces, and we have a ray-tracer available to generate pictures from all the above. No flat-maps, though one can argue about their usefulness anyway. What in particular did you find missing? As for the state of dot - I hope somebody else answers that, as I don't know much about PET analysis. Cheers, Jason --Apple-Mail-13-769783031-- From sylvain@bic.mni.mcgill.ca Fri Nov 26 12:34:04 2004 From: sylvain@bic.mni.mcgill.ca (Sylvain MILOT) Date: Fri Nov 26 12:34:04 2004 Subject: [MINC-users] PET analysis on MINC files In-Reply-To: <1101465108.18360.107.camel@kafka.pet.auh.dk> Message-ID: Hello Chris, You're right in your assessment of dot support since I do not wear that hat much anymore. The support I offer is limited to its usage at large for both clinical and experimental use. I spend the rest of my time doing sys admin work. I did have version 2.0 in the making but haven't done any serious work on it for almost 2 years now. I would like to complete it but time is hard to find. Even if version 2.0 was out it would still be limited to GLIM (General LInear Model). Dr. Keith Worsley told me it was possible to analyse PET data with his fMRIstats package and I have also wanted to explore this ... my wishlist is at a standstill unless I make time for it - this will be my year 2005 resolution! :-/ In the meantime I have to concentrate on my monday interview for jury duty - on how to make myself unworthy for selection, so that it doesn't suck up 3 months of my life if not worse ... this is a scary thought ... not that I wouldn't want to do my civic duty, but seriously who has time for this! Needless to say this is not on my wishlist. I havent answered all of your questions specifically but I think you get the general picture. PS. I dont know much about FSL - I'll add that to my wishlist PPS. dot is not available for linux although it could be, with some work - this was part of my dot 2.1 plan ... don't hold your breath ... Sylvain On Fri, 26 Nov 2004, Christopher Bailey wrote: > > Dear list, > > and PET-users in particular. I would be grateful for advice, comments, > pointers, anything, on how best to analyse CBF "activation" studies > (15-O-water). > > People here in Aarhus (DK) have been using dot since the mid 90's. I > joined this year, after some experience in amongst others the FMRI > world. It seems to me that dot has fallen a little out of date. We are > running version 1.8.0, which according to the manual is from 1998. I > take it dot is no longer supported? > > Though a t-test will always be a t-test, whatever the year, I would like > to see us use the more advanced inference methods available in, for > example, FSL, SPM and even FMRIstat. Is that in fact what is happening; > MINC PET's convert their data into Analyze/NifTi and use e.g. SPM? Or is > the community still sticking to dot? > > Personally, I like FSL (the filosophy of which does resemble that of > dot, no?) and would like to use it both for FMRI and PET. However, I > would prefer sticking to a single file format. I noticed Andrew has put > some pressure on the Oxford guys to include MINC in the read/write file > formats of FSL. As noted before on the list, they already have a > skeleton of MINC routines in their IO library. Is it the Master Plan of > the MINC Executive Decision Committee (!?!) to lobby the inclusion of > MINC into, e.g., FSL (soon!), or is there an Alternative Plan to update > dot to the status quo of analysis methods? > > Is there a version of dot anywhere that is (easily) compilable/compiled > for linux? > > Best regards, > Chris > > -- > Christopher Bailey > PET Centre and > Center for Functionally Integrative Neuroscience > Aarhus University Hospital, Denmark > http://www.cfin.au.dk/ > > > > _______________________________________________ > MINC-users@bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > --- Sylvain Milot (sylvain@bic.mni.mcgill.ca) (trinity@bic.mni.mcgill.ca) Brain Imaging Centre Montreal Neurological Institute Webster 2B, Room 208 Montreal, Qc., Canada, H3A 2B4 Phone : (514) 398-4965, Fax: 398-8948 Mobile : (514) 712-1768 Office : 527 Pine, room 204 From andrew_janke@iinet.net.au Fri Nov 26 18:27:04 2004 From: andrew_janke@iinet.net.au (Andrew Janke) Date: Fri Nov 26 18:27:04 2004 Subject: [MINC-users] Anatomical labelling of MINC files In-Reply-To: <5148BED6-3FC1-11D9-8B6E-000A95DBBFD8@bic.mni.mcgill.ca> References: <1101465471.18360.118.camel@kafka.pet.auh.dk> <5148BED6-3FC1-11D9-8B6E-000A95DBBFD8@bic.mni.mcgill.ca> Message-ID: On Fri, 26 Nov 2004, Jason Lerch wrote: > Collins, D. L., C. J. Holmes, T. M. Peters and A. C. Evanc (1995). "Automatic > 3D model-based neuroanatomical segmentation." Human Brain Mapping 3(3): > 190-208. > > As I understand it, the missing pieces will be available for download soon > (they just have to be packaged up). The models part of this will be available early next week. (average305, icbm152 and colin27) -- Andrew Janke (andrew_janke@iinet.net DOT au || www.cmr.uq.edu.au/~rotor) Australia->Brisbane H: +61 7 3390 6332 || M: +61 4 2138 8581 From louis.collins@mcgill.ca Sat Nov 27 06:47:04 2004 From: louis.collins@mcgill.ca (D. Louis Collins) Date: Sat Nov 27 06:47:04 2004 Subject: [MINC-users] Anatomical labelling of MINC files In-Reply-To: <5148BED6-3FC1-11D9-8B6E-000A95DBBFD8@bic.mni.mcgill.ca> Message-ID: > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3184314331_6625398 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Just to confirm for ANIMAL+auto labeling... The target files have been packaged. We still need to rope up and package the label files and the stx_segment script. -Louis On 11/26/04 10:39 AM, "Jason Lerch" wrote: > Hello Chris, > > here's an attempt to answer some of your questions: > > > On Nov 26, 2004, at 5:37 AM, Christopher Bailey wrote: > >> >> Hi again, again, >> >> Though the issue of automagically assigning anatomical labels to MR's is >> a hot potato, I'm curious to know how much such functionality will be >> included in the MINC tools in the future? > > We do have automatic labelling, and have had it since the mid nineties in the > ANIMAL package. > > Collins, D. L., C. J. Holmes, T. M. Peters and A. C. Evanc (1995). "Automatic > 3D model-based neuroanatomical segmentation." Human Brain Mapping 3(3): > 190-208. > > As I understand it, the missing pieces will be available for download soon > (they just have to be packaged up). >> >> Following up on my PET-post, I would like to address the related issue >> of production of Pretty Pictures for publications. Now that FreeSurfer, >> Caret/SureFit and Brainvoyager are churning out inflated/flattened maps >> at an alarming rate, the Marching Cubes of Display seems a bit quaint. I >> think the MINC community would embrace something that could produce, >> say, an Anatomic Segmentation using Proximities................. > > I'm not quite sure what you mean - we certainly have the ability to generate > surfaces, we have the ability to inflate those surfaces, and we have a > ray-tracer available to generate pictures from all the above. No flat-maps, > though one can argue about their usefulness anyway. What in particular did you > find missing? > > As for the state of dot - I hope somebody else answers that, as I don't know > much about PET analysis. > > Cheers, > > Jason > > --B_3184314331_6625398 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Re: [MINC-users] Anatomical labelling of MINC files Just = to confirm for ANIMAL+auto labeling... The target files have been packaged. =  We still need to rope up and package the label files and the stx_segme= nt script.

-Louis



On 11/26/04 10:39 AM, "Jason Lerch" <jason@bic.mni.mcgill.ca&g= t; wrote:

Hello Chris,

here's an attempt to answer some of your questions:


On Nov 26, 2004, at 5:37 AM, Christopher Bailey wrote:


Hi again, again,

Though the issue of automagically assigning anatomical labels to MR's is a hot potato, I'm curious to know how much such functionality will be
included in the MINC tools in the future?  

We do have automatic labelling, and have had it since the mid nineties in t= he ANIMAL package.

Collins, D. L., C. J. Holmes, T. M. Peters and A. C. Evanc (1995). "Au= tomatic 3D model-based neuroanatomical segmentation." Human Brain Ma= pping 3(3): 190-208.

As I understand it, the missing pieces will be available for download soon = (they just have to be packaged up).

Following up on my PET-post, I would like to address the related issue
of production of Pretty Pictures for publications. Now that FreeSurfer, Caret/SureFit and Brainvoyager are churning out inflated/flattened maps at an alarming rate, the Marching Cubes of Display seems a bit quaint. I think the MINC community would embrace something that could produce,
say, an Anatomic Segmentation using Proximities.................  

I'm not quite sure what you mean - we certainly have the ability to generat= e surfaces, we have the ability to inflate those surfaces, and we have a ray= -tracer available to generate pictures from all the above. No flat-maps, tho= ugh one can argue about their usefulness anyway. What in particular did you = find missing?

As for the state of dot - I hope somebody else answers that, as I don't kno= w much about PET analysis.

Cheers,

Jason



--B_3184314331_6625398-- From andrew_janke@iinet.net.au Sun Nov 28 09:25:04 2004 From: andrew_janke@iinet.net.au (Andrew Janke) Date: Sun Nov 28 09:25:04 2004 Subject: [MINC-users] Mincextract to get voxel values and coordinates? In-Reply-To: References: Message-ID: On Mon, 22 Nov 2004, Dylan WAGNER wrote: > Jason Lerch modified minctotag for me (effectively removing the > ROUND command). However as minctotag as no support for searching within a mask > (ie: I get some 900,000 voxels no matter what I do with a 2mm dataset), > something which mincsample does/will, so I'd like to cast my solo vote to > adding this feature to mincsample! >> I suspect something like this would do the trick: >> >> mincsample -ascii -coords -mask point-mask.mnc stats_file.mnc Well it took a bit more work than I expected, but mincsample 1.1 is now available and the above will now work... :) get it here: http://www.bic.mni.mcgill.ca/~rotor/distro/tgz/mincsample-1.1.tar.gz And there is a deb here (built against a sarge install) http://www.bic.mni.mcgill.ca/~rotor/distro/deb/mincsample-1.1-linux-2.6-intel.deb The output format should be what you expect... (in other words, no I haven't finshed the documentation for it yet!) -- Andrew Janke (andrew_janke@iinet.net DOT au || www.cmr.uq.edu.au/~rotor) Australia->Brisbane H: +61 7 3390 6332 || M: +61 4 2138 8581 From m.audette@aist.go.jp Mon Nov 29 08:13:03 2004 From: m.audette@aist.go.jp (Michel Audette) Date: Mon Nov 29 08:13:03 2004 Subject: [MINC-users] Fw: voxel_loop-like hard-disk access for arbitrary voxel positions Message-ID: <000b01c4d6e8$ee331b60$07751d96@surgsim5> > Forwarding to minc-users... 2nd try... > > Michel > > > > Hi Andrew, > > > > I'm working late. Thanks for your kind response. I'll copy to minc-users, > > because others might contribute to and/or benefit from the discussion. > > > > Someone (Andreas Jaeger, who wrote a homepage on LFS > > http://www.suse.de/~aj/linux_lfs.html ) has told me that LFS works for > > accessing a file of large (>2*32) size, but not for using a swap space of > > large size. This is contrary to what I expected, but I don't know of > anyone > > commenting positively that LFS on a 32-bit machine does entail access to > > large swap. I wonder if any other minc-user might chime in? > > > > While on the subject, I wonder if you or any minc-user knows of anyone who > > compiled and used minc software on a 64-bit machine, or conversely of any > > problems going to a 64-bit platform? > > > > Best regards, > > > > Michel > > > > Michel Audette, Ph.D., > > Research Fellow, Surgical Simulation, > > Surgical Assist Group, > > AIST, > > Namiki 1-2, > > Tsukuba, Japan, > > 305-8564 > > > ----- Original Message ----- > > > From: "Andrew Janke" > > > To: "Michel Audette" > > > Sent: Monday, November 29, 2004 4:35 AM > > > Subject: Re: [MINC-users] voxel_loop-like hard-disk access for arbitrary > > > voxel positions > > > > > > > > > > On Fri, 26 Nov 2004, Michel Audette wrote: > > > > > > > > > I'm thinking of going with a LFS-ready Linux distribution with my > > 32-bit > > > > > machine: is this feasible to your knowledge? > > > > > > > > Feasible. The usuall tack is to use multiple swap partitions to get > to > > > the RAM > > > > requirements you are likely going to need. > > > > > > > > > > > > a > > > > > > From jason@bic.mni.mcgill.ca Mon Nov 29 11:55:03 2004 From: jason@bic.mni.mcgill.ca (Jason Lerch) Date: Mon Nov 29 11:55:03 2004 Subject: [MINC-users] Fw: voxel_loop-like hard-disk access for arbitrary voxel positions In-Reply-To: <000b01c4d6e8$ee331b60$07751d96@surgsim5> References: <000b01c4d6e8$ee331b60$07751d96@surgsim5> Message-ID: <4F7B2555-4227-11D9-8B6E-000A95DBBFD8@bic.mni.mcgill.ca> >>> >>> While on the subject, I wonder if you or any minc-user knows of >>> anyone > who >>> compiled and used minc software on a 64-bit machine, or conversely of > any >>> problems going to a 64-bit platform? We've run 64-bit MINC on the SGIs before, and it now works without any problems (well, any known problems). I think the patches are in MINC 1.2 and later. So that is certainly an option available to you. I see no reason why it wouldn't work on any other 64-bit system either. Cheers, Jason