From crioux@student.cs.uwaterloo.ca Wed Jun 2 14:53:04 2004 From: crioux@student.cs.uwaterloo.ca (crioux) Date: Wed Jun 2 13:53:04 2004 Subject: [MINC-users] Problems installing Display on Fedora -- undefined reference to `__ctype_b' In-Reply-To: References: Message-ID: Thanks Robert, Steve. Recompilling netCDF from scratch indeed fixed the problem. Just so the information is out there, when trying to compile Display I ran into a similar problem, from libbicpl.a this time: "undefined reference to `ppm_writeppminit'" Recompiling BICPL from scratch fixed this one too. Thanks again, Caroline On Mon, 31 May 2004, Robert VINCENT wrote: > I believe that the preferred workaround for this problem is to recompile > netCDF from the sources. > > See the following reference from the netCDF website: > > http://www.unidata.ucar.edu/cgi-bin/msgout?/glimpse/netcdf/5327 > > -bert > > On Sun, 30 May 2004, Steve ROBBINS wrote: > > > On Fri, May 28, 2004 at 02:53:22PM -0400, crioux wrote: > > > > > configure:20894: checking for ncopen in -lnetcdf > > > configure:20924: gcc -o conftest -g -O2 -I/usr/local/mni/include > > > -L/usr/local/mni/lib conftest.c -lnetcdf -lm >&5 > > > /usr/local/mni/lib/libnetcdf.a(string.o)(.text+0x62): In function > > > `NC_check_name': > > > : undefined reference to `__ctype_b' > > > collect2: ld returned 1 exit status > > [...] > > > > > Now I've looked around for similar problems, and have found this: > > > > > and this fix: > > > http://oss.sgi.com/archives/info-inventor-dev/2004-02/msg00004.html > > > > > > > Is this my problem? > > > > I'm not using Redhat myself, but I suspect that is your problem. > > > > Do I have to build such a workaround? > > > > I would guess so. Or perhaps it suffices to recompile netcdf. > > > > -S > > > > _______________________________________________ > > MINC-users@bic.mni.mcgill.ca > > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > > > From rotor@cmr.uq.edu.au Thu Jun 3 10:20:04 2004 From: rotor@cmr.uq.edu.au (Andrew Janke) Date: Thu Jun 3 09:20:04 2004 Subject: [MINC-users] "Not implemented yet in cache_volume_range_has_chang ed()" In-Reply-To: References: Message-ID: On Sun, 30 May 2004 adamt-pub@fmrif.nimh.nih.gov wrote: > Was there a solution posted for the problem Max posted back in January > (attached below)? I am encountering the same problem with minctracc: > > [adamt@aurum sk-2004-05-27]$ minctracc -verbose 5 -lsq6 -tricubic -step > 0.4 0.4 0.4 -mi sk-2004-05-27_3.mnc sk-2004-05-27_2.mnc > sk-2004-05-27_3to2.xfm > (snip) > .................................................................. > Not implemented yet in cache_volume_range_has_changed() > WARNING: target volume not UNSIGNED_BYTE, will do conversion now. > Converting: > .................................................................. > Not implemented yet in cache_volume_range_has_changed() > Segmentation fault Adam, First, It's likely that the "Not implemented in ..." looking error is not an error at all. And thus might be throwwing you off. This is an old debugging type statement that was never removed from the code. If your problem is indeed only apparent when you use larger volumes you may be hitting the volume_io caching limit. (and caching can be a bit flaky in volume_io, best to let the OS look after such things...) So if you read the volume_io Documentation, you'll note a environment variable: VOLUME_CACHE_THRESHOLD. Perhaps try increasing this to something (very) large, this will force volume_io to never cache (internally) -- Andrew Janke ( rotorATcmr.uq.edu.au || www.cmr.uq.edu.au/~rotor ) Australia->University of Queensland->Centre for Magnetic Resonance W: +61 7 3232 7254 || H: +61 7 3800 4042 || M: +61 4 2138 8581 From danahe.paquin-ricard@UMontreal.CA Thu Jun 3 22:45:05 2004 From: danahe.paquin-ricard@UMontreal.CA (=?iso-8859-1?b?RGFuYWjp?= Paquin-Ricard) Date: Thu Jun 3 21:45:05 2004 Subject: [MINC-users] Maximum frames in a 4D minc file Message-ID: <1086034875.40bb93bb12aff@www.courrier.umontreal.ca> Hi, is there a maximum of frames that we can put in a 4D minc file? I put many 3D minc files together to have a 4D minc file. Up to 200 frames, it works, but not with 300 frames or more... It seem that the maximum is around 250 frames. Why? Can I change it? Thanks, Danahe Paquin-Ricard From bert@bic.mni.mcgill.ca Fri Jun 4 11:47:04 2004 From: bert@bic.mni.mcgill.ca (Robert VINCENT) Date: Fri Jun 4 10:47:04 2004 Subject: [MINC-users] Maximum frames in a 4D minc file In-Reply-To: <1086034875.40bb93bb12aff@www.courrier.umontreal.ca> Message-ID: Danahe, There should be no fixed limit. How large are the frames? What tool are you using to add them to the MINC file? -bert On Mon, 31 May 2004, [iso-8859-1] Danahé Paquin-Ricard wrote: > Hi, > is there a maximum of frames that we can put in a 4D minc file? > > I put many 3D minc files together to have a 4D minc file. Up to 200 frames, it > works, but not with 300 frames or more... It seem that the maximum is around > 250 frames. Why? Can I change it? > > Thanks, > Danahe Paquin-Ricard > > _______________________________________________ > MINC-users@bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > From bert@bic.mni.mcgill.ca Mon Jun 7 11:41:09 2004 From: bert@bic.mni.mcgill.ca (Robert VINCENT) Date: Mon Jun 7 10:41:09 2004 Subject: [MINC-users] new minc 2.0 beta Message-ID: Hi everyone, A new MINC 2.0 beta release is available for all interested parties. This is build 2.0.07. This release fixes several data portability issues between big-endian and little-endian machines. All existing MINC 2.0 format files _should_ be readable in the new library. You can download this version at: http://www.bic.mni.mcgill.ca/~bert/minc-2.0.07.tar.gz for more information see the NEWS and ChangeLog in the release, and visit the new MINC web page: http://www.bic.mni.mcgill.ca/software/minc/ Please send any problems, requests, or bug reports to me. Thanks! -bert From colliot@bic.mni.mcgill.ca Mon Jun 7 17:05:04 2004 From: colliot@bic.mni.mcgill.ca (Olivier Colliot) Date: Mon Jun 7 16:05:04 2004 Subject: [MINC-users] "Silent" start_volume_input Message-ID: <40C4CC78.2000704@bic.mni.mcgill.ca> Hi, Is there a way to ask the function "start_volume_input" to stay "silent" ? i.e. to prevent it from outputting messages like "Error: opening MINC file" to stderr ? Thanks, Olivier From bert@bic.mni.mcgill.ca Mon Jun 7 17:31:03 2004 From: bert@bic.mni.mcgill.ca (Robert VINCENT) Date: Mon Jun 7 16:31:03 2004 Subject: [MINC-users] "Silent" start_volume_input In-Reply-To: <40C4CC78.2000704@bic.mni.mcgill.ca> Message-ID: Olivier, The easiest way I see to do this would be to define a function like: void my_print_error(char *message) { /* do nothing */ } Then call the function "set_print_error_function(my_print_error);" somewhere before you call start_volume_input(). This tells the library to -bert On Mon, 7 Jun 2004, Olivier Colliot wrote: > Hi, > > Is there a way to ask the function "start_volume_input" to stay "silent" ? > i.e. to prevent it from outputting messages like "Error: opening MINC > file" to stderr ? > > Thanks, > Olivier > > > _______________________________________________ > MINC-users@bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > From thomas_mitchell2@merck.com Tue Jun 8 10:46:05 2004 From: thomas_mitchell2@merck.com (Mitchell, Thomas William (WP)) Date: Tue Jun 8 09:46:05 2004 Subject: [MINC-users] MNI Display Message-ID: <94182F9BC86E27468CEFA770034DF9E8035A52B5@uswpmx15.merck.com> I am using the Windows version of MNI Display. My question has to do with segmentation of MRI slices. When I segment a slice, and for example, have more than one label (a green label or red label with separate voxel values and separate areas), once I save that slice, and at a later date re-open that slice, now the two separate labels and associated separate voxel and area values are now combined into one label (default red) and one combined voxel and area value. I understand that the Linux version does not do this. Is this a problem with the Windows version or am I doing something incorrect? Thanks. Tom ------------------------------------------------------- Thomas W. Mitchell, V.M.D., Ph.D. Merck & Co., Inc. ------------------------------------------------------------------------------ Notice: This e-mail message, together with any attachments, contains information of Merck & Co., Inc. (One Merck Drive, Whitehouse Station, New Jersey, USA 08889), and/or its affiliates (which may be known outside the United States as Merck Frosst, Merck Sharp & Dohme or MSD and in Japan, as Banyu) that may be confidential, proprietary copyrighted and/or legally privileged. It is intended solely for the use of the individual or entity named on this message. If you are not the intended recipient, and have received this message in error, please notify us immediately by reply e-mail and then delete it from your system. ------------------------------------------------------------------------------ From najma@bic.mni.mcgill.ca Sat Jun 12 00:48:04 2004 From: najma@bic.mni.mcgill.ca (Najmeh Khalili M.) Date: Fri Jun 11 23:48:04 2004 Subject: [MINC-users] Voxelwise P-values for T-maps. In-Reply-To: Message-ID: Hi, Is there already a minc-tool to calculate the p-values of a t-stat volume? (Notwithstanding Bonferroni correction or multiple hypothesis testing) Thanks. Najma From mchung@stat.wisc.edu Sat Jun 12 01:01:04 2004 From: mchung@stat.wisc.edu (Moo Chung) Date: Sat Jun 12 00:01:04 2004 Subject: [MINC-users] Voxelwise P-values for T-maps. In-Reply-To: References: Message-ID: Keith's FMRISTAT package does that in MATLAB. On Fri, 11 Jun 2004, Najmeh Khalili M. wrote: > > Hi, > > Is there already a minc-tool to calculate the p-values of a t-stat volume? > (Notwithstanding Bonferroni correction or multiple hypothesis testing) > > Thanks. > Najma > > _______________________________________________ > MINC-users@bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > MOo K. Chung http://www.stat.wisc.edu/~mchung Assistant Professor cell: 608-217-2452 Department of Statistics Department of Biostatistics and Medical Informatics W.M. Keck Laboratory for Functional Brain Imaging and Behavior University of Wisconsin-Madison The better work men do is always done under stress and at great personal cost. - W. C. Williams From najma@bic.mni.mcgill.ca Sat Jun 12 01:13:06 2004 From: najma@bic.mni.mcgill.ca (Najmeh Khalili M.) Date: Sat Jun 12 00:13:06 2004 Subject: [MINC-users] Voxelwise P-values for T-maps. In-Reply-To: Message-ID: Yes, but it doesn't generate a volume of p-values, or am I missing/overlooking a function? Thanks, Najma > Keith's FMRISTAT package does that in MATLAB. > > On Fri, 11 Jun 2004, Najmeh Khalili M. wrote: > > > > > Hi, > > > > Is there already a minc-tool to calculate the p-values of a t-stat volume? > > (Notwithstanding Bonferroni correction or multiple hypothesis testing) > > > > Thanks. > > Najma > > > > _______________________________________________ > > MINC-users@bic.mni.mcgill.ca > > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > > > > MOo K. Chung http://www.stat.wisc.edu/~mchung > Assistant Professor cell: 608-217-2452 > Department of Statistics > Department of Biostatistics and Medical Informatics > W.M. Keck Laboratory for Functional Brain Imaging and Behavior > University of Wisconsin-Madison > > The better work men do is always done under stress and > at great personal cost. - W. C. Williams > _______________________________________________ > MINC-users@bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > ________________________________________________________________ Najmeh Khalili M. McConnell Brain Imaging Center, Montreal Neurological Institute tel: (514) 276-5921 3801 University St., Montreal H3A 2B4 ________________________________________________________________ Reason has always existed, but not always in a reasonable form. Karl Marx From ali.soleymani@mail.mcgill.ca Mon Jun 14 15:25:05 2004 From: ali.soleymani@mail.mcgill.ca (Ali Soleymani) Date: Mon Jun 14 14:25:05 2004 Subject: [MINC-users] (no subject) Message-ID: <1087237213.40cdec5d18cbf@www.webmail.mcgill.ca> Hello everyone, I would like to save different pictures in register or Display as jpeg. ( Operating system is linux redhat). What is the simplest way to do this ? ( I have already tried the GIMP, screen capture, ... but these programs are only able to capture the whole window of register or Display and not an individual picture.) Thanks Ali From rotor@cmr.uq.edu.au Mon Jun 14 22:17:05 2004 From: rotor@cmr.uq.edu.au (Andrew Janke) Date: Mon Jun 14 21:17:05 2004 Subject: [MINC-users] (no subject) In-Reply-To: <1087237213.40cdec5d18cbf@www.webmail.mcgill.ca> References: <1087237213.40cdec5d18cbf@www.webmail.mcgill.ca> Message-ID: On Mon, 14 Jun 2004, Ali Soleymani wrote: > I would like to save different pictures in register or Display as jpeg. There is actually an undocumented magic incantation of key-presses or something to do this. However at the current moment it escapes me.. ;( I'm hoping someone who does remember this incantation will contribute here though... > What is the simplest way to do this ? However the way I usually do this is to use mincpik on the Command line after reading off the slice number from within register. ie: mincpik -image_range 23.5 100.6 -slice 12 -coronal in.mnc slice.png -- Andrew Janke ( rotorATcmr.uq.edu.au || www.cmr.uq.edu.au/~rotor ) Australia->University of Queensland->Centre for Magnetic Resonance W: +61 7 3232 7254 || H: +61 7 3800 4042 || M: +61 4 2138 8581 From jason@bic.mni.mcgill.ca Tue Jun 15 09:59:05 2004 From: jason@bic.mni.mcgill.ca (Jason Lerch) Date: Tue Jun 15 08:59:05 2004 Subject: [MINC-users] (no subject) In-Reply-To: References: <1087237213.40cdec5d18cbf@www.webmail.mcgill.ca> Message-ID: On Jun 14, 2004, at 9:16 PM, Andrew Janke wrote: > On Mon, 14 Jun 2004, Ali Soleymani wrote: > >> I would like to save different pictures in register or Display as >> jpeg. > > There is actually an undocumented magic incantation of key-presses or > something > to do this. However at the current moment it escapes me.. ;( I'm > hoping someone > who does remember this incantation will contribute here though... In register, hold your mouse cursor over a slice window and press "shift+g"; this only works in versions that have been compiled against libbicpl which in turn was compiled against either SGI's image library or libppm. In Display, go to the file menu and then press "G" for "Save Slice Window". You can then use the command line function "convert" to get the results into jpeg. > >> What is the simplest way to do this ? > > However the way I usually do this is to use mincpik on the Command > line after > reading off the slice number from within register. ie: > > mincpik -image_range 23.5 100.6 -slice 12 -coronal in.mnc slice.png > > > -- > Andrew Janke ( rotorATcmr.uq.edu.au || www.cmr.uq.edu.au/~rotor ) > Australia->University of Queensland->Centre for Magnetic Resonance > W: +61 7 3232 7254 || H: +61 7 3800 4042 || M: +61 4 2138 8581 > _______________________________________________ > MINC-users@bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users From jchen@bic.mni.mcgill.ca Tue Jun 15 16:39:04 2004 From: jchen@bic.mni.mcgill.ca (Jeni Chen) Date: Tue Jun 15 15:39:04 2004 Subject: [MINC-users] (no subject) In-Reply-To: <1087237213.40cdec5d18cbf@www.webmail.mcgill.ca> Message-ID: Ali, Actually GIMP does allow you to take individual pictures. Once you take the screenshot of the whole window, select the crop tool, then while holding down the ctrl key, use the left mouse button to drag and select the picture you want to take, then double click and voila. You can then save the picture in any format that's available from the menu. Jeni chen Agente de Recherche Centre de Recherche en Sciences Neurologiques Pavillon Paul Desmarais, Universit de Montral C.P. 6128, Succ. A, Montral, QC H3C 3J7 Tel:(514) 343-6111 ext.4359 Fax:(514) 343-2111 On Mon, 14 Jun 2004, Ali Soleymani wrote: > > > Hello everyone, > I would like to save different pictures in register or Display as jpeg. ( > Operating system is linux redhat). > What is the simplest way to do this ? > ( I have already tried the GIMP, screen capture, ... but these programs are only > able to capture the whole window of register or Display and not an individual > picture.) > Thanks > Ali > > _______________________________________________ > MINC-users@bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users From yves.roy@umontreal.ca Thu Jun 17 13:24:04 2004 From: yves.roy@umontreal.ca (Roy Yves) Date: Thu Jun 17 12:24:04 2004 Subject: [MINC-users] ana2mnc for fMRI Message-ID: Hello, Is there already a script converting 3D FMRI frames from analyse to a 4D minc volume? Thanks Yves From pgravel@bic.mni.mcgill.ca Mon Jun 21 12:08:04 2004 From: pgravel@bic.mni.mcgill.ca (Paul GRAVEL) Date: Mon Jun 21 11:08:04 2004 Subject: [MINC-users] Automated Segmentation Questions Message-ID: Hi All, I am not sure if this is the appropriate mailing list to send these questions(bottom of e-mail) to, but I will ask them anyway. Please let me know if I should send them to another mailing list. I have 42 subjects that I needed to segment into several ROI's. I used the procedure displayed on Dr. Louis Collins Web Page (http://www.bic.mni.mcgill.ca/users/louis/pet_segment) The procedure is as followed: Step 1: mritotal $arg1'_mri.mnc' $arg1'_mri_stx_lin.xfm' Step 2: nu_correct $arg1'_mri.mnc' $arg1'_mri_nuc.mnc' Step 3: mritotal -nonlinear $arg1'_mri_nuc.mnc' -transformation $arg1'_mri_stx_lin.xfm' $arg1'_mri_stx_nonlin.xfm' Step 4a: mincresample -like /avgbrain/brain/images/icbm_template_1.00mm.mnc $arg1'_mri_nuc.mnc' -transformation $arg1'_mri_stx_lin.xfm' $arg1'_mri_stx_nuc.mnc' Step 4b: classify_clean $arg1'_mri_stx_nuc.mnc' $arg1'_mri_stx_classes.mnc' Step 5: stx_segment $arg1'_mri_stx_nonlin.xfm' $arg1'_mri_stx_lin.xfm' $arg1'_mri_stx_classes.mnc' $arg1'_mri_stx_labels.mnc' My questions are as followed: 1 - Is this still the best procedure to do segmentation? 2 - Is step 2(nu_correct) based on the N3 Algorithm, if not which algorithm is it based on? 3 - Is step 4b(classify_clean) based on the INSECT (Intensity Normalized Stereotaxic Environment for the Classification of Tissue) Algorithm, if not which algorithm is it based on? 4 - Is step 5(stx_segment) based on the ANIMAL (Automatic Nonlinear Imaging Matching and Anatomical Labelling) Algorithm, if not which algorithm is it based on? I thank you very much in advance. Best Regards, Paul ______________________________ Paul Gravel Neurobiological Psychiatry Unit McGill University 1033 Pine Avenue West Montreal, Quebec, Canada, H3A 1A1 Phone: (514) 398-7301 Fax: (514) 398-4866 From louis@bic.mni.mcgill.ca Mon Jun 21 21:30:04 2004 From: louis@bic.mni.mcgill.ca (D. Louis Collins) Date: Mon Jun 21 20:30:04 2004 Subject: [MINC-users] Automated Segmentation Questions In-Reply-To: References: Message-ID: <49C1A2CE-C3E3-11D8-A810-000D93520AA0@bic.mni.mcgill.ca> Paul, The procedure described on my web site is still valid, however, many of the programs have been updated and yield better results now. Answers are below. -Louis On Jun 21, 2004, at 11:07 AM, Paul GRAVEL wrote: > Hi All, > > I am not sure if this is the appropriate mailing list to send these > questions(bottom of e-mail) to, but I will ask them anyway. Please > let me > know if I should send them to another mailing list. > > I have 42 subjects that I needed to segment into several ROI's. > I used the procedure displayed on Dr. Louis Collins Web Page > (http://www.bic.mni.mcgill.ca/users/louis/pet_segment) > > The procedure is as followed: > > Step 1: mritotal $arg1'_mri.mnc' $arg1'_mri_stx_lin.xfm' > > Step 2: nu_correct $arg1'_mri.mnc' $arg1'_mri_nuc.mnc' > > Step 3: mritotal -nonlinear $arg1'_mri_nuc.mnc' -transformation > $arg1'_mri_stx_lin.xfm' $arg1'_mri_stx_nonlin.xfm' > > Step 4a: mincresample -like > /avgbrain/brain/images/icbm_template_1.00mm.mnc > $arg1'_mri_nuc.mnc' -transformation $arg1'_mri_stx_lin.xfm' > $arg1'_mri_stx_nuc.mnc' > > Step 4b: classify_clean $arg1'_mri_stx_nuc.mnc' > $arg1'_mri_stx_classes.mnc' > > Step 5: stx_segment $arg1'_mri_stx_nonlin.xfm' $arg1'_mri_stx_lin.xfm' > $arg1'_mri_stx_classes.mnc' $arg1'_mri_stx_labels.mnc' > > > My questions are as followed: > > 1 - Is this still the best procedure to do segmentation? pretty much. ANIMAL now uses the ICBM152 model for more robust linear registrations. > 2 - Is step 2(nu_correct) based on the N3 Algorithm, if not which > algorithm is it based on? this is based on N3, the method of John Sled. > 3 - Is step 4b(classify_clean) based on the INSECT (Intensity > Normalized > Stereotaxic Environment for the Classification of Tissue) Algorithm, if > not which algorithm is it based on? classify_clean is a perl script that uses both bayesian and artificial neural nets for classification and is based on INSECT. > 4 - Is step 5(stx_segment) based on the ANIMAL (Automatic Nonlinear > Imaging Matching and Anatomical Labelling) Algorithm, if not which > algorithm is it based on? step 5, stx_segment, takes the output of the linear and non-linear registrations and combines it with the classified data to achieve a segmentation. The entire procedure, registrations+classifications is ANIMAL. Hope this helps, -L > > I thank you very much in advance. > > Best Regards, > > Paul > ______________________________ > > Paul Gravel > Neurobiological Psychiatry Unit > McGill University > 1033 Pine Avenue West > Montreal, Quebec, Canada, H3A 1A1 > Phone: (514) 398-7301 > Fax: (514) 398-4866 > > > > > _______________________________________________ > MINC-users@bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users From cjb@pet.auh.dk Fri Jun 25 09:55:04 2004 From: cjb@pet.auh.dk (Christopher Bailey) Date: Fri Jun 25 08:55:04 2004 Subject: [MINC-users] mincconcat: 3D->4D or 4D-4D ? Message-ID: Dear MINC-users, I am trying to concatenate 3D volumes (frames of a dynamic PET scan) into a 4D one. Below is the call to mincconcat; I give the frame start times and widths with -coordlist and -widhtlist. As you can see, the sampling is irregular. >>> mincconcat -clobber -concat_dimension time -coordlist "0,15,30,45,60,90,120,180,240,300,450,600,900,1200,1500,1800,2400,3000,3600,4200,4800" -widthlist "15,15,15,15,30,30,60,60,60,150,150,300,300,300,300,600,600,600,600,600,599" /tmp/frame1.mnc /tmp/frame2.mnc /tmp/frame3.mnc /tmp/frame4.mnc /tmp/frame5.mnc /tmp/frame6.mnc /tmp/frame7.mnc /tmp/frame8.mnc /tmp/frame9.mnc /tmp/frame10.mnc /tmp/frame11.mnc /tmp/frame12.mnc /tmp/frame13.mnc /tmp/frame14.mnc /tmp/frame15.mnc /tmp/frame16.mnc /tmp/frame17.mnc /tmp/frame18.mnc /tmp/frame19.mnc /tmp/frame20.mnc output.mnc <<< Doing a mincinfo on output.mnc, I get image dimensions: time zspace yspace xspace dimension name length step start -------------- ------ ---- ----- time 21 240 0 zspace 63 0.12115 0 yspace 128 0.0845247 0 xspace 128 0.0845247 0 Why is there a step and a start for the time dimension? All the original frames were 3D, the starts and widths were given as lists. A mincheader on the same files has the following: <<< double time(time) ; time:varid = "MINC standard variable" ; time:vartype = "dimension____" ; time:version = "MINC Version 1.0" ; time:spacing = "irregular" ; time:alignment = "start_" ; time:start = 0. ; time:step = 240. ; double time-width(time) ; time-width:varid = "MINC standard variable" ; time-width:vartype = "dim-width____" ; time-width:version = "MINC Version 1.0" ; time-width:spacing = "irregular" ; time-width:filtertype = "square____" ; >>> So it realises the spacings are irregular and yet insists on having the time:start and time:step fields! Later in the header the "real" starts and widths appear (as "globals"?): <<< data: time = 0, 15, 30, 45, 60, 90, 120, 180, 240, 300, 450, 600, 900, 1200, 1500,1800, 2400, 3000, 3600, 4200, 4800 ; time-width = 15, 15, 15, 15, 30, 30, 60, 60, 60, 150, 150, 300, 300, 300, 300, 600, 600, 600, 600, 600, 599 ; >>> Now I'm not sure this will ever cause me problems, but it is a peculiar "feature", no? Can I be sure none of the MINC tools get confused about this matter, screwing up the timing info? Best, Chris Bailey Center for Functionally Integrative Neuroscience Aarhus General Hospital, Denmark From cjb@pet.auh.dk Fri Jun 25 10:11:04 2004 From: cjb@pet.auh.dk (Christopher Bailey) Date: Fri Jun 25 09:11:04 2004 Subject: [MINC-users] Register and Display: internal representation? Message-ID: Dear MINC-users, I want to subtract one 3D (frame) from another: newframe = frame1 - frame0 I use mincmath as follows (correct?): mincmath -sub frame1 frame0 newframe Both frames are signed floats with slightly different ranges (0->2e5 and 0->2e6) and are coregistered. They both contain lots of zeros at the edges of the image. When I open "newframe" in either register or Display, those same voxels that should still be zero, now have a mysterious value of -185.253! Doing the subtraction the other way round yields +185.253. I opened "newframe" in AFNI, which DID show zeros in the edge voxels! I also did a mnc2ana on the file and looked at it in mricro---again zeros on the edges as it should be. So what is going on with register and Display? We have concluded it must be an internal representation issue, but I would still like comments on this. I'm of course concerned about doing further analysis on these files---I want zero to be zero! All the best, Chris Bailey Center for Functionally Integrative Neuroscience Aarhus General Hospital, Denmark From bert@bic.mni.mcgill.ca Fri Jun 25 10:39:04 2004 From: bert@bic.mni.mcgill.ca (Robert VINCENT) Date: Fri Jun 25 09:39:04 2004 Subject: [MINC-users] mincconcat: 3D->4D or 4D-4D ? In-Reply-To: Message-ID: Christopher, It should be harmless to define a step and start for an irregular dimension. mincconcat sets the step value for irregular dimensions to a mean value, which is calculated as (end - begin) / (length - 1), so that explains the 240 value. This is actually part of the MINC specification. -bert On Fri, 25 Jun 2004, Christopher Bailey wrote: > > Dear MINC-users, > > I am trying to concatenate 3D volumes (frames of a dynamic PET scan) into > a 4D one. Below is the call to mincconcat; I give the frame start times > and widths with -coordlist and -widhtlist. As you can see, the sampling is > irregular. > > >>> > mincconcat -clobber -concat_dimension time -coordlist > "0,15,30,45,60,90,120,180,240,300,450,600,900,1200,1500,1800,2400,3000,3600,4200,4800" > -widthlist > "15,15,15,15,30,30,60,60,60,150,150,300,300,300,300,600,600,600,600,600,599" > /tmp/frame1.mnc /tmp/frame2.mnc /tmp/frame3.mnc /tmp/frame4.mnc > /tmp/frame5.mnc /tmp/frame6.mnc /tmp/frame7.mnc /tmp/frame8.mnc > /tmp/frame9.mnc /tmp/frame10.mnc /tmp/frame11.mnc /tmp/frame12.mnc > /tmp/frame13.mnc /tmp/frame14.mnc /tmp/frame15.mnc /tmp/frame16.mnc > /tmp/frame17.mnc /tmp/frame18.mnc /tmp/frame19.mnc /tmp/frame20.mnc > output.mnc > <<< > > Doing a mincinfo on output.mnc, I get > > image dimensions: time zspace yspace xspace > dimension name length step start > -------------- ------ ---- ----- > time 21 240 0 > zspace 63 0.12115 0 > yspace 128 0.0845247 0 > xspace 128 0.0845247 0 > > Why is there a step and a start for the time dimension? All the original > frames were 3D, the starts and widths were given as lists. A mincheader on > the same files has the following: > <<< > double time(time) ; > time:varid = "MINC standard variable" ; > time:vartype = "dimension____" ; > time:version = "MINC Version 1.0" ; > time:spacing = "irregular" ; > time:alignment = "start_" ; > time:start = 0. ; > time:step = 240. ; > double time-width(time) ; > time-width:varid = "MINC standard variable" ; > time-width:vartype = "dim-width____" ; > time-width:version = "MINC Version 1.0" ; > time-width:spacing = "irregular" ; > time-width:filtertype = "square____" ; > >>> > > > So it realises the spacings are irregular and yet insists on having the > time:start and > time:step > fields! Later in the header the "real" starts and widths appear (as > "globals"?): > > <<< > data: > > time = 0, 15, 30, 45, 60, 90, 120, 180, 240, 300, 450, 600, 900, 1200, > 1500,1800, 2400, 3000, 3600, 4200, 4800 ; > > time-width = 15, 15, 15, 15, 30, 30, 60, 60, 60, 150, 150, 300, 300, 300, > 300, 600, 600, 600, 600, 600, 599 ; > >>> > > Now I'm not sure this will ever cause me problems, but it is a peculiar > "feature", no? Can I be sure none of the MINC tools get confused about > this matter, screwing up the timing info? > > Best, > > Chris Bailey > Center for Functionally Integrative Neuroscience > Aarhus General Hospital, Denmark > > _______________________________________________ > MINC-users@bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > From bert@bic.mni.mcgill.ca Fri Jun 25 10:45:04 2004 From: bert@bic.mni.mcgill.ca (Robert VINCENT) Date: Fri Jun 25 09:45:04 2004 Subject: [MINC-users] Register and Display: internal representation? In-Reply-To: Message-ID: Christopher, I'm not certain what's going on here, but it could be that the valid_range attribute is not set properly. Could you send me the output of mincinfo or mincheader on the input & output files? It might also be interesting to compare the results when performing the equivalent subtraction with minccalc. -bert On Fri, 25 Jun 2004, Christopher Bailey wrote: > > Dear MINC-users, > > I want to subtract one 3D (frame) from another: > > newframe = frame1 - frame0 > > I use mincmath as follows (correct?): > > mincmath -sub frame1 frame0 newframe > > Both frames are signed floats with slightly different ranges (0->2e5 and > 0->2e6) and are coregistered. They both contain lots of zeros at the edges > of the image. When I open "newframe" in either register or Display, those > same voxels that should still be zero, now have a mysterious value of > -185.253! Doing the subtraction the other way round yields +185.253. > > I opened "newframe" in AFNI, which DID show zeros in the edge voxels! I > also did a mnc2ana on the file and looked at it in mricro---again zeros > on the edges as it should be. > > So what is going on with register and Display? We have concluded it must > be an internal representation issue, but I would still like comments on > this. I'm of course concerned about doing further analysis on these > files---I want zero to be zero! > > All the best, > > Chris Bailey > Center for Functionally Integrative Neuroscience > Aarhus General Hospital, Denmark > > > > _______________________________________________ > MINC-users@bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > From cjb@pet.auh.dk Fri Jun 25 10:46:04 2004 From: cjb@pet.auh.dk (Christopher Bailey) Date: Fri Jun 25 09:46:04 2004 Subject: [MINC-users] Register and Display: internal representation? In-Reply-To: <6AA77A67-C6AA-11D8-AA55-000A95DBBFD8@bic.mni.mcgill.ca> Message-ID: Dear Jason, Thank you for you reply; print_world_value gives correct values. Do you know if postf behaves the same as register & Display? I don't have easy access to an IRIX... I suppose if one extracts a TAC using a VOI in postf, the underlying code uses the original file values instead of what postf shows on the screen. Thank you for your help, -Chris On Fri, 25 Jun 2004, Jason Lerch wrote: > The ranges matter in conjunction with the data type. register and > Display always open files as byte, so if the files are stored in a > different format, then this could be your answer. You can always create > a little mask of the voxels that you are interested in and use > mincstats to figure out the real values there. I think the command > print_world_value uses the volume's data-type as well. > > Cheers, > > Jason > > On Jun 25, 2004, at 9:10 AM, Christopher Bailey wrote: > > > > > Dear MINC-users, > > > > I want to subtract one 3D (frame) from another: > > > > newframe = frame1 - frame0 > > > > I use mincmath as follows (correct?): > > > > mincmath -sub frame1 frame0 newframe > > > > Both frames are signed floats with slightly different ranges (0->2e5 > > and > > 0->2e6) and are coregistered. They both contain lots of zeros at the > > edges > > of the image. When I open "newframe" in either register or Display, > > those > > same voxels that should still be zero, now have a mysterious value of > > -185.253! Doing the subtraction the other way round yields +185.253. > > > > I opened "newframe" in AFNI, which DID show zeros in the edge voxels! I > > also did a mnc2ana on the file and looked at it in mricro---again zeros > > on the edges as it should be. > > > > So what is going on with register and Display? We have concluded it > > must > > be an internal representation issue, but I would still like comments on > > this. I'm of course concerned about doing further analysis on these > > files---I want zero to be zero! > > > > All the best, > > > > Chris Bailey > > Center for Functionally Integrative Neuroscience > > Aarhus General Hospital, Denmark > > > > > > > > _______________________________________________ > > MINC-users@bic.mni.mcgill.ca > > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > > From cjb@pet.auh.dk Fri Jun 25 10:56:04 2004 From: cjb@pet.auh.dk (Christopher Bailey) Date: Fri Jun 25 09:56:04 2004 Subject: [MINC-users] Register and Display: internal representation? In-Reply-To: Message-ID: Hi Bert, I tried minccalc out with -expression (A[1]-A[0]) and got the same result as with mincmath. I'm inclined to believe this is not a big problem---as Jason pointed out it is a representation-issue. Thanks! -Chris On Fri, 25 Jun 2004, Robert VINCENT wrote: > Christopher, > > I'm not certain what's going on here, but it could be that the valid_range > attribute is not set properly. Could you send me the output of > mincinfo or mincheader on the input & output files? It might also be > interesting to compare the results when performing the equivalent > subtraction with minccalc. > > -bert > > On Fri, 25 Jun 2004, Christopher Bailey wrote: > > > > > Dear MINC-users, > > > > I want to subtract one 3D (frame) from another: > > > > newframe = frame1 - frame0 > > > > I use mincmath as follows (correct?): > > > > mincmath -sub frame1 frame0 newframe > > > > Both frames are signed floats with slightly different ranges (0->2e5 and > > 0->2e6) and are coregistered. They both contain lots of zeros at the edges > > of the image. When I open "newframe" in either register or Display, those > > same voxels that should still be zero, now have a mysterious value of > > -185.253! Doing the subtraction the other way round yields +185.253. > > > > I opened "newframe" in AFNI, which DID show zeros in the edge voxels! I > > also did a mnc2ana on the file and looked at it in mricro---again zeros > > on the edges as it should be. > > > > So what is going on with register and Display? We have concluded it must > > be an internal representation issue, but I would still like comments on > > this. I'm of course concerned about doing further analysis on these > > files---I want zero to be zero! > > > > All the best, > > > > Chris Bailey > > Center for Functionally Integrative Neuroscience > > Aarhus General Hospital, Denmark > > > > > > > > _______________________________________________ > > MINC-users@bic.mni.mcgill.ca > > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > > > > From colliot@bic.mni.mcgill.ca Fri Jun 25 12:30:04 2004 From: colliot@bic.mni.mcgill.ca (Olivier Colliot) Date: Fri Jun 25 11:30:04 2004 Subject: [MINC-users] minctracc writes into the "processing" variable instead of "history" attribute Message-ID: <40DC4662.3080602@bic.mni.mcgill.ca> Hi, Does anyone know why "minctracc", to store some history-like information, makes use of a variable named "processing" instead of the traditionnal "history" attribute ? Is this "processing" variable deprecated ? Thanks, Olivier From rotor@cmr.uq.edu.au Tue Jun 29 03:01:04 2004 From: rotor@cmr.uq.edu.au (Andrew Janke) Date: Tue Jun 29 02:01:04 2004 Subject: [MINC-users] minctracc writes into the "processing" variable instead of "history" attribute In-Reply-To: <40DC4662.3080602@bic.mni.mcgill.ca> References: <40DC4662.3080602@bic.mni.mcgill.ca> Message-ID: On Fri, 25 Jun 2004, Olivier Colliot wrote: > Does anyone know why "minctracc", to store some history-like > information, makes use of a variable named "processing" instead of the > traditionnal "history" attribute ? I believe the original logic to this was that the typical minc file output of minctracc is a non-linear grid. The processing variable contained the contents of the linear affine xfm that was part of this (non-linear) transformation. I guess louis the plan here was that if the linear and non-linear part of a xfm got split up, then all you needed was the non-linear part to re-create the whole (admittedly, manually). > Is this "processing" variable deprecated ? Well, it never was part of any specification that I can remember. Any programmer/user is always going to be free to put any variable they like into the header and even more so in MINC 2.0! a