From andrewkrause at ucla.edu Mon Oct 3 14:18:55 2011 From: andrewkrause at ucla.edu (andrewkrause at ucla.edu) Date: Mon, 03 Oct 2011 11:18:55 -0700 Subject: [MINC-users] minctracc and mincresample question Message-ID: <20111003111855.2044324t6naoh3ms@mail.ucla.edu> Hi everyone, We've been using minctracc and mincresample to register skull-stripped images as part of our workflow, but we recently found out that registration might work better using the whole image before skullstripping. I was hoping to save some work by registering the images with the skull on using minctracc, and then take the xfm output file from that and apply it to the skull-stripped versions with mincresample. However, when I do that, I end up with blank registered images. Looking at the matrices in the xfm files of the registered with skull on and registered with skull off images, I noticed that the first three columns are fairly similar but the last column is very different. Does anyone have any ideas as to why it's not working? I can post the script I wrote to do this if it helps. Thanks, Andrew From a.janke at gmail.com Mon Oct 3 17:31:15 2011 From: a.janke at gmail.com (Andrew Janke) Date: Tue, 4 Oct 2011 07:31:15 +1000 Subject: [MINC-users] minctracc and mincresample question In-Reply-To: <20111003111855.2044324t6naoh3ms@mail.ucla.edu> References: <20111003111855.2044324t6naoh3ms@mail.ucla.edu> Message-ID: Hi Andrew, > We've been using minctracc and mincresample to register skull-stripped > images as part of our workflow, but we recently found out that registration > might work better using the whole image before skullstripping. I was hoping > to save some work by registering the images with the skull on using > minctracc, and then take the xfm output file from that and apply it to the > skull-stripped versions with mincresample. However, when I do that, I end up > with blank registered images. Looking at the matrices in the xfm files of > the registered with skull on and registered with skull off images, I noticed > that the first three columns are fairly similar but the last column is very > different. Does anyone have any ideas as to why it's not working? I can post > the script I wrote to do this if it helps. The last column of a xfm matrix can be thought of as linear shifts in X, Y and Z. As such, my guess is that if you are using BET (via a conversion to NIFTI) to skull strip the images the co-ordinates of the stripped image is being altered along the way. The last column of a xfm matrix is the transformation parameters. Perhaps can you post the results of mincinfo on both your original and skull stripped images? if they are different then you can do something hackish like this: $ cp original.mnc final.mnc $ minccopy stripped.mnc final.mnc To get your original co-ordinates back. This will just copy the data from the stripped image into final.mnc leaving the co-ordinate information intact. Thanks a From se at hst.aau.dk Tue Oct 4 08:36:19 2011 From: se at hst.aau.dk (Simon Fristed Eskildsen) Date: Tue, 4 Oct 2011 12:36:19 +0000 Subject: [MINC-users] Building Register on Ubuntu In-Reply-To: References: , Message-ID: <359F4F9E7F6F4E49A954A8AB5DEFAB840220AD@AD-EXCHMBX2-4.aau.dk> Hello, Did this fix ever find its way into the official release? N3 still complains about this. Even the cvs code does not compile. Simon ________________________________________ From: minc-users-bounces at bic.mni.mcgill.ca [minc-users-bounces at bic.mni.mcgill.ca] on behalf of Vladimir Fonov [vladimir.fonov at gmail.com] Sent: May 1, 2010 21:47 To: MINC users mailing list Subject: Re: [MINC-users] Building Register on Ubuntu Hello, On Sat, May 1, 2010 at 7:16 AM, Andrew Janke wrote: >> /Network/MEDICS/EX/etc/minc-2.0.18/lib/libEBTKS.a(Spline.o): In function >> `RSpline::addDataPoint(float const*, double)': >> /opt/build/source/ebtks-1.6.2/src/Spline.cc:346: undefined reference to >> `Mat& operator+=(Mat&, Mat const&)' >> /opt/build/source/ebtks-1.6.2/src/Spline.cc:347: undefined reference to >> `Mat& operator+=(Mat&, Mat const&)' >> /Network/MEDICS/EX/etc/minc-2.0.18/lib/libEBTKS.a(Spline.o): In function >> `Mat::operator-() const': >> /opt/build/source/ebtks-1.6.2/./templates/Matrix.h:486: undefined reference >> to `Mat& operator-=(Mat&, Mat >> const&)' > > This is a problem with EBTKS and versions of g++ greater than 4.2. > You will have to either get the version of EBTKS from CVS or build > with an older version of g++ and then re-link N3 against this. It's also possible to try this (fixed) version of EBTKS: http://www.bic.mni.mcgill.ca/~vfonov/software/ebtks-1.6.2.tar.gz -- Best regards, Vladimir S. Fonov ~ v.s.fonov <@> ilmarin.info _______________________________________________ MINC-users at bic.mni.mcgill.ca http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users From andrewkrause at ucla.edu Tue Oct 4 14:52:18 2011 From: andrewkrause at ucla.edu (andrewkrause at ucla.edu) Date: Tue, 04 Oct 2011 11:52:18 -0700 Subject: [MINC-users] minctracc and mincresample question In-Reply-To: References: <20111003111855.2044324t6naoh3ms@mail.ucla.edu> Message-ID: <20111004115218.13306lmu6d38ji0w@mail.ucla.edu> Hello, There's a lot of file conversion happening in the original workflow, so I thought it might be something like that. We received DICOM files from the scanner, converted them to Analyze format, skull-stripped, then converted them into MNC and registered with those files. Here's what mincinfo gives on the skull-stripped version before registration: image: unsigned short 0 to 65535 image dimensions: zspace yspace xspace dimension name length step start -------------- ------ ---- ----- zspace 256 1 0 yspace 224 1 0 xspace 192 1 0 and after registration: image: unsigned short 0 to 65535 image dimensions: yspace zspace xspace dimension name length step start -------------- ------ ---- ----- yspace 230 1 -130 zspace 230 1 -92 xspace 230 1 -109 Here's mincinfo on the non-skull-stripped version before registration: image: unsigned short 0 to 65535 image dimensions: zspace yspace xspace dimension name length step start -------------- ------ ---- ----- zspace 256 1 0 yspace 224 1 0 xspace 192 1 0 and after registration (using the skull-stripped xfm file): image: unsigned short 0 to 65535 image dimensions: zspace yspace xspace dimension name length step start -------------- ------ ---- ----- zspace 181 1 -72 yspace 217 1 -126 xspace 181 1 -90 -- Andrew Quoting Andrew Janke : > Hi Andrew, > >> We've been using minctracc and mincresample to register skull-stripped >> images as part of our workflow, but we recently found out that registration >> might work better using the whole image before skullstripping. I was hoping >> to save some work by registering the images with the skull on using >> minctracc, and then take the xfm output file from that and apply it to the >> skull-stripped versions with mincresample. However, when I do that, I end up >> with blank registered images. Looking at the matrices in the xfm files of >> the registered with skull on and registered with skull off images, I noticed >> that the first three columns are fairly similar but the last column is very >> different. Does anyone have any ideas as to why it's not working? I can post >> the script I wrote to do this if it helps. > > The last column of a xfm matrix can be thought of as linear shifts in > X, Y and Z. As such, > my guess is that if you are using BET (via a conversion to NIFTI) to > skull strip the images the co-ordinates of the stripped image is being > altered along the way. The last column of a xfm matrix is the > transformation parameters. > > Perhaps can you post the results of mincinfo on both your original and > skull stripped images? if they are different then you can do > something hackish like this: > > $ cp original.mnc final.mnc > $ minccopy stripped.mnc final.mnc > > To get your original co-ordinates back. This will just copy the data > from the stripped image into final.mnc leaving the co-ordinate > information intact. > > Thanks > > > a > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > From andrewkrause at ucla.edu Wed Oct 5 20:27:35 2011 From: andrewkrause at ucla.edu (andrewkrause at ucla.edu) Date: Wed, 05 Oct 2011 17:27:35 -0700 Subject: [MINC-users] minctracc and mincresample question In-Reply-To: <20111004115218.13306lmu6d38ji0w@mail.ucla.edu> References: <20111003111855.2044324t6naoh3ms@mail.ucla.edu> <20111004115218.13306lmu6d38ji0w@mail.ucla.edu> Message-ID: <20111005172735.105553ctvl1xy2gw@mail.ucla.edu> And of course now I see that somehow the resizing during resampling got lost in the many edits to the script, and that might be what's causing the problem. Thanks for your help! -- Andrew Quoting andrewkrause at ucla.edu: > Hello, > > There's a lot of file conversion happening in the original workflow, > so I thought it might be something like that. We received DICOM > files from the scanner, converted them to Analyze format, > skull-stripped, then converted them into MNC and registered with > those files. > > Here's what mincinfo gives on the skull-stripped version before registration: > > image: unsigned short 0 to 65535 > image dimensions: zspace yspace xspace > dimension name length step start > -------------- ------ ---- ----- > zspace 256 1 0 > yspace 224 1 0 > xspace 192 1 0 > > and after registration: > > image: unsigned short 0 to 65535 > image dimensions: yspace zspace xspace > dimension name length step start > -------------- ------ ---- ----- > yspace 230 1 -130 > zspace 230 1 -92 > xspace 230 1 -109 > > > > Here's mincinfo on the non-skull-stripped version before registration: > > image: unsigned short 0 to 65535 > image dimensions: zspace yspace xspace > dimension name length step start > -------------- ------ ---- ----- > zspace 256 1 0 > yspace 224 1 0 > xspace 192 1 0 > > and after registration (using the skull-stripped xfm file): > > image: unsigned short 0 to 65535 > image dimensions: zspace yspace xspace > dimension name length step start > -------------- ------ ---- ----- > zspace 181 1 -72 > yspace 217 1 -126 > xspace 181 1 -90 > > > -- Andrew > > Quoting Andrew Janke : > >> Hi Andrew, >> >>> We've been using minctracc and mincresample to register skull-stripped >>> images as part of our workflow, but we recently found out that registration >>> might work better using the whole image before skullstripping. I was hoping >>> to save some work by registering the images with the skull on using >>> minctracc, and then take the xfm output file from that and apply it to the >>> skull-stripped versions with mincresample. However, when I do >>> that, I end up >>> with blank registered images. Looking at the matrices in the xfm files of >>> the registered with skull on and registered with skull off images, >>> I noticed >>> that the first three columns are fairly similar but the last column is very >>> different. Does anyone have any ideas as to why it's not working? >>> I can post >>> the script I wrote to do this if it helps. >> >> The last column of a xfm matrix can be thought of as linear shifts in >> X, Y and Z. As such, >> my guess is that if you are using BET (via a conversion to NIFTI) to >> skull strip the images the co-ordinates of the stripped image is being >> altered along the way. The last column of a xfm matrix is the >> transformation parameters. >> >> Perhaps can you post the results of mincinfo on both your original and >> skull stripped images? if they are different then you can do >> something hackish like this: >> >> $ cp original.mnc final.mnc >> $ minccopy stripped.mnc final.mnc >> >> To get your original co-ordinates back. This will just copy the data >> from the stripped image into final.mnc leaving the co-ordinate >> information intact. >> >> Thanks >> >> >> a >> _______________________________________________ >> MINC-users at bic.mni.mcgill.ca >> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users >> > > > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > From berliner55 at gmail.com Fri Oct 7 11:03:11 2011 From: berliner55 at gmail.com (Friedrich Dong) Date: Fri, 7 Oct 2011 11:03:11 -0400 Subject: [MINC-users] simulating real and imaginary images -- does it work? In-Reply-To: References: Message-ID: Dear Andrew, It has been a while since our last communication. I do not use C++, and did not install mrisim. I did not know if one can simulate real+imaginary mri from the brainweb website, as one can do for magnitude mri. I would appreciate it if you would provide information on this. Thanks! On Wed, Jan 5, 2011 at 12:44 AM, Andrew Janke wrote: > Hi > > You can get mrisim from here: > > http://packages.bic.mni.mcgill.ca/tgz/ > > And yes it is for simulation, it's what is behind Brainweb. > > > -- > Andrew Janke > (a.janke at gmail.com || http://a.janke.googlepages.com/) > Canberra->Australia +61 (402) 700 883 > > > On 24 December 2010 01:41, Friedrich Dong wrote: > > Hi Andrew, > > > > I meant BrainWeb. But how can I get mrisim? Is it for MRI simulation? > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > From a.janke at gmail.com Sun Oct 9 08:44:03 2011 From: a.janke at gmail.com (Andrew Janke) Date: Sun, 9 Oct 2011 22:44:03 +1000 Subject: [MINC-users] simulating real and imaginary images -- does it work? In-Reply-To: References: Message-ID: Hi Friedrich, My understanding is no. a On 8 October 2011 01:03, Friedrich Dong wrote: > I did not know if one can simulate real+imaginary mri from the brainweb > website, as one can do for magnitude mri. From zijdenbos at gmail.com Thu Oct 27 22:56:39 2011 From: zijdenbos at gmail.com (Alex Zijdenbos) Date: Thu, 27 Oct 2011 22:56:39 -0400 Subject: [MINC-users] interpolating missing slices? Message-ID: Hello all, I have a stack of image slices with some slices missing, and I would like to stitch those together into a volume by interpolating the missing slices. Does anybody have a suggestion on what would be an efficient way to do this? I initially thought volregrid would do this sort of thing but it seems not (or if it does, I have not been able to figure out how to use it :) Thanks, -- Alex From a.janke at gmail.com Thu Oct 27 23:08:44 2011 From: a.janke at gmail.com (Andrew Janke) Date: Fri, 28 Oct 2011 14:08:44 +1100 Subject: [MINC-users] interpolating missing slices? In-Reply-To: References: Message-ID: Hi Alex, > I have a stack of image slices with some slices missing, and I would > like to stitch those together into a volume by interpolating the > missing slices. Does anybody have a suggestion on what would be an > efficient way to do this? I initially thought volregrid would do this > sort of thing but it seems not (or if it does, I have not been able to > figure out how to use it :) Well volregrid will do it but it's probably not the most straight forward way. I do this: 1. hack the volume up into a series of 1 slice images and skip the blank ones. for i in `seq 1 200`; do mincreshape -dimrange zspace=$i,1 in.mnc tmp/$i.mnc done # remove the dud ones rm tmp/mnc 2. put it all back together mincconcat tmp/*.mnc concat.mnc 3. You will not have a volume with irregular spacing. so make it regular: mincresample -sync -zstep 1 concat.mnc concat-reg.mnc This is a little script of mine that will figure out a good step size for step 3 in you are interested. It also makes the volume isotropic so perhaps not what you want http://packages.bic.mni.mcgill.ca/scripts/voliso If however your data is label data, then I'd use morphological interpolation, I am writing code to do this now for some mouse mapping labels that I can make available. ta a From zijdenbos at gmail.com Thu Oct 27 23:43:10 2011 From: zijdenbos at gmail.com (Alex Zijdenbos) Date: Thu, 27 Oct 2011 23:43:10 -0400 Subject: [MINC-users] autocrop/MincUtilties and step precision Message-ID: Hello all, I have stumbled on something I might consider a bug in autocrop; although it is somewhat intricate. It turns out that if one uses the 'v' specification to for instance expand a volume with a certain number of voxels, like so: autocrop -isoexpand 1v the actual expansion may be 2 voxels instead of one. The reason for this is that autocrop converts the 'voxel' specification to a floating point distance, that subsequently is used together with the step size to (re)calculate the number of voxels for the expansion. The latter happens in MNI::MincUtilities::compute_reshape_args: $count[$i] = round ($extent->[$i] / $step->[$i], 1, +1); since the step size returned by 'mincinfo -attvalue [xyz]space:step' has limited precision, you are likely to get a step size that looks like this: 0.0060000000000000001249 (yes these are small voxels). What then happens is the $count[$i] in the statement above, which is always rounded up, ends up at the next integer value, and so in the end the '1v' specification in the autocrop call turns into '2v' - which is probably not what you wanted when you asked for '1v'. There are a few ways to solve this; one suggestion would be to change the above line in MincUtilities to something like: $count[$i] = round ($extent->[$i] / $step->[$i] - 1e-6, 1, +1); thus leaving a tiny bit of slack for precision trouble. But there are other ways, such as to treat the 'v' specification separately and not go through all the floating point calculations in that case - somewhat more work to do. Suggestions? -- Alex PS Re: precision: $ minc_modify_header -dinsert zspace:step=0.006 test.mnc $ mincinfo -attvalue zspace:step test.mnc 0.0060000000000000001249 I assume this reflects the inherent precision of the variable storage in... HDF5? From zijdenbos at gmail.com Thu Oct 27 23:46:31 2011 From: zijdenbos at gmail.com (Alex Zijdenbos) Date: Thu, 27 Oct 2011 23:46:31 -0400 Subject: [MINC-users] interpolating missing slices? In-Reply-To: References: Message-ID: Ah - great - I keep forgetting how powerful MINC is :-) had not thought of using its support for irregular slice spacing. This works - thanks! On Thu, Oct 27, 2011 at 11:08 PM, Andrew Janke wrote: > Hi Alex, > >> I have a stack of image slices with some slices missing, and I would >> like to stitch those together into a volume by interpolating the >> missing slices. Does anybody have a suggestion on what would be an >> efficient way to do this? I initially thought volregrid would do this >> sort of thing but it seems not (or if it does, I have not been able to >> figure out how to use it :) > > Well volregrid will do it but it's probably not the most straight > forward way. I do this: > > 1. hack the volume up into a series of 1 slice images and skip the blank ones. > > ? for i in `seq 1 200`; do > ? ? ?mincreshape -dimrange zspace=$i,1 in.mnc tmp/$i.mnc > ? done > > ? # remove the dud ones > ? rm tmp/mnc > > 2. put it all back together > > ? mincconcat tmp/*.mnc concat.mnc > > 3. You will not have a volume with irregular spacing. ?so make it regular: > > ? mincresample -sync -zstep 1 concat.mnc concat-reg.mnc > > This is a little script of mine that will figure out a good step size > for step 3 in you are interested. It also makes the volume isotropic > so perhaps not what you want > > ?http://packages.bic.mni.mcgill.ca/scripts/voliso > > If however your data is label data, then I'd use morphological > interpolation, I am writing code to do this now for some mouse mapping > labels that I can make available. > > ta > > > a > > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > > From zijdenbos at gmail.com Fri Oct 28 11:59:24 2011 From: zijdenbos at gmail.com (Alex Zijdenbos) Date: Fri, 28 Oct 2011 11:59:24 -0400 Subject: [MINC-users] interpolating missing slices? In-Reply-To: References: Message-ID: Hi Andrew, One issue that came up here: I assume you meant '-sinc' in the mincesample call; but interestingly, mincresample seems to ignore any interpolation suggestion in this scenario; it seems to always use linear interpolation regardless of what you specify on the command line. In other words, mincresample -nearest mincresample -trilinear mincresample -sinc when resampling a volume with irregular slice spacing all give identical output. That seems like a bug to me...? -- A On Thu, Oct 27, 2011 at 11:08 PM, Andrew Janke wrote: > Hi Alex, > >> I have a stack of image slices with some slices missing, and I would >> like to stitch those together into a volume by interpolating the >> missing slices. Does anybody have a suggestion on what would be an >> efficient way to do this? I initially thought volregrid would do this >> sort of thing but it seems not (or if it does, I have not been able to >> figure out how to use it :) > > Well volregrid will do it but it's probably not the most straight > forward way. I do this: > > 1. hack the volume up into a series of 1 slice images and skip the blank ones. > > ? for i in `seq 1 200`; do > ? ? ?mincreshape -dimrange zspace=$i,1 in.mnc tmp/$i.mnc > ? done > > ? # remove the dud ones > ? rm tmp/mnc > > 2. put it all back together > > ? mincconcat tmp/*.mnc concat.mnc > > 3. You will not have a volume with irregular spacing. ?so make it regular: > > ? mincresample -sync -zstep 1 concat.mnc concat-reg.mnc > > This is a little script of mine that will figure out a good step size > for step 3 in you are interested. It also makes the volume isotropic > so perhaps not what you want > > ?http://packages.bic.mni.mcgill.ca/scripts/voliso > > If however your data is label data, then I'd use morphological > interpolation, I am writing code to do this now for some mouse mapping > labels that I can make available. > > ta > > > a > > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > > From assemlal at cim.mcgill.ca Sun Oct 30 17:58:25 2011 From: assemlal at cim.mcgill.ca (Haz-Edine Assemlal) Date: Sun, 30 Oct 2011 17:58:25 -0400 Subject: [MINC-users] [MINC-development] GLUT colours In-Reply-To: <3E5A7A72-A770-451E-8A67-8D2227795460@phenogenomics.ca> References: <3A53A56C-954C-4AB8-856A-AF1F9B6E280F@phenogenomics.ca> <3E5A7A72-A770-451E-8A67-8D2227795460@phenogenomics.ca> Message-ID: I confirm this issue, I had the same artefact on OS 10.6. It is my understanding that those problems come from the GLUT library. Also it seems that there are similar issues when compiling Display on newer versions of Ubuntu. Regards, Haz-Edine On 2011-10-30, at 3:30 PM, Jason Lerch wrote: > Let's try this again without attachment (the list complained). > >> From: Jason Lerch >> Subject: GLUT colours >> Date: 30 October, 2011 3:18:40 PM EDT >> To: MINC development discussion & planning >> >> Hi all, >> >> I was rebuilding all the MINCy goodness on OS 10.7, and am running into some fun psychedelic colours with Display and register (see attached). Anybody have any hints about where to look to solve this? I remember a message from Jim a few months/years ago which appeared to suggest that this issue was somehow tied into MINC versions, supposedly patched in 2.0.19. I'm using 2.1, in case that is indeed the issue; if anyone remembers where in the MINC codebase that colourful output was created I can look to see if it's still there or has somehow returned ... >> >> Thanks, >> >> Jason >> >> > > _______________________________________________ > MINC-development mailing list > MINC-development at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development