From trash001 at odu.edu Tue Sep 4 11:12:00 2012 From: trash001 at odu.edu (Tanweer Rashid) Date: Tue, 4 Sep 2012 11:12:00 -0400 Subject: [MINC-users] Length of a cell/voxel Message-ID: Hi, Can anyone tell me what function(s) to use to figure out the length of a cell or voxel in each spatial (x, y, z) dimension? Regards, -- Tanweer Rashid MSVE Dept. Old Dominion University From a.janke at gmail.com Tue Sep 4 11:20:29 2012 From: a.janke at gmail.com (Andrew Janke) Date: Wed, 5 Sep 2012 01:20:29 +1000 Subject: [MINC-users] Length of a cell/voxel In-Reply-To: References: Message-ID: Hi Tanweer, You can do this on the command line: $ mincinfo -attvalue xspace:step infile.mnc (and then for yspace and zspace). a On 5 September 2012 01:12, Tanweer Rashid wrote: > Hi, > > Can anyone tell me what function(s) to use to figure out the length of a > cell or voxel in each spatial (x, y, z) dimension? > > Regards, > -- > Tanweer Rashid > MSVE Dept. > Old Dominion University > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users From maudette at odu.edu Tue Sep 4 11:46:52 2012 From: maudette at odu.edu (Audette, Michel A.) Date: Tue, 4 Sep 2012 15:46:52 +0000 Subject: [MINC-users] Length of a cell/voxel In-Reply-To: References: , Message-ID: <22EC75E8215562428ACADFA35877A25A02F842@JANEWAY.ts.odu.edu> Hi Andrew, I think what Tanweer had in mind was how to get this information using a function within a program, not a command. I have not played with MINC programming lately, so what I used back in the day for MINC1 probably no longer applies to MINC2. Btw, does ITK support for MINC2 include this type of query? Cheers, Michel Michel Audette, Ph.D. Assistant Professor, Department of Modeling, Simulation and Visualization Engineering, Old Dominion University, Norfolk, VA. ________________________________________ From: minc-users-bounces at bic.mni.mcgill.ca [minc-users-bounces at bic.mni.mcgill.ca] on behalf of Andrew Janke [a.janke at gmail.com] Sent: Tuesday, September 04, 2012 11:20 AM To: MINC users mailing list Subject: Re: [MINC-users] Length of a cell/voxel Hi Tanweer, You can do this on the command line: $ mincinfo -attvalue xspace:step infile.mnc (and then for yspace and zspace). a On 5 September 2012 01:12, Tanweer Rashid wrote: > Hi, > > Can anyone tell me what function(s) to use to figure out the length of a > cell or voxel in each spatial (x, y, z) dimension? > > Regards, > -- > Tanweer Rashid > MSVE Dept. > Old Dominion University > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users _______________________________________________ MINC-users at bic.mni.mcgill.ca http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users -- BEGIN-ANTISPAM-VOTING-LINKS ------------------------------------------------------ Teach CanIt if this mail (ID 699327249) is spam: Spam: https://www.spamtrap.odu.edu/b.php?i=699327249&m=4da47c0ba936&t=20120904&c=s Not spam: https://www.spamtrap.odu.edu/b.php?i=699327249&m=4da47c0ba936&t=20120904&c=n Forget vote: https://www.spamtrap.odu.edu/b.php?i=699327249&m=4da47c0ba936&t=20120904&c=f ------------------------------------------------------ END-ANTISPAM-VOTING-LINKS From vladimir.fonov at gmail.com Tue Sep 4 11:53:59 2012 From: vladimir.fonov at gmail.com (Vladimir S. FONOV) Date: Tue, 4 Sep 2012 11:53:59 -0400 Subject: [MINC-users] Length of a cell/voxel In-Reply-To: <22EC75E8215562428ACADFA35877A25A02F842@JANEWAY.ts.odu.edu> References: <22EC75E8215562428ACADFA35877A25A02F842@JANEWAY.ts.odu.edu> Message-ID: Hello, in ITK you can get this information using GetSpacing() function of itk::Image On Tue, Sep 4, 2012 at 11:46 AM, Audette, Michel A. wrote: > Hi Andrew, > > I think what Tanweer had in mind was how to get this information using a function within a program, not a command. I have not played with MINC programming lately, so what I used back in the day for MINC1 probably no longer applies to MINC2. Btw, does ITK support for MINC2 include this type of query? > > Cheers, > > Michel > > Michel Audette, Ph.D. > Assistant Professor, > Department of Modeling, Simulation and Visualization Engineering, > Old Dominion University, > Norfolk, VA. > ________________________________________ > From: minc-users-bounces at bic.mni.mcgill.ca [minc-users-bounces at bic.mni.mcgill.ca] on behalf of Andrew Janke [a.janke at gmail.com] > Sent: Tuesday, September 04, 2012 11:20 AM > To: MINC users mailing list > Subject: Re: [MINC-users] Length of a cell/voxel > > Hi Tanweer, > > You can do this on the command line: > > $ mincinfo -attvalue xspace:step infile.mnc > > (and then for yspace and zspace). > > > a > > On 5 September 2012 01:12, Tanweer Rashid wrote: >> Hi, >> >> Can anyone tell me what function(s) to use to figure out the length of a >> cell or voxel in each spatial (x, y, z) dimension? >> >> Regards, >> -- >> Tanweer Rashid >> MSVE Dept. >> Old Dominion University >> _______________________________________________ >> MINC-users at bic.mni.mcgill.ca >> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > > > -- > BEGIN-ANTISPAM-VOTING-LINKS > ------------------------------------------------------ > > Teach CanIt if this mail (ID 699327249) is spam: > Spam: https://www.spamtrap.odu.edu/b.php?i=699327249&m=4da47c0ba936&t=20120904&c=s > Not spam: https://www.spamtrap.odu.edu/b.php?i=699327249&m=4da47c0ba936&t=20120904&c=n > Forget vote: https://www.spamtrap.odu.edu/b.php?i=699327249&m=4da47c0ba936&t=20120904&c=f > ------------------------------------------------------ > END-ANTISPAM-VOTING-LINKS > > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users -- Best regards, Vladimir S. Fonov ~ vladimir fonov gmail com From maudette at odu.edu Tue Sep 4 13:10:38 2012 From: maudette at odu.edu (Audette, Michel A.) Date: Tue, 4 Sep 2012 17:10:38 +0000 Subject: [MINC-users] Length of a cell/voxel In-Reply-To: References: <22EC75E8215562428ACADFA35877A25A02F842@JANEWAY.ts.odu.edu>, Message-ID: <22EC75E8215562428ACADFA35877A25A02F88D@JANEWAY.ts.odu.edu> Dear Vladimir, thanks for your kind reply. This seems like the most sensible approach. I've asked Tanweer to pursue this option. Best wishes, Michel Michel Audette, Ph.D. Assistant Professor, Department of Modeling, Simulation and Visualization Engineering, Old Dominion University, Norfolk, VA. ________________________________________ From: minc-users-bounces at bic.mni.mcgill.ca [minc-users-bounces at bic.mni.mcgill.ca] on behalf of Vladimir S. FONOV [vladimir.fonov at gmail.com] Sent: Tuesday, September 04, 2012 11:53 AM To: MINC users mailing list Subject: Re: [MINC-users] Length of a cell/voxel Hello, in ITK you can get this information using GetSpacing() function of itk::Image On Tue, Sep 4, 2012 at 11:46 AM, Audette, Michel A. wrote: > Hi Andrew, > > I think what Tanweer had in mind was how to get this information using a function within a program, not a command. I have not played with MINC programming lately, so what I used back in the day for MINC1 probably no longer applies to MINC2. Btw, does ITK support for MINC2 include this type of query? > > Cheers, > > Michel > > Michel Audette, Ph.D. > Assistant Professor, > Department of Modeling, Simulation and Visualization Engineering, > Old Dominion University, > Norfolk, VA. > ________________________________________ > From: minc-users-bounces at bic.mni.mcgill.ca [minc-users-bounces at bic.mni.mcgill.ca] on behalf of Andrew Janke [a.janke at gmail.com] > Sent: Tuesday, September 04, 2012 11:20 AM > To: MINC users mailing list > Subject: Re: [MINC-users] Length of a cell/voxel > > Hi Tanweer, > > You can do this on the command line: > > $ mincinfo -attvalue xspace:step infile.mnc > > (and then for yspace and zspace). > > > a > > On 5 September 2012 01:12, Tanweer Rashid wrote: >> Hi, >> >> Can anyone tell me what function(s) to use to figure out the length of a >> cell or voxel in each spatial (x, y, z) dimension? >> >> Regards, >> -- >> Tanweer Rashid >> MSVE Dept. >> Old Dominion University >> _______________________________________________ >> MINC-users at bic.mni.mcgill.ca >> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > > > -- > > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users -- Best regards, Vladimir S. Fonov ~ vladimir fonov gmail com _______________________________________________ MINC-users at bic.mni.mcgill.ca http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users -- BEGIN-ANTISPAM-VOTING-LINKS ------------------------------------------------------ Teach CanIt if this mail (ID 699336336) is spam: Spam: https://www.spamtrap.odu.edu/b.php?i=699336336&m=a221225e3932&t=20120904&c=s Not spam: https://www.spamtrap.odu.edu/b.php?i=699336336&m=a221225e3932&t=20120904&c=n Forget vote: https://www.spamtrap.odu.edu/b.php?i=699336336&m=a221225e3932&t=20120904&c=f ------------------------------------------------------ END-ANTISPAM-VOTING-LINKS From a.janke at gmail.com Tue Sep 4 21:18:45 2012 From: a.janke at gmail.com (Andrew Janke) Date: Wed, 5 Sep 2012 11:18:45 +1000 Subject: [MINC-users] Length of a cell/voxel In-Reply-To: <22EC75E8215562428ACADFA35877A25A02F842@JANEWAY.ts.odu.edu> References: <22EC75E8215562428ACADFA35877A25A02F842@JANEWAY.ts.odu.edu> Message-ID: Ah. Well that changes things. In MINC2 you'd do this like this: http://en.wikibooks.org/wiki/MINC/Reference/MINC2.0_Application_Programmers_Interface#miget_dimension_separation.2Fmiset_dimension_separation There is a very similar example bit of code here: http://en.wikibooks.org/wiki/MINC/Tutorials/Programming04 In which the volume sizes (not steps) are extracted. a On 5 September 2012 01:46, Audette, Michel A. wrote: > Hi Andrew, > > I think what Tanweer had in mind was how to get this information using a function within a program, not a command. I have not played with MINC programming lately, so what I used back in the day for MINC1 probably no longer applies to MINC2. Btw, does ITK support for MINC2 include this type of query? > > Cheers, > > Michel > > Michel Audette, Ph.D. > Assistant Professor, > Department of Modeling, Simulation and Visualization Engineering, > Old Dominion University, > Norfolk, VA. > ________________________________________ > From: minc-users-bounces at bic.mni.mcgill.ca [minc-users-bounces at bic.mni.mcgill.ca] on behalf of Andrew Janke [a.janke at gmail.com] > Sent: Tuesday, September 04, 2012 11:20 AM > To: MINC users mailing list > Subject: Re: [MINC-users] Length of a cell/voxel > > Hi Tanweer, > > You can do this on the command line: > > $ mincinfo -attvalue xspace:step infile.mnc > > (and then for yspace and zspace). > > > a > > On 5 September 2012 01:12, Tanweer Rashid wrote: >> Hi, >> >> Can anyone tell me what function(s) to use to figure out the length of a >> cell or voxel in each spatial (x, y, z) dimension? >> >> Regards, >> -- >> Tanweer Rashid >> MSVE Dept. >> Old Dominion University >> _______________________________________________ >> MINC-users at bic.mni.mcgill.ca >> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > > > -- > BEGIN-ANTISPAM-VOTING-LINKS > ------------------------------------------------------ > > Teach CanIt if this mail (ID 699327249) is spam: > Spam: https://www.spamtrap.odu.edu/b.php?i=699327249&m=4da47c0ba936&t=20120904&c=s > Not spam: https://www.spamtrap.odu.edu/b.php?i=699327249&m=4da47c0ba936&t=20120904&c=n > Forget vote: https://www.spamtrap.odu.edu/b.php?i=699327249&m=4da47c0ba936&t=20120904&c=f > ------------------------------------------------------ > END-ANTISPAM-VOTING-LINKS > > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users From pfannmoelj at uni-greifswald.de Thu Sep 6 06:12:14 2012 From: pfannmoelj at uni-greifswald.de (=?ISO-8859-1?Q?J=F6rg_Pfannm=F6ller?=) Date: Thu, 6 Sep 2012 12:12:14 +0200 Subject: [MINC-users] Conversion to MINC and visual inspection of the MINC-file Message-ID: <20120906121214.45fe768c.pfannmoelj@uni-greifswald.de> Dear MINC-Experts, I am attempting to convert 16 bit images of a mouse brain in tif format (example image attached as number 01) to minc format. Therefore, I use imageJ to convert the original .tif data to .raw data. After that the following command is used to convert the .raw file to an .mnc file: rawtominc -input t2_3D_tse_3-wt2.raw -transverse -short -unsigned -ounsigned -xstep 0.0244140625 -ystep 0.0244140625 -zstep 0.10000000149 -mri -origin 0 0 0 -range 0 65535 -real_range 0 65535 -clobber mydata.mnc 96 1024 1024 Subsequently mydata.mnc is converted to .raw format using: minctoraw -short -nonormalize mydata.mnc > mydata.raw This is displayed in imageJ and seem to be correct (example image attached as number 02) If mydata.mnc is depicted using mincpik: mincpik -verbose -depth 16 -scale 40 out.mnc MIFF:- | display - a rather strange image occurs (example image attached as number 03). Since I want to use out.mnc together with nu_correct I wonder whether the conversion from tif to minc is correctly performed. Sample computations using nu_correct for the reduction of intensity in homogeneities obviously are not correct if displayed with imageJ and converted using minctoraw -short -nonormalize nu_correct_result.mnc > nu_correct_result.raw see example image number 04. Any help would be appreciated Respectfully yours pfannmoe From a.janke at gmail.com Thu Sep 6 08:17:42 2012 From: a.janke at gmail.com (Andrew Janke) Date: Thu, 6 Sep 2012 22:17:42 +1000 Subject: [MINC-users] Conversion to MINC and visual inspection of the MINC-file In-Reply-To: <20120906121214.45fe768c.pfannmoelj@uni-greifswald.de> References: <20120906121214.45fe768c.pfannmoelj@uni-greifswald.de> Message-ID: Hi J?rg Unfortunately attachments aren't allowed on this list but I'm going to take a stab at this anyhow. On 6 September 2012 20:12, J?rg Pfannm?ller wrote: > Subsequently mydata.mnc is converted to .raw format using: > minctoraw -short -nonormalize mydata.mnc > mydata.raw > > This is displayed in imageJ and seem to be correct (example image attached as number 02) > > If mydata.mnc is depicted using mincpik: > > mincpik -verbose -depth 16 -scale 40 out.mnc MIFF:- | display - > > a rather strange image occurs (example image attached as number 03) My guess is that you don't want a scale of 40 here, you probably want to use a -width option instead. The problem is that a lot of the minc tools have a few constants hard-coded in there for "human head" sized data so working with little voxels will occasionally cause grief. >Sample computations using nu_correct for the reduction of intensity in homogeneities obviously are not correct if displayed with imageJ and converted using For a start you are going to have to specify a -distance parameter to nu_correct to suit your data. This will depend on field strength. One of the common approaches when working with mouse data is to simple scale it all to "human" size. Typically this is about a scale of 30. a From jason at phenogenomics.ca Thu Sep 6 08:52:40 2012 From: jason at phenogenomics.ca (Jason Lerch) Date: Thu, 6 Sep 2012 08:52:40 -0400 Subject: [MINC-users] Conversion to MINC and visual inspection of the MINC-file In-Reply-To: References: <20120906121214.45fe768c.pfannmoelj@uni-greifswald.de> Message-ID: On 2012-09-06, at 8:17 AM, Andrew Janke wrote: > Hi J?rg > > Unfortunately attachments aren't allowed on this list but I'm going to > take a stab at this anyhow. > > On 6 September 2012 20:12, J?rg Pfannm?ller > wrote: >> Subsequently mydata.mnc is converted to .raw format using: >> minctoraw -short -nonormalize mydata.mnc > mydata.raw >> >> This is displayed in imageJ and seem to be correct (example image attached as number 02) >> >> If mydata.mnc is depicted using mincpik: >> >> mincpik -verbose -depth 16 -scale 40 out.mnc MIFF:- | display - >> >> a rather strange image occurs (example image attached as number 03) > > My guess is that you don't want a scale of 40 here, you probably want > to use a -width option instead. The problem is that a lot of the minc > tools have a few constants hard-coded in there for "human head" sized > data so working with little voxels will occasionally cause grief. That should be considered a bug to be identified and fixed - do you know where that's still the case? We run everything at native resolution (i.e. voxel sizes between 5 and 200 micron isotropic) and haven't been bitten by that in a while with the exception of some ITK algorithms. > >> Sample computations using nu_correct for the reduction of intensity in homogeneities obviously are not correct if displayed with imageJ and converted using > > For a start you are going to have to specify a -distance parameter to > nu_correct to suit your data. This will depend on field strength. One > of the common approaches when working with mouse data is to simple > scale it all to "human" size. Typically this is about a scale of 30. Eek - we really shouldn't have to do that. Step sizes should accurately reflect the acquired data. For what it's worth, we use these nu_correct parameters on mouse brain MRIs (we keep it constant regardless of whether we use ex or in-vivo data, so voxel sizes ranging from 30 to 125 micron isotropic): -distance 8 -iterations 100 -stop 0.001 -fwhm 0.15 -shrink 4 -lambda 5.0e-02 Jason From a.janke at gmail.com Thu Sep 6 19:11:37 2012 From: a.janke at gmail.com (Andrew Janke) Date: Fri, 7 Sep 2012 09:11:37 +1000 Subject: [MINC-users] Conversion to MINC and visual inspection of the MINC-file In-Reply-To: References: <20120906121214.45fe768c.pfannmoelj@uni-greifswald.de> Message-ID: >> My guess is that you don't want a scale of 40 here, you probably want >> to use a -width option instead. The problem is that a lot of the minc >> tools have a few constants hard-coded in there for "human head" sized >> data so working with little voxels will occasionally cause grief. > > That should be considered a bug to be identified and fixed - do you know where that's still the case? We run everything at native resolution (i.e. voxel sizes between 5 and 200 micron isotropic) and haven't been bitten by that in a while with the exception of some ITK algorithms. I don't disagree. Thus the suggestion of using -width over -scale. >> For a start you are going to have to specify a -distance parameter to >> nu_correct to suit your data. This will depend on field strength. One >> of the common approaches when working with mouse data is to simple >> scale it all to "human" size. Typically this is about a scale of 30. > > Eek - we really shouldn't have to do that. Step sizes should accurately reflect the acquired data. For what it's worth, we use these nu_correct parameters on mouse brain MRIs (we keep it constant regardless of whether we use ex or in-vivo data, so voxel sizes ranging from 30 to 125 micron isotropic): Again, completely agree. But there are a number of defaults in nu_correct that need to be changed (thanks for posting what you use). In the first instance to see if things will "just work" I will usually scale data to head size, test and then if all is good go back and redo things. Perhaps I should change my ways. Still, this sounds like we now have something to do when I'm in Toronto in a weeks time... a From sorench at gmail.com Sat Sep 8 20:09:39 2012 From: sorench at gmail.com (Soren Christensen) Date: Sun, 9 Sep 2012 10:09:39 +1000 Subject: [MINC-users] mincreshape - "Can't allocate 135168 bytes" Message-ID: Hi, I am gettign a strange error from mincreshape when downsampling a dataset. This is what I have: >mincinfo T320.mnc file: T320.mnc image: signed__ short -2048 to 3062 image dimensions: time zspace yspace xspace dimension name length step start -------------- ------ ---- ----- time 12 1 0 zspace 320 0.5 -539.75 yspace 512 -0.461 107.894 xspace 512 -0.461 117.894 And I do: >mincreshape -clobber -dimsize xspace=128 -dimsize yspace=128 -dimsize zspace=128 T320.mnc t.mnc Copying chunks:.(from miicv_get): Can't allocate 135168 bytes (and I have several gigs of RAM free) But it works with 16 slices: >mincreshape -clobber -dimsize xspace=128 -dimsize yspace=128 -dimsize zspace=16 T320.mnc t.mnc (OK) Googling "Can't allocate 135168 bytes" leads to some results, but not nothing that is an obvious fix to me. I am on Fedora 17 with mincreshape -version program: 2.1.20 libminc: 2.1.20 netcdf : 4.2 of Sep 5 2012 22:51:46 $ HDF5 : 1.8.8 gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.7.0/lto-wrapper Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla--enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --disable-build-with-cxx --disable-build-poststage1-with-cxx --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread model: posix gcc version 4.7.0 20120507 (Red Hat 4.7.0-5) (GCC) Soren From pfannmoelj at uni-greifswald.de Mon Sep 10 09:30:00 2012 From: pfannmoelj at uni-greifswald.de (=?ISO-8859-1?Q?J=F6rg_Pfannm=F6ller?=) Date: Mon, 10 Sep 2012 15:30:00 +0200 Subject: [MINC-users] Conversion to MINC and visual inspection of the MINC-file In-Reply-To: References: <20120906121214.45fe768c.pfannmoelj@uni-greifswald.de> Message-ID: <20120910153000.99343a33.pfannmoelj@uni-greifswald.de> Hi, thank you for your help. Concerning your suggestions I have two questions. 1.) I don't find the option witdh in rawtominc, micpik ord nu_correct. Can you give some more details on this hint. 2.) nu_correct did accept all options for nu_correcting the mouse brain except of lambda. My prompt was: nu_correct my_data.mnc corrected_data.mnc -distance 8 -mask new_mask_reduced.mnc -iterations 100 -stop 0.001 -fwhm 0.15 -shrink 4 What went wrong? After all I appreciate your help, but form my state of knowledge I can not understand how the conversion from raw to minc can be performed for my data. Currently I use micro_view on windows to transform my data from analyzer format to minc. The final minc data look as the original ones if displayed with mincpik. nu_correct also processes giving reasonable results. So what can I do to achieve a proper conversion using the linus shell? Respectfully yours pfannmoe From trash001 at odu.edu Mon Sep 10 13:32:56 2012 From: trash001 at odu.edu (Tanweer Rashid) Date: Mon, 10 Sep 2012 13:32:56 -0400 Subject: [MINC-users] Density value Message-ID: Hi, Can anyone tell me how I can compute the maximum, minimum and averate density values for a MINC volume? Is there any functions that will do this? Thanks and regards, -- Tanweer Rashid MSVE Dept. Old Dominion University From a.janke at gmail.com Mon Sep 10 13:44:33 2012 From: a.janke at gmail.com (Andrew Janke) Date: Mon, 10 Sep 2012 19:44:33 +0200 Subject: [MINC-users] Density value In-Reply-To: References: Message-ID: Hi Tanweer, If by density you mean signal intensity then mincstats will give you what you want. a On 10 September 2012 19:32, Tanweer Rashid wrote: > Hi, > > Can anyone tell me how I can compute the maximum, minimum and averate > density values for a MINC volume? Is there any functions that will do this? > > Thanks and regards, > -- > Tanweer Rashid > MSVE Dept. > Old Dominion University > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users From sorench at gmail.com Thu Sep 13 04:10:33 2012 From: sorench at gmail.com (Soren Christensen) Date: Thu, 13 Sep 2012 18:10:33 +1000 Subject: [MINC-users] MINC 2 api and RAM/HD access Message-ID: Hi, I am am working on some MINC files sized at ~3GB and views ("hyper slabs" in minc speak) of this data to the GPU for display purposes. I can't put the whole thing on the GPU at once so I am using miget_voxel_value_hyperslab and setting the apparent order as appropriate for the view I want. This seems to be a little slow, especially over my nfs mount. I assume this is due to the extensive jumping around the file required for changing the stride on the data. It would be great if the MINC file could be loaded into RAM, and I could then continue to use the MINC2 api on the file. The alternative is of course to read in the whole voxel volume, but then I have to worry about stride etc my self - I'd rather leave that to the API if possible. Is there a way to "cache" the data in RAM for this purpose? I can't find it in the API, but I was hoping for some pointers as to what it would take to achieve this. Thanks Soren From antoine.pattin at gmail.com Thu Sep 13 06:25:34 2012 From: antoine.pattin at gmail.com (antoine pattin) Date: Thu, 13 Sep 2012 12:25:34 +0200 Subject: [MINC-users] Which parameters for normalization ? Message-ID: Hello everyone ! I'm struggling to normalize data extracted from a MINC file using the miicv_get and miicv_set functions (image conversion variable functions). My objective is to read separately each frame from my MINC volume. In the minc file, data are stored as signed short but I would like to read it in a float buffer. The extraction works without trouble but I never obtain the expected values. Here are the details about my last try : /* I create the icv and set the personalised normalization */ icv = miicv_create(); (void) miicv_setint(icv, MI_ICV_DO_NORM, TRUE); (void) miicv_setint(icv, MI_ICV_USER_NORM, TRUE); /* the data will be read as signed shorts and stored as floats */ (void) miicv_setint(icv, MI_ICV_TYPE, NC_SHORT); (void) miicv_setstr(icv, MI_ICV_SIGN, MI_SIGNED); /* I don't know how to set the valid range, should it be the float data range or the short data range [-32768; 32767] ? (void) miicv_setint(icv, MI_ICV_VALID_MAX, 32000); (void) miicv_setint(icv, MI_ICV_VALID_MIN, 0); /* I want to read each frame separately so I set my user image range the same as the range of data in the frame */ float frame_min = 1033; float frame_max = 2835; (void) miicv_setint(icv, MI_ICV_IMAGE_MAX, frame_max); (void) miicv_setint(icv, MI_ICV_IMAGE_MIN, frame_min); and then begins the extraction. Should I use miicv_setdbl functions instead of miicvset_int ? If I want to compare the data over all the frame, should I set the image range to the minc min and minc max instead of frame min and frame max ? What should be my valid range and am I calling miicv_set functions in the right order ? I know this is a lot of questions but even after reading the "example reading values" from the minc documentation I still can't understand. I thank you for your help and for your time. Best regards, Antoine. From vladimir.fonov at gmail.com Thu Sep 13 09:40:11 2012 From: vladimir.fonov at gmail.com (Vladimir S. FONOV) Date: Thu, 13 Sep 2012 09:40:11 -0400 Subject: [MINC-users] MINC 2 api and RAM/HD access In-Reply-To: References: Message-ID: Hello Soren, maybe it will be worth to reorganize your file so that the slabs you are reading are actually stored as fastest-varying (using mincreshape -dimorder ), also you might want to disable built-in compression when creating the file ( MINC_COMPRESS environment variable). P.S. What is the reason for not reading the whole MINC file into array, and then just dealing with it without minc api ? On Thu, Sep 13, 2012 at 4:10 AM, Soren Christensen wrote: > Hi, > I am am working on some MINC files sized at ~3GB and views ("hyper > slabs" in minc speak) of this data to the GPU for display purposes. I > can't put the whole thing on the GPU at once so I am using > miget_voxel_value_hyperslab and setting the apparent order as > appropriate for the view I want. This seems to be a little slow, > especially over my nfs mount. I assume this is due to the extensive > jumping around the file required for changing the stride on the data. > It would be great if the MINC file could be loaded into RAM, and I > could then continue to use the MINC2 api on the file. The alternative > is of course to read in the whole voxel volume, but then I have to > worry about stride etc my self - I'd rather leave that to the API if > possible. Is there a way to "cache" the data in RAM for this purpose? > I can't find it in the API, but I was hoping for some pointers as to > what it would take to achieve this. > > Thanks > Soren > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users -- Best regards, Vladimir S. Fonov ~ vladimir fonov gmail com From vladimir.fonov at gmail.com Thu Sep 13 10:01:06 2012 From: vladimir.fonov at gmail.com (Vladimir S. Fonov) Date: Thu, 13 Sep 2012 10:01:06 -0400 Subject: [MINC-users] Which parameters for normalization ? In-Reply-To: References: Message-ID: <5051E722.2030900@gmail.com> Hello Antoine, take a look on how it's done in ezminc: https://github.com/BIC-MNI/minc/blob/develop/ezminc/minc_1_rw.cpp#L1073 P.S. It is easier API to use then MINC directly, see examples in https://github.com/BIC-MNI/minc/tree/develop/ezminc/examples and in tests: https://github.com/BIC-MNI/minc/tree/develop/ezminc/tests On 13/09/2012 6:25 AM, antoine pattin wrote: > Hello everyone ! > > I'm struggling to normalize data extracted from a MINC file using the > miicv_get and miicv_set functions (image conversion variable functions). > > My objective is to read separately each frame from my MINC volume. > In the minc file, data are stored as signed short but I would like to read > it in a float buffer. > The extraction works without trouble but I never obtain the expected values. > > > Here are the details about my last try : > > /* I create the icv and set the personalised normalization */ > icv = miicv_create(); > (void) miicv_setint(icv, MI_ICV_DO_NORM, TRUE); > (void) miicv_setint(icv, MI_ICV_USER_NORM, TRUE); > > /* the data will be read as signed shorts and stored as floats */ > (void) miicv_setint(icv, MI_ICV_TYPE, NC_SHORT); > (void) miicv_setstr(icv, MI_ICV_SIGN, MI_SIGNED); > > /* I don't know how to set the valid range, should it be the float data > range or the short data range [-32768; 32767] ? > (void) miicv_setint(icv, MI_ICV_VALID_MAX, 32000); > (void) miicv_setint(icv, MI_ICV_VALID_MIN, 0); > /* I want to read each frame separately so I set my user image range the > same as the range of data in the frame */ > float frame_min = 1033; > float frame_max = 2835; > (void) miicv_setint(icv, MI_ICV_IMAGE_MAX, frame_max); > (void) miicv_setint(icv, MI_ICV_IMAGE_MIN, frame_min); > > and then begins the extraction. > > > Should I use miicv_setdbl functions instead of miicvset_int ? > If I want to compare the data over all the frame, should I set the image > range to the minc min and minc max instead of frame min and frame max ? > What should be my valid range and am I calling miicv_set functions in the > right order ? > > I know this is a lot of questions but even after reading the "example > reading values" from the minc documentation I still can't understand. > I thank you for your help and for your time. > > Best regards, > Antoine. > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > -- Best regards, Vladimir S. Fonov ~ vladimir fonov gmail com From sorench at gmail.com Thu Sep 13 10:38:37 2012 From: sorench at gmail.com (Soren Christensen) Date: Fri, 14 Sep 2012 00:38:37 +1000 Subject: [MINC-users] MINC 2 api and RAM/HD access In-Reply-To: References: Message-ID: Hi Vladimir, The dataset is pretty large and contain multiple temporal frames so I am caching certain views that allows for quick interaction. That is, volume navigation+cross time navigation. So only one temporal frame is kept at the GPU at time in addition to 3 buffers for the temporal frames of the current orthogonal views. Once the frames are advanced the cached buffers are displayed and nothing needs transferring from the CPU. Once the frame advancement is stopped, the volume at the stopping frame is then read from file, replacing the existing one. So I have 4 dimension orderings in use: x y z (fastest->slowest) for the volume at the current frame and x z t, y z t, x y t for the cached frames. I need to frequently refresh these buffers from the file so as far as I can see reordering the file will only optimize for one of the 4 hyper slab requirements. Yes maybe just reading it all into RAM and just have access functions get the right reordering is the way to go - it does not seem to be difficult, but it is essentially what set_dimorder_apparent already does, so if I could use that it would just save me coding it up. Thanks for the tip on the compression too. Cheers Soren On Thu, Sep 13, 2012 at 11:40 PM, Vladimir S. FONOV wrote: > Hello Soren, > > maybe it will be worth to reorganize your file so that the slabs you > are reading are actually stored as fastest-varying (using mincreshape > -dimorder ), also you might want to disable built-in compression when > creating the file ( MINC_COMPRESS environment variable). > > P.S. What is the reason for not reading the whole MINC file into > array, and then just dealing with it without minc api ? > > On Thu, Sep 13, 2012 at 4:10 AM, Soren Christensen wrote: >> Hi, >> I am am working on some MINC files sized at ~3GB and views ("hyper >> slabs" in minc speak) of this data to the GPU for display purposes. I >> can't put the whole thing on the GPU at once so I am using >> miget_voxel_value_hyperslab and setting the apparent order as >> appropriate for the view I want. This seems to be a little slow, >> especially over my nfs mount. I assume this is due to the extensive >> jumping around the file required for changing the stride on the data. >> It would be great if the MINC file could be loaded into RAM, and I >> could then continue to use the MINC2 api on the file. The alternative >> is of course to read in the whole voxel volume, but then I have to >> worry about stride etc my self - I'd rather leave that to the API if >> possible. Is there a way to "cache" the data in RAM for this purpose? >> I can't find it in the API, but I was hoping for some pointers as to >> what it would take to achieve this. >> >> Thanks >> Soren >> _______________________________________________ >> MINC-users at bic.mni.mcgill.ca >> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > > > > -- > Best regards, > > Vladimir S. Fonov ~ vladimir fonov gmail com > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users From jon.pipitone at utoronto.ca Thu Sep 13 11:35:04 2012 From: jon.pipitone at utoronto.ca (jon pipitone) Date: Thu, 13 Sep 2012 11:35:04 -0400 Subject: [MINC-users] MINC 2 api and RAM/HD access In-Reply-To: References: Message-ID: Hey Soren, One far less glamorous way we've dealt with improving access speeds is to move images onto a ramdisk (e.g. /dev/shm) and manipulate them there. Jon. On Thu, Sep 13, 2012 at 10:38 AM, Soren Christensen wrote: > Hi Vladimir, > The dataset is pretty large and contain multiple temporal frames so I > am caching certain views that allows for quick interaction. That is, > volume navigation+cross time navigation. So only one temporal frame is > kept at the GPU at time in addition to 3 buffers for the temporal > frames of the current orthogonal views. Once the frames are advanced > the cached buffers are displayed and nothing needs transferring from > the CPU. Once the frame advancement is stopped, the volume at the > stopping frame is then read from file, replacing the existing one. So > I have 4 dimension orderings in use: x y z (fastest->slowest) for the > volume at the current frame and x z t, y z t, x y t for the cached > frames. I need to frequently refresh these buffers from the file so > as far as I can see reordering the file will only optimize for one of > the 4 hyper slab requirements. Yes maybe just reading it all into RAM > and just have access functions get the right reordering is the way to > go - it does not seem to be difficult, but it is essentially what > set_dimorder_apparent already does, so if I could use that it would > just save me coding it up. > Thanks for the tip on the compression too. > > Cheers > Soren > > > > > On Thu, Sep 13, 2012 at 11:40 PM, Vladimir S. FONOV > wrote: > > Hello Soren, > > > > maybe it will be worth to reorganize your file so that the slabs you > > are reading are actually stored as fastest-varying (using mincreshape > > -dimorder ), also you might want to disable built-in compression when > > creating the file ( MINC_COMPRESS environment variable). > > > > P.S. What is the reason for not reading the whole MINC file into > > array, and then just dealing with it without minc api ? > > > > On Thu, Sep 13, 2012 at 4:10 AM, Soren Christensen > wrote: > >> Hi, > >> I am am working on some MINC files sized at ~3GB and views ("hyper > >> slabs" in minc speak) of this data to the GPU for display purposes. I > >> can't put the whole thing on the GPU at once so I am using > >> miget_voxel_value_hyperslab and setting the apparent order as > >> appropriate for the view I want. This seems to be a little slow, > >> especially over my nfs mount. I assume this is due to the extensive > >> jumping around the file required for changing the stride on the data. > >> It would be great if the MINC file could be loaded into RAM, and I > >> could then continue to use the MINC2 api on the file. The alternative > >> is of course to read in the whole voxel volume, but then I have to > >> worry about stride etc my self - I'd rather leave that to the API if > >> possible. Is there a way to "cache" the data in RAM for this purpose? > >> I can't find it in the API, but I was hoping for some pointers as to > >> what it would take to achieve this. > >> > >> Thanks > >> Soren > >> _______________________________________________ > >> MINC-users at bic.mni.mcgill.ca > >> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > > > > > > > > -- > > Best regards, > > > > Vladimir S. Fonov ~ vladimir fonov gmail com > > _______________________________________________ > > MINC-users at bic.mni.mcgill.ca > > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > From a.janke at gmail.com Thu Sep 13 17:21:01 2012 From: a.janke at gmail.com (Andrew Janke) Date: Thu, 13 Sep 2012 23:21:01 +0200 Subject: [MINC-users] MINC 2 api and RAM/HD access In-Reply-To: References: Message-ID: I'll second this. The advantage is that you let the kernel do all the hard stuff. a On 13 September 2012 17:35, jon pipitone wrote: > One far less glamorous way we've dealt with improving access speeds is to > move images onto a ramdisk (e.g. /dev/shm) and manipulate them there From sorench at gmail.com Sat Sep 15 08:27:53 2012 From: sorench at gmail.com (Soren Christensen) Date: Sat, 15 Sep 2012 22:27:53 +1000 Subject: [MINC-users] MINC 2 api and RAM/HD access In-Reply-To: References: Message-ID: Thanks to all! >From local drive a call to miget_voxel_value_hyperslab takes me about 500ms - that is for a 512*320*12 short buffer lookup from the 512 512 320 12 matrix. This is noticeable and I am looking for half of that. Interestingly putting it in /dev/shm seems to make no difference. I suppose the OS may be caching the file in RAM even if it is on the drive? The file is not compressed so nothing to gain for me here unfortunately. The only thing I can thing of to speed it up further, is if the reordering can be optimized - I suppose for certain reorderings longer blocks can be copied at once, but this may be exploited already and I am not even sure if there is any gain to be won here - any ideas on this? (The t-x-y lookup is 3ms, the t-x-z 252ms and finally t-z-y is 519ms. I assume y-z-t is the slowest since there is a jump for every voxel read, whereas the two other "views" have larger continuous memory blocks - can anyone confirm?) Thanks again, Soren On Fri, Sep 14, 2012 at 7:21 AM, Andrew Janke wrote: > I'll second this. The advantage is that you let the kernel do all the > hard stuff. > > > a > > On 13 September 2012 17:35, jon pipitone wrote: >> One far less glamorous way we've dealt with improving access speeds is to >> move images onto a ramdisk (e.g. /dev/shm) and manipulate them there > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users From sorench at gmail.com Sat Sep 15 09:23:43 2012 From: sorench at gmail.com (Soren Christensen) Date: Sat, 15 Sep 2012 23:23:43 +1000 Subject: [MINC-users] miset_dimension_apparent_voxel_order - should it not affect miget_voxel_value_hyperslab? Message-ID: Hi, Sorry for the multiple questions - this is a separate issue so I am posting separately. I am trying to use miset_dimension_apparent_voxel_order hoping it could give my data with a fixed relationship between array direction and spatial direction. When I use it though, there seems to be no difference to the voxel output. I had expected a "flip". Where am I going wrong here? This is what I do: give my all y of xrow 16 in native ordering: -2048 -2048 -2048 -1918 -1789 -1659 -1528 -1405 -1251 -1191 -996 -1168 -1237 -1025 -954 -1156 -1498 -1631 -2048 -2048 -2048 -2048 -2048 -2048 -2048 -2048 -2048 -2048 -2048 -2048 -2048 -2048 dimname is yspace step is -1.844 now attempt to reverse y by req y to come out positive by using miset_dimension_apparent_voxel_order. Output is now: -2048 -2048 -2048 -1918 -1789 -1659 -1528 -1405 -1251 -1191 -996 -1168 -1237 -1025 -954 -1156 -1498 -1631 -2048 -2048 -2048 -2048 -2048 -2048 -2048 -2048 -2048 -2048 -2048 -2048 -2048 -2048 (identical) step is -1.844 (also not changed) (I had thought the second array would come out flipped) mincinfo: image dimensions: time zspace yspace xspace dimension name length step start -------------- ------ ---- ----- time 12 1 0 zspace 80 2 -539 yspace 32 -1.844 18.6907 xspace 32 -1.844 28.6905 Code: mihandle_t minc_volume; int result = miopen_volume(fname.toStdString().c_str(), MI2_OPEN_READ, &minc_volume); mitype_t volume_data_type[1]; miget_data_type(minc_volume,volume_data_type ); size_t start[4]={0,0,0,16}; size_t end[4]={1,1,32,1}; //get y row signed short data[32]={0}; result=miget_voxel_value_hyperslab(minc_volume,volume_data_type[0],start,end,static_cast(data)); for (int k=0; k<32; k++) { std::cout << data[k] << " "; } std::cout << std::endl; //what is the y step? midimhandle_t dimensions[4]; result=miget_volume_dimensions(minc_volume, MI_DIMCLASS_SPATIAL,MI_DIMATTR_ALL,MI_DIMORDER_FILE, 4, dimensions); char *name_ptr[1]; miget_dimension_name(dimensions[2], name_ptr ); std::cout << "dimname is " << *name_ptr; std::cout << std::endl; double step[1]; miget_dimension_separation(dimensions[2],MI_ORDER_FILE,step); std::cout << "step is " << step[0] << std::endl; std::cout << "now attempt to reverse y by req y to come out positive "; result=miset_dimension_apparent_voxel_order(dimensions[2],MI_POSITIVE); result=miget_voxel_value_hyperslab(minc_volume,volume_data_type[0],start,end,static_cast(data)); for (int k=0; k<32; k++) { std::cout << data[k] << " "; } std::cout << std::endl; miget_dimension_separation(dimensions[2],MI_ORDER_FILE,step); std::cout << "step is " << step[0] << std::endl; From vladimir.fonov at gmail.com Sat Sep 15 11:05:50 2012 From: vladimir.fonov at gmail.com (Vladimir S. FONOV) Date: Sat, 15 Sep 2012 11:05:50 -0400 Subject: [MINC-users] MINC 2 api and RAM/HD access In-Reply-To: References: Message-ID: Hello, I don't think that anything you will do using MINC2 api will get you close to the performance of accessing float[x*y*z*t] memory array. On Sat, Sep 15, 2012 at 8:27 AM, Soren Christensen wrote: > Thanks to all! > From local drive a call to miget_voxel_value_hyperslab takes me about > 500ms - that is for a 512*320*12 short buffer lookup from the 512 512 > 320 12 matrix. This is noticeable and I am looking for half of that. > Interestingly putting it in /dev/shm seems to make no difference. I > suppose the OS may be caching the file in RAM even if it is on the > drive? > The file is not compressed so nothing to gain for me here unfortunately. > > The only thing I can thing of to speed it up further, is if the > reordering can be optimized - I suppose for certain reorderings longer > blocks can be copied at once, but this may be exploited already and I > am not even sure if there is any gain to be won here - any ideas on > this? > > (The t-x-y lookup is 3ms, the t-x-z 252ms and finally t-z-y is 519ms. > I assume y-z-t is the slowest since there is a jump for every voxel > read, whereas the two other "views" have larger continuous memory > blocks - can anyone confirm?) > > Thanks again, > Soren > > > > > > > > On Fri, Sep 14, 2012 at 7:21 AM, Andrew Janke wrote: >> I'll second this. The advantage is that you let the kernel do all the >> hard stuff. >> >> >> a >> >> On 13 September 2012 17:35, jon pipitone wrote: >>> One far less glamorous way we've dealt with improving access speeds is to >>> move images onto a ramdisk (e.g. /dev/shm) and manipulate them there >> _______________________________________________ >> MINC-users at bic.mni.mcgill.ca >> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users -- Best regards, Vladimir S. Fonov ~ vladimir fonov gmail com From a.janke at gmail.com Sat Sep 15 13:57:28 2012 From: a.janke at gmail.com (Andrew Janke) Date: Sat, 15 Sep 2012 19:57:28 +0200 Subject: [MINC-users] MINC 2 api and RAM/HD access In-Reply-To: References: Message-ID: I'm afraid I'll have to agree on this one. a On 15 September 2012 17:05, Vladimir S. FONOV wrote: > I don't think that anything you will do using MINC2 api will get you > close to the performance of accessing float[x*y*z*t] memory array. From sorench at gmail.com Sun Sep 16 05:40:53 2012 From: sorench at gmail.com (Soren Christensen) Date: Sun, 16 Sep 2012 19:40:53 +1000 Subject: [MINC-users] MINC 2 api and RAM/HD access In-Reply-To: References: Message-ID: It seems you are right. A simple loop extracting the coronal direction (ie no copying of more than one value at a time in my case) takes about 30 ms from RAM (vs ~500 ms via the API be it via disk or /dev/shm) - that is fine for what I need it to do. Thanks for the advice. Soren On Sun, Sep 16, 2012 at 3:57 AM, Andrew Janke wrote: > I'm afraid I'll have to agree on this one. > > > a > > On 15 September 2012 17:05, Vladimir S. FONOV wrote: >> I don't think that anything you will do using MINC2 api will get you >> close to the performance of accessing float[x*y*z*t] memory array. > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users From baghdadi at phenogenomics.ca Mon Sep 17 09:40:07 2012 From: baghdadi at phenogenomics.ca (Leila Baghdadi) Date: Mon, 17 Sep 2012 09:40:07 -0400 Subject: [MINC-users] miset_dimension_apparent_voxel_order - should it not affect miget_voxel_value_hyperslab? Message-ID: <24286868.128821347889207007.JavaMail.root@mail2.phenogenomics.ca> Soren, a while ago, I checked in some changes to the minc2 git code which address the issue you are talking about! I suspect you are using a version of the code which does not have these changes. you should be able to check your micn directory (libsrc2/hyper.c --> check mitranslate_hyperslab_origin --> mine is around line 280) and see the changes if not please update your minc2 source and rebuild HTH Leila ----- Original Message ----- From: Soren Christensen Sent: Sat, 9/15/2012 9:23am To: MINC users mailing list Subject: [MINC-users] miset_dimension_apparent_voxel_order - should it not affect miget_voxel_value_hyperslab? Hi, Sorry for the multiple questions - this is a separate issue so I am posting separately. I am trying to use miset_dimension_apparent_voxel_order hoping it could give my data with a fixed relationship between array direction and spatial direction. When I use it though, there seems to be no difference to the voxel output. I had expected a "flip". Where am I going wrong here? This is what I do: give my all y of xrow 16 in native ordering: -2048 -2048 -2048 -1918 -1789 -1659 -1528 -1405 -1251 -1191 -996 -1168 -1237 -1025 -954 -1156 -1498 -1631 -2048 -2048 -2048 -2048 -2048 -2048 -2048 -2048 -2048 -2048 -2048 -2048 -2048 -2048 dimname is yspace step is -1.844 now attempt to reverse y by req y to come out positive by using miset_dimension_apparent_voxel_order. Output is now: -2048 -2048 -2048 -1918 -1789 -1659 -1528 -1405 -1251 -1191 -996 -1168 -1237 -1025 -954 -1156 -1498 -1631 -2048 -2048 -2048 -2048 -2048 -2048 -2048 -2048 -2048 -2048 -2048 -2048 -2048 -2048 (identical) step is -1.844 (also not changed) (I had thought the second array would come out flipped) mincinfo: image dimensions: time zspace yspace xspace dimension name length step start -------------- ------ ---- ----- time 12 1 0 zspace 80 2 -539 yspace 32 -1.844 18.6907 xspace 32 -1.844 28.6905 Code: mihandle_t minc_volume; int result = miopen_volume(fname.toStdString().c_str(), MI2_OPEN_READ, &minc_volume); mitype_t volume_data_type[1]; miget_data_type(minc_volume,volume_data_type ); size_t start[4]={0,0,0,16}; size_t end[4]={1,1,32,1}; //get y row signed short data[32]={0}; result=miget_voxel_value_hyperslab(minc_volume,volume_data_type[0],start,end,static_cast(data)); for (int k=0; k<32; k++) { std::cout << data[k] << " "; } std::cout << std::endl; //what is the y step? midimhandle_t dimensions[4]; result=miget_volume_dimensions(minc_volume, MI_DIMCLASS_SPATIAL,MI_DIMATTR_ALL,MI_DIMORDER_FILE, 4, dimensions); char *name_ptr[1]; miget_dimension_name(dimensions[2], name_ptr ); std::cout << "dimname is " << *name_ptr; std::cout << std::endl; double step[1]; miget_dimension_separation(dimensions[2],MI_ORDER_FILE,step); std::cout << "step is " << step[0] << std::endl; std::cout << "now attempt to reverse y by req y to come out positive "; result=miset_dimension_apparent_voxel_order(dimensions[2],MI_POSITIVE); result=miget_voxel_value_hyperslab(minc_volume,volume_data_type[0],start,end,static_cast(data)); for (int k=0; k<32; k++) { std::cout << data[k] << " "; } std::cout << std::endl; miget_dimension_separation(dimensions[2],MI_ORDER_FILE,step); std::cout << "step is " << step[0] << std::endl; _______________________________________________ MINC-users at bic.mni.mcgill.ca http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users From zijdenbos at gmail.com Mon Sep 17 10:38:30 2012 From: zijdenbos at gmail.com (Alex Zijdenbos) Date: Mon, 17 Sep 2012 10:38:30 -0400 Subject: [MINC-users] mincreshape +/-direction options (again) Message-ID: Hi all, I occasionally bump into the fact that the mincreshape *direction options operate on image dimensions (the two fastest varying dimensions, i.e., a slice) only. Things like this: $ mincreshape -xdirection test.mnc test-x.mnc Copying chunks:..................................................................................................................................................................................................................Done. $ mincinfo test.mnc test-x.mnc file: test.mnc image: unsigned byte 0 to 165 image dimensions: xspace yspace zspace dimension name length step start -------------- ------ ---- ----- xspace 210 0.06 -6.33 yspace 274 0.06 -9.663 zspace 141 0.06 -4.8 file: test-x.mnc image: unsigned byte 0 to 255 image dimensions: xspace yspace zspace dimension name length step start -------------- ------ ---- ----- xspace 210 0.06 -6.33 yspace 274 0.06 -9.663 zspace 141 0.06 -4.8 So I told mincreshape to force the step in x to be negative; but my volume comes out unchanged. The explanation lives in the man page under the +direction option: +direction Flip images to give positive step value for spatial axes. Note that the flipping of spatial axes only applies to "image dimensions". These are the two fastest varying (non-vector) dimensions in the file. If you want to flip a non-image dimension, you can convert it to an image dimension with -dimsize dimname=-1 (the -1 means don't really change the size). Check out the examples. However, this is at best very confusing, if not just wrong. It seems to me that a very specific instruction like -xdirection should "just work" regardless of whether or not xspace happens to be an image dimension. I have seen several posts over the years where people scratch their heads over this (myself included :) I can think of a few ways to address this: - modify mincreshape to "just work" for [+-][xyz]direction - throw a warning or error when [+-][xyz]direction is used while the corresponding [xyz]space is not an image dimension - make this rather counterintuitive behaviour abundantly clear (e.g., description with every such option in the man page/help) Thoughts? -- A From sorench at gmail.com Tue Sep 18 09:14:07 2012 From: sorench at gmail.com (Soren Christensen) Date: Tue, 18 Sep 2012 23:14:07 +1000 Subject: [MINC-users] miset_dimension_apparent_voxel_order - should it not affect miget_voxel_value_hyperslab? In-Reply-To: <24286868.128821347889207007.JavaMail.root@mail2.phenogenomics.ca> References: <24286868.128821347889207007.JavaMail.root@mail2.phenogenomics.ca> Message-ID: Hi Leila, I pulled the branches but not sure how to determine if your changes are there - which branch is it in and is there any identifying feature in the code. I was using minc from the minc-toolkit installed just a couple of weeks ago, but perhaps an older commit in the submodule. Cheers Soren On Mon, Sep 17, 2012 at 11:40 PM, Leila Baghdadi wrote: > Soren, > > a while ago, I checked in some changes to the minc2 git code which address the issue you are talking about! I suspect you are using a version of the code which does not have these changes. > > you should be able to check your micn directory (libsrc2/hyper.c --> check mitranslate_hyperslab_origin --> mine is around line 280) and see the changes > > if not please update your minc2 source and rebuild > > HTH > > Leila > > ----- Original Message ----- > From: Soren Christensen > Sent: Sat, 9/15/2012 9:23am > To: MINC users mailing list > Subject: [MINC-users] miset_dimension_apparent_voxel_order - should it not affect miget_voxel_value_hyperslab? > > Hi, > Sorry for the multiple questions - this is a separate issue so I am > posting separately. > I am trying to use miset_dimension_apparent_voxel_order hoping it > could give my data with a fixed relationship between array direction > and spatial direction. > When I use it though, there seems to be no difference to the voxel > output. I had expected a "flip". > Where am I going wrong here? > > This is what I do: > give my all y of xrow 16 in native ordering: > -2048 -2048 -2048 -1918 -1789 -1659 -1528 -1405 -1251 -1191 -996 -1168 > -1237 -1025 -954 -1156 -1498 -1631 -2048 -2048 -2048 -2048 -2048 -2048 > -2048 -2048 -2048 -2048 -2048 -2048 -2048 -2048 > dimname is yspace > step is -1.844 > > now attempt to reverse y by req y to come out positive by using > miset_dimension_apparent_voxel_order. Output is now: > -2048 -2048 -2048 -1918 -1789 -1659 -1528 -1405 -1251 -1191 -996 -1168 > -1237 -1025 -954 -1156 -1498 -1631 -2048 -2048 -2048 -2048 -2048 -2048 > -2048 -2048 -2048 -2048 -2048 -2048 -2048 -2048 (identical) > step is -1.844 (also not changed) > > > (I had thought the second array would come out flipped) > > > mincinfo: > image dimensions: time zspace yspace xspace > dimension name length step start > -------------- ------ ---- ----- > time 12 1 0 > zspace 80 2 -539 > yspace 32 -1.844 18.6907 > xspace 32 -1.844 28.6905 > > > > Code: > mihandle_t minc_volume; > int result = miopen_volume(fname.toStdString().c_str(), > MI2_OPEN_READ, &minc_volume); > > > mitype_t volume_data_type[1]; > miget_data_type(minc_volume,volume_data_type ); > > > size_t start[4]={0,0,0,16}; > size_t end[4]={1,1,32,1}; > > //get y row > signed short data[32]={0}; > > result=miget_voxel_value_hyperslab(minc_volume,volume_data_type[0],start,end,static_cast(data)); > > for (int k=0; k<32; k++) > { > std::cout << data[k] << " "; > > } > std::cout << std::endl; > > //what is the y step? > midimhandle_t dimensions[4]; > result=miget_volume_dimensions(minc_volume, > MI_DIMCLASS_SPATIAL,MI_DIMATTR_ALL,MI_DIMORDER_FILE, 4, dimensions); > > char *name_ptr[1]; > miget_dimension_name(dimensions[2], name_ptr ); > std::cout << "dimname is " << *name_ptr; > std::cout << std::endl; > double step[1]; > miget_dimension_separation(dimensions[2],MI_ORDER_FILE,step); > > std::cout << "step is " << step[0] << std::endl; > > std::cout << "now attempt to reverse y by req y to come out positive "; > result=miset_dimension_apparent_voxel_order(dimensions[2],MI_POSITIVE); > > result=miget_voxel_value_hyperslab(minc_volume,volume_data_type[0],start,end,static_cast(data)); > > for (int k=0; k<32; k++) > { > std::cout << data[k] << " "; > > } > std::cout << std::endl; > > miget_dimension_separation(dimensions[2],MI_ORDER_FILE,step); > > std::cout << "step is " << step[0] << std::endl; > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users From baghdadi at phenogenomics.ca Tue Sep 18 12:25:22 2012 From: baghdadi at phenogenomics.ca (Leila Baghdadi) Date: Tue, 18 Sep 2012 12:25:22 -0400 Subject: [MINC-users] miset_dimension_apparent_voxel_order - should it not affect miget_voxel_value_hyperslab? In-Reply-To: Message-ID: <32250166.143961347985522002.JavaMail.root@mail2.phenogenomics.ca> Hi Soren, I understand there is gonna be a minc merge in the next few weeks but for now try pulling the changes from my fork https://github.com/leila1349/minc/ you can see the changes dated march16/2011 in libsrc2/hyper.c HTH Leila ----- Original Message ----- From: Soren Christensen Sent: Tue, 9/18/2012 9:14am To: MINC users mailing list Subject: Re: [MINC-users] miset_dimension_apparent_voxel_order - should it not affect miget_voxel_value_hyperslab? Hi Leila, I pulled the branches but not sure how to determine if your changes are there - which branch is it in and is there any identifying feature in the code. I was using minc from the minc-toolkit installed just a couple of weeks ago, but perhaps an older commit in the submodule. Cheers Soren On Mon, Sep 17, 2012 at 11:40 PM, Leila Baghdadi wrote: > Soren, > > a while ago, I checked in some changes to the minc2 git code which address the issue you are talking about! I suspect you are using a version of the code which does not have these changes. > > you should be able to check your micn directory (libsrc2/hyper.c --> check mitranslate_hyperslab_origin --> mine is around line 280) and see the changes > > if not please update your minc2 source and rebuild > > HTH > > Leila > > ----- Original Message ----- > From: Soren Christensen > Sent: Sat, 9/15/2012 9:23am > To: MINC users mailing list > Subject: [MINC-users] miset_dimension_apparent_voxel_order - should it not affect miget_voxel_value_hyperslab? > > Hi, > Sorry for the multiple questions - this is a separate issue so I am > posting separately. > I am trying to use miset_dimension_apparent_voxel_order hoping it > could give my data with a fixed relationship between array direction > and spatial direction. > When I use it though, there seems to be no difference to the voxel > output. I had expected a "flip". > Where am I going wrong here? > > This is what I do: > give my all y of xrow 16 in native ordering: > -2048 -2048 -2048 -1918 -1789 -1659 -1528 -1405 -1251 -1191 -996 -1168 > -1237 -1025 -954 -1156 -1498 -1631 -2048 -2048 -2048 -2048 -2048 -2048 > -2048 -2048 -2048 -2048 -2048 -2048 -2048 -2048 > dimname is yspace > step is -1.844 > > now attempt to reverse y by req y to come out positive by using > miset_dimension_apparent_voxel_order. Output is now: > -2048 -2048 -2048 -1918 -1789 -1659 -1528 -1405 -1251 -1191 -996 -1168 > -1237 -1025 -954 -1156 -1498 -1631 -2048 -2048 -2048 -2048 -2048 -2048 > -2048 -2048 -2048 -2048 -2048 -2048 -2048 -2048 (identical) > step is -1.844 (also not changed) > > > (I had thought the second array would come out flipped) > > > mincinfo: > image dimensions: time zspace yspace xspace > dimension name length step start > -------------- ------ ---- ----- > time 12 1 0 > zspace 80 2 -539 > yspace 32 -1.844 18.6907 > xspace 32 -1.844 28.6905 > > > > Code: > mihandle_t minc_volume; > int result = miopen_volume(fname.toStdString().c_str(), > MI2_OPEN_READ, &minc_volume); > > > mitype_t volume_data_type[1]; > miget_data_type(minc_volume,volume_data_type ); > > > size_t start[4]={0,0,0,16}; > size_t end[4]={1,1,32,1}; > > //get y row > signed short data[32]={0}; > > result=miget_voxel_value_hyperslab(minc_volume,volume_data_type[0],start,end,static_cast(data)); > > for (int k=0; k<32; k++) > { > std::cout << data[k] << " "; > > } > std::cout << std::endl; > > //what is the y step? > midimhandle_t dimensions[4]; > result=miget_volume_dimensions(minc_volume, > MI_DIMCLASS_SPATIAL,MI_DIMATTR_ALL,MI_DIMORDER_FILE, 4, dimensions); > > char *name_ptr[1]; > miget_dimension_name(dimensions[2], name_ptr ); > std::cout << "dimname is " << *name_ptr; > std::cout << std::endl; > double step[1]; > miget_dimension_separation(dimensions[2],MI_ORDER_FILE,step); > > std::cout << "step is " << step[0] << std::endl; > > std::cout << "now attempt to reverse y by req y to come out positive "; > result=miset_dimension_apparent_voxel_order(dimensions[2],MI_POSITIVE); > > result=miget_voxel_value_hyperslab(minc_volume,volume_data_type[0],start,end,static_cast(data)); > > for (int k=0; k<32; k++) > { > std::cout << data[k] << " "; > > } > std::cout << std::endl; > > miget_dimension_separation(dimensions[2],MI_ORDER_FILE,step); > > std::cout << "step is " << step[0] << std::endl; > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users _______________________________________________ MINC-users at bic.mni.mcgill.ca http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users From a.janke at gmail.com Mon Sep 24 10:53:00 2012 From: a.janke at gmail.com (Andrew Janke) Date: Mon, 24 Sep 2012 10:53:00 -0400 Subject: [MINC-users] Getting max and min in a sphere centered at each voxel In-Reply-To: <7AFC7FF86A08427D8604F4A5107CB477@gmail.com> References: <4FF5EF34.7040203@gmail.com> <4FF60BD9.1040802@gmail.com> <5F68039A26D441D4A82C01FDED75029C@gmail.com> <7AFC7FF86A08427D8604F4A5107CB477@gmail.com> Message-ID: Hi Alex, On 6 July 2012 23:18, Alex Zijdenbos wrote: > I realized there were some issues with the kernel generation script I passed along (center voxel nonzero, among other things), so here is an improved version: > > make_mincmorph_kernel.pl (http://cl.ly/3P0i391X0k0e2V1T2846) You can now find this here: https://github.com/BIC-MNI/minc/blob/develop/progs/mincmorph/make_mincmorph_kernel.pl a From a.janke at gmail.com Sat Sep 29 22:05:06 2012 From: a.janke at gmail.com (Andrew Janke) Date: Sun, 30 Sep 2012 12:05:06 +1000 Subject: [MINC-users] MINC 2.2.00 and changes to github. Message-ID: Hi all, First MINC 2.2 has been released here: http://packages.bic.mni.mcgill.ca/tgz/minc-2.2.00.tar.gz or if you are feeling like doing things the cool github way, here: https://github.com/BIC-MNI/minc/tarball/release-2.2.00 I have just spent a bit of time back in Montreal with Vlad Fonov and Louis Collins. One of the things that has long been discussed by the MINC developers is split libminc from the current minc package to allow easier integration into other packages such as ITK. With this in mind, the existing github repository here: https://github.com/BIC-MNI/minc Will no longer be updated by the primary minc developers. Vlad and I have split MINC into two packages, libminc and minc-tools. You can find them here: https://github.com/BIC-MNI/libminc https://github.com/BIC-MNI/minc-tools These two repositories are then combined into Vlads MINC superbuild package that will soon become the official MINC "all in one" distribution. So thanks to Vlad for all his hard work on this. https://github.com/BIC-MNI/minc-toolkit For those who are interested we are currently working on a build of libminc that does not depend upon netCDF for the purposes of ITk integration. This is a branch of libminc called minc-lite and the work in progress can be found here: https://github.com/BIC-MNI/libminc/tree/minc_lite There will be more updates on this soon but for now minc_lite should be considered highly experimental and not for use in anything you would like to trust. The 2.2.00 release of MINC at the start of this email should be considered the current stable release. Thanks a From a.janke at gmail.com Sat Sep 29 23:21:21 2012 From: a.janke at gmail.com (Andrew Janke) Date: Sun, 30 Sep 2012 13:21:21 +1000 Subject: [MINC-users] mincreshape +/-direction options (again) In-Reply-To: References: Message-ID: Hi Alex, I'm all for this option. The reasons for doing this are not that important in HDF files. I've put it down as an issue here: https://github.com/BIC-MNI/minc-tools/issues/1 a On 18 September 2012 00:38, Alex Zijdenbos wrote: > I can think of a few ways to address this: > > - modify mincreshape to "just work" for [+-][xyz]direction