From ilana at bic.mni.mcgill.ca Tue Oct 1 10:56:35 2013 From: ilana at bic.mni.mcgill.ca (Ilana Leppert) Date: Tue, 1 Oct 2013 10:56:35 -0400 Subject: [MINC-users] MINC tools for diffusion weighted images In-Reply-To: References: <20130926061926.GA28198@kensho.slice> <26119_1380262684_5245231C_26119_23_1_2b57d17d56f44ca4911aba99f6a71c09@EXHUB2010-1.campus.MCGILL.CA> Message-ID: Hi, The toolkit you mention (mincdiffusion, developed by Jennifer Campbell), is in the process of being packaged and with Vlad's help, we plan to include it in the standard minc distribution. On Fri, Sep 27, 2013 at 2:16 AM, Andrew Janke wrote: > Hi Jon, > > > What sorts of tools are there for working with diffusion weighted images > > in MINC? > > > > Specifically, my wish list includes tools enabling me to: > > 1. convert the DWI from our raw dicoms to minc format preserving > > diffusion parameters > > dcm2mnc should preserve this for you. Take a look at the GIT history > of dcm2mnc and you will see a lot of commits around this from Bruce > Pikes group. > > > 2. merge multiple DWI acquisitions for single subject > > Depends on what level. But no pre-canned methods in MINC that I know > of for public download. > We do a linear registration between runs and concatenate the volumes and diffusion header information. > > 3. perform registration of the DWI image to a structural scan (updating > > directions) > > Not that I know of. But again, this depends on the method, are you > correcting the raw data or the first order tensor approximation? if > the raw data, I can't imagine this being too hard to do with a few > judicious calls to minccalc, when doing this are you also planning on > doing some form of mass preservation for nonlinear deformations? If so > this can be achieved by using mincblob -determinant on the resulting > field and multiplying the result with the resampled volume. But again, > no pre-canned tool but something that could be simply scripted using > python/perl. Jason will no doubt point you to pyminc! > This is part of the pre-processing, but only linear registrations are implemented. A program called 'transform_diff_dirs' takes care of updating the directions. > > 4. estimate a diffusion tensor > > The code I released for this many years ago when first order tensor > approximations were all the rage (mincdti) is still there and works. > Others have matlab toolboxes and other things around this, I don't > know of a public release of these though. Perhaps they can chime in > here. (Illana and Jennifer come to mind). > Yes, we have 'minctensor.pl', which uses matlab, which outputs the tensor, FA, MD and a color-coded by direction RGB. > > > 5. export the DWI (and DTI) volume to other well-known formats (nifti > > or NRRD mostly) for further processing. > > No idea on that one. > I have found mnc2nii to work well, even for diffusion (you'll have to grab the diffusion information from the header). Vlad worked on some code using ITK, which can convert back and forth from NRRD. Some DTI volumes (eigenvectors, eigenvalues) might require some extra manipulation because different software expect different formats. > > > From my searching so far it looks like there is a toolkit[1] for MINC > > that should do most of the above, but I'm not sure if it is a) still > > maintained, or b) available to the public (seems one must have a BIC > > username to check out the source?). There is also the mincdti > > program[2] but I believe that only estimates a tensor. > > Correct, only a first order tensor, and then FA, ISO, etc from that. > We have some tools for estimating multiple fiber populations per voxel (Spherical Deconvolution) as well as tracking using FACT or the maxima from of the fiber ODF resulting from the deconvolution. There are also some nice 3D visualization tools. > > > What are my other options? With the minc integration into ITK are there > > perhaps ITK-based toolkits you could recommend? > > ITK is probably a good vector. > > > a > I hope that helps, maybe Jen would like to add some more info... Ilana > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > From sorench at gmail.com Tue Oct 1 15:08:35 2013 From: sorench at gmail.com (Soren Christensen) Date: Tue, 1 Oct 2013 12:08:35 -0700 Subject: [MINC-users] mincreshape segfault and general behavior Message-ID: Hi, I was hoping someone could explain the below mincreshape behavior. Basically I get segfaults for certain choices of dimsizes. When I leave Z unmodified, the file is written, but with padding. 1) I assume the segfault is a bug? (or am I feeding illegal input) 2) Why is padding introduced? Is it padded to achieve volume averaging of whole voxels only (as opposed to fractions). 3) Is it correctly understood that mincreshape does volume averaging for downsizing as opposed to mincreshape that will just use the specified interpolation method? Thanks Soren MNC$ mi A.mnc file: A.mnc image: signed__ float -2048.041015625 to 3123.968017578125 image dimensions: time zspace yspace xspace dimension name length step start -------------- ------ ---- ----- time 19 1 0 zspace 312 0.5 -585.268 yspace 420 -0.43 70.4 xspace 342 -0.43 80.112 MNC$ mincreshape -clobber -dimsize xspace=100 -dimsize yspace=100 -dimsize zspace=100 A.mnc B.mnc Copying chunks:......Segmentation fault (core dumped) s at s-IdeaCentre-K450:/data2/TOSH_DATA/DATA/MNC$ mincreshape -clobber -dimsize xspace=100 -dimsize yspace=100 -dimsize zspace=312 A.mnc B.mnc Copying chunks:.................................................................................................................................................................. [works] From a.janke at gmail.com Wed Oct 2 10:54:09 2013 From: a.janke at gmail.com (Andrew Janke) Date: Thu, 3 Oct 2013 00:54:09 +1000 Subject: [MINC-users] mincreshape segfault and general behavior In-Reply-To: References: Message-ID: Hi Soren, > I was hoping someone could explain the below mincreshape behavior. > Basically I get segfaults for certain choices of dimsizes. > When I leave Z unmodified, the file is written, but with padding. > 1) I assume the segfault is a bug? (or am I feeding illegal input) At a guess I'd say this is a problem that I've seen surface a few times with particular combinations of HDF, netCDF and MINC2.x when working on MINC1 files. Are the input files MINC1 or MINC2? If MINC1, you should be able to get around this by running mincconvert on them. > 3) Is it correctly understood that mincreshape does volume averaging for > downsizing as opposed to mincreshape that will just use the specified > interpolation method? I take it you mean mincresample here? If so then mincreshape does no averaging or interpolating and mincresample does. a From sorench at gmail.com Wed Oct 2 17:21:17 2013 From: sorench at gmail.com (Soren Christensen) Date: Wed, 2 Oct 2013 14:21:17 -0700 Subject: [MINC-users] mincreshape segfault and general behavior In-Reply-To: References: Message-ID: Hi Andrew, It's a MINC2 file. Sorry I meant mincresample where marked below: > > 3) Is it correctly understood that mincreshape does volume averaging for > > downsizing as opposed to *mincresample* that will just use the specified > > interpolation method? > Let me make sure I understand this right. Are you saying mincreshape does no volume averaging? If you reshape from a dimsize of 512 to 256 for example, then isn't each voxel a 4x4 average of the input? I just verified that it is, but maybe we mean different things by volume averaging? Thanks Soren > > a > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users From zijdenbos at gmail.com Wed Oct 2 18:56:51 2013 From: zijdenbos at gmail.com (Alex Zijdenbos) Date: Wed, 2 Oct 2013 18:56:51 -0400 Subject: [MINC-users] mincreshape segfault and general behavior In-Reply-To: References: Message-ID: Hi Soren, Andrew can throw in his $0.02, but to my knowledge, neither mincreshape nor mincresample does the kind of volume averaging that you describe. MINC considers voxel values as a lattice of dimensionless point samples; the step sizes are distances between those points, and are therefore attributes of the volume, not the voxel. mincresample will interpolate between the point samples when it needs to, but it will not average. In other words, if you would use mincresample to downsample by a factor of 3 in all dimensions (collapse each 3x3x3 cube into a single voxel at the same point location), you are simply tossing out 26 of the 27 voxel values in each 3x3x3 cube - you are not averaging them. I have raised this a few times (very recently even), but even though it may be counter-intuitive to many, it is by Peter's design. In my scripts I usually call mincblur before mincresample when I know I will be downsampling. mincreshape will only massage how the lattice is arranged, allowing you to extract hyperslabs and etc; it does not change the point samples (voxel values), will not interpolate, and would/should certainly not do any averaging. Well that is all my understanding at least :) -- A On Wed, Oct 2, 2013 at 5:21 PM, Soren Christensen wrote: > Hi Andrew, > It's a MINC2 file. > > Sorry I meant mincresample where marked below: >> > 3) Is it correctly understood that mincreshape does volume averaging for >> > downsizing as opposed to *mincresample* that will just use the specified >> > interpolation method? >> > > Let me make sure I understand this right. Are you saying mincreshape does > no volume averaging? If you reshape from a dimsize of 512 to 256 for > example, then isn't each voxel a 4x4 average of the input? > > I just verified that it is, but maybe we mean different things by volume > averaging? > > Thanks > > Soren > > > >> >> 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 sorench at gmail.com Wed Oct 2 22:04:25 2013 From: sorench at gmail.com (Soren Christensen) Date: Wed, 2 Oct 2013 19:04:25 -0700 Subject: [MINC-users] mincreshape segfault and general behavior In-Reply-To: References: Message-ID: Thanks again for comments, > - I am not sure why you would simulate noise for this example, that just > seems to make things harder to see > Sure - I just wanted some quick values for numerical comparison. I added the circle to see how the edges were affected. > - the mincreshape call that you used simply crops the image, from > 512x512x2 to 128x128x1, it wouldn't change anything to the actual > (remaining) voxel values at all. > Mind you i am not using -dimrange here which I could have used for a crop. To me a crop preserves the steps. That's not the case here, the steps behave as you'd expect for volume averaging (and I believe inconsistent with a crop): s at s-IdeaCentre-K450:/data2/matlabwork/simcode$ mi test.mnc test_reshaped.mnc file: test.mnc image: signed__ float 0 to 1 image dimensions: time zspace yspace xspace dimension name length step start -------------- ------ ---- ----- time 1 unknown unknown zspace 2 1 0 yspace 512 -1 0 xspace 512 -1 0 file: test_reshaped.mnc image: signed__ float 0 to 1 image dimensions: time zspace yspace xspace dimension name length step start -------------- ------ ---- ----- time 1 1 0 zspace 1 2 0.5 yspace 128 -4 -1.5 xspace 128 -4 -1.5 > mincresample -like test.mnc test_reshaped.mnc test_new.mnc > > and look at the difference between test.mnc and test_new.mnc, you should > see that it has zero difference in the 128x128x1 region that you cropped. > I believe it is evident from the dims and sizes that it is not a crop here. If I follow your suggestion I get an empty image out (max=0), I believe this is because the source voxelcenter is not exactly 0.5 voxel from the target grid. It's definitely not a crop. If it was, the circle you see (from slice 0) would come out clean. It is not. It's mixed with noise (strongly assumed from slice 1). I would think a crop would require starts and lengths too - not just lengths. > > - it is not immediately clear to me why your matlab code/diff seems too > agree with the volume averaging idea, but I'm sure there is a logical > explanation for it > > I still don't see anything to suggest it is not volume averaging. It's definitely not a crop - I have used it extensively recently and I'd see about a quarter of my images missing. If it was a nearest neighbor re-sampling I would not see edge blurring. I had a look at the code but it is beyond me. I think they core of it is here: if (really_copy_the_data) { /* Read in the data */ (void) miicv_get(reshape_info->icvid, input_start, input_count, chunk_data); /* Write it out */ (void) ncvarputg(reshape_info->outmincid, reshape_info->outimgid, output_start, output_count, NULL, output_imapncvarput, output_origin); } I have trouble understanding from the ncvarputg call how this would iterate over inputs contained in the output voxel (assuming it does volume average), but maybe someone here can help. Thanks Soren -- A > > > On Wed, Oct 2, 2013 at 7:21 PM, Soren Christensen wrote: > >> Thanks for the feedback Alex, >> Well I guess a peek at the code is coming closer.. >> I ran a little test making a 512*512*2 noise image (std 1, mena 0 ) with >> a circle in the middle (to better see edge blurring). >> (figure below - also sent to your email to make sure you see the image) >> >> 1) Volume average in 4x4x2 blocks in Matlab >> 2) mincreshape to 128x128x1 >> >> The images differ by maximally 4.9596e-08 which I guess is precision >> issues - since I simulated a double but store a single. >> So unless somehow interpolation in this particular case is supposed to >> yield a similar result (my understanding is that biliniear interpolation >> uses immediate neighbors, but here we are in a 4x4 neighborhood so it >> should not - it may have been similar for a 2x2x2 case). >> So at least this seems to me that it is indeed volume averaging? >> I'll have a look at the code later tonight, but hoping someone could >> enlighten us.. >> >> Soren >> >> >> >> >> >> clear >> >> *%%sim image* >> opimg=rand(512,512,2); >> %save opimg opimg >> %load opimg >> [x,y]=meshgrid(1:512); >> circ=sqrt((x-256).^2+(y-256).^2)<50; >> opimg(128:383,128:383,1)=circ(128:383,128:383); >> >> *%write + reshape* >> mymincwrite(permute(opimg,[1 2 4 3]),'test.mnc',[]) >> system(['mincreshape -clobber -dimsize xspace=128 -dimsize yspace=128 >> -dimsize zspace=1 test.mnc test_reshaped.mnc']) >> >> >> >> >> *%matlab volume averaging* >> recon=zeros(128)*nan; >> for irow=1:128 >> for icol=1:128 >> rindx=(irow-1)*4+1; >> cindx=(icol-1)*4+1; >> zindx=1:2; >> vals=opimg(rindx:(rindx+3),cindx:(cindx+3),zindx); >> recon(irow,icol)=mean( vals(:)); >> end >> end >> >> >> sc(recon) >> m=newmr('test_reshaped.mnc'); >> sc(m-recon) >> tmp=m-recon; >> maxabserr=max(abs(tmp(:))) >> 1st image: Simulated (2 concatted slices) >> 2nd image:Mincresahped >> 3rd: mincreshaped-matlab reshaped - see scale >> >> [image: Inline image 1] >> >> >> >> On Wed, Oct 2, 2013 at 3:56 PM, Alex Zijdenbos wrote: >> >>> Hi Soren, >>> >>> Andrew can throw in his $0.02, but to my knowledge, neither >>> mincreshape nor mincresample does the kind of volume averaging that >>> you describe. MINC considers voxel values as a lattice of >>> dimensionless point samples; the step sizes are distances between >>> those points, and are therefore attributes of the volume, not the >>> voxel. >>> >>> mincresample will interpolate between the point samples when it needs >>> to, but it will not average. In other words, if you would use >>> mincresample to downsample by a factor of 3 in all dimensions >>> (collapse each 3x3x3 cube into a single voxel at the same point >>> location), you are simply tossing out 26 of the 27 voxel values in >>> each 3x3x3 cube - you are not averaging them. I have raised this a few >>> times (very recently even), but even though it may be >>> counter-intuitive to many, it is by Peter's design. In my scripts I >>> usually call mincblur before mincresample when I know I will be >>> downsampling. >>> >>> mincreshape will only massage how the lattice is arranged, allowing >>> you to extract hyperslabs and etc; it does not change the point >>> samples (voxel values), will not interpolate, and would/should >>> certainly not do any averaging. >>> >>> Well that is all my understanding at least :) >>> >>> -- A >>> >>> On Wed, Oct 2, 2013 at 5:21 PM, Soren Christensen >>> wrote: >>> > Hi Andrew, >>> > It's a MINC2 file. >>> > >>> > Sorry I meant mincresample where marked below: >>> >> > 3) Is it correctly understood that mincreshape does volume >>> averaging for >>> >> > downsizing as opposed to *mincresample* that will just use the >>> specified >>> >> > interpolation method? >>> >> >>> > >>> > Let me make sure I understand this right. Are you saying mincreshape >>> does >>> > no volume averaging? If you reshape from a dimsize of 512 to 256 for >>> > example, then isn't each voxel a 4x4 average of the input? >>> > >>> > I just verified that it is, but maybe we mean different things by >>> volume >>> > averaging? >>> > >>> > Thanks >>> > >>> > Soren >>> > >>> > >>> > >>> >> >>> >> 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 >>> > >>> _______________________________________________ >>> MINC-users at bic.mni.mcgill.ca >>> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users >>> >> >> > From zijdenbos at gmail.com Wed Oct 2 22:52:14 2013 From: zijdenbos at gmail.com (Alex Zijdenbos) Date: Wed, 2 Oct 2013 22:52:14 -0400 Subject: [MINC-users] mincreshape segfault and general behavior In-Reply-To: References: Message-ID: Hi Soren, OK, you definitely have stumbled across something strange here, as far as I am concerned. Taking one of the files from mni_models: $ mincreshape -dimsize xspace=128 -dimsize yspace=128 -dimsize zspace=128 /usr/local/bic/share/mni-models/icbm_avg_152_t1_tal_lin.mnc small.mnc Copying chunks:................................................................................................................................Segmentation fault I would say that this shouldn't happen. Although the man page does state that the dimension resizing only applies to image dimensions, which would be xspace and yspace here. Still, a segfault is ugly. $ mincreshape -clobber -dimsize xspace=128 -dimsize yspace=128 /usr/local/bic/share/mni-models/icbm_avg_152_t1_tal_lin.mnc small.mnc Copying chunks:.....................................................................................................................................................................................Done. $ mincinfo /usr/local/bic/share/mni-models/icbm_avg_152_t1_tal_lin.mnc small.mnc file: /usr/local/bic/share/mni-models/icbm_avg_152_t1_tal_lin.mnc image: signed__ short 0 to 4095 image dimensions: zspace yspace xspace dimension name length step start -------------- ------ ---- ----- zspace 181 1 -72 yspace 217 1 -126 xspace 181 1 -90 file: small.mnc image: signed__ short -32768 to 32767 image dimensions: zspace yspace xspace dimension name length step start -------------- ------ ---- ----- zspace 181 1 -72 yspace 128 2 -143.5 xspace 128 2 -125.5 I thought this shouldn't happen either; in fact, I have always been under the impression that mincreshape never changes the step values. But, from the man page: *You want more!?! Okay, okay. Mincreshape makes all of the minc library ICV operations available on the command line. For those who like things defined, an ICV is an image conversion variable (don't ask me why I called it that) which basically lets you tell the data what it's going to look like. In other words, it does a bunch of conversions for you. These conversions include changing type, range and normalization of the voxel values, expanding or contracting images (by voxel duplication or averaging) to give a specified image size, and converting vector images to scalar.* So this is actually (sort of) documented, and I stand corrected - and learned something new about mincreshape. -- A On Wed, Oct 2, 2013 at 10:04 PM, Soren Christensen wrote: > Thanks again for comments, > >> - I am not sure why you would simulate noise for this example, that just >> seems to make things harder to see >> > Sure - I just wanted some quick values for numerical comparison. I added > the circle to see how the edges were affected. > > >> - the mincreshape call that you used simply crops the image, from >> 512x512x2 to 128x128x1, it wouldn't change anything to the actual >> (remaining) voxel values at all. >> > Mind you i am not using -dimrange here which I could have used for a crop. > To me a crop preserves the steps. That's not the case here, the steps > behave as you'd expect for volume averaging (and I believe inconsistent > with a crop): > s at s-IdeaCentre-K450:/data2/matlabwork/simcode$ mi test.mnc > test_reshaped.mnc > file: test.mnc > image: signed__ float 0 to 1 > image dimensions: time zspace yspace xspace > dimension name length step start > -------------- ------ ---- ----- > time 1 unknown unknown > zspace 2 1 0 > yspace 512 -1 0 > xspace 512 -1 0 > > file: test_reshaped.mnc > image: signed__ float 0 to 1 > image dimensions: time zspace yspace xspace > dimension name length step start > -------------- ------ ---- ----- > time 1 1 0 > zspace 1 2 0.5 > yspace 128 -4 -1.5 > xspace 128 -4 -1.5 > > > >> mincresample -like test.mnc test_reshaped.mnc test_new.mnc >> >> > and look at the difference between test.mnc and test_new.mnc, you should >> see that it has zero difference in the 128x128x1 region that you cropped. >> > I believe it is evident from the dims and sizes that it is not a crop > here. If I follow your suggestion I get an empty image out (max=0), I > believe this is because the source voxelcenter is not exactly 0.5 voxel > from the target grid. > > It's definitely not a crop. If it was, the circle you see (from slice 0) > would come out clean. It is not. It's mixed with noise (strongly assumed > from slice 1). > I would think a crop would require starts and lengths too - not just > lengths. > > > >> >> - it is not immediately clear to me why your matlab code/diff seems too >> agree with the volume averaging idea, but I'm sure there is a logical >> explanation for it >> >> > I still don't see anything to suggest it is not volume averaging. It's > definitely not a crop - I have used it extensively recently and I'd see > about a quarter of my images missing. If it was a nearest neighbor > re-sampling I would not see edge blurring. > > > I had a look at the code but it is beyond me. > I think they core of it is here: > > if (really_copy_the_data) { > > /* Read in the data */ > (void) miicv_get(reshape_info->icvid, input_start, input_count, > chunk_data); > > /* Write it out */ > (void) ncvarputg(reshape_info->outmincid, reshape_info->outimgid, > output_start, output_count, NULL, > output_imapncvarput, > output_origin); > > } > > I have trouble understanding from the ncvarputg call how this would > iterate over inputs contained in the output voxel (assuming it does volume > average), but maybe someone here can help. > > Thanks > Soren > > > -- A >> >> >> On Wed, Oct 2, 2013 at 7:21 PM, Soren Christensen wrote: >> >>> Thanks for the feedback Alex, >>> Well I guess a peek at the code is coming closer.. >>> I ran a little test making a 512*512*2 noise image (std 1, mena 0 ) with >>> a circle in the middle (to better see edge blurring). >>> (figure below - also sent to your email to make sure you see the image) >>> >>> 1) Volume average in 4x4x2 blocks in Matlab >>> 2) mincreshape to 128x128x1 >>> >>> The images differ by maximally 4.9596e-08 which I guess is precision >>> issues - since I simulated a double but store a single. >>> So unless somehow interpolation in this particular case is supposed to >>> yield a similar result (my understanding is that biliniear interpolation >>> uses immediate neighbors, but here we are in a 4x4 neighborhood so it >>> should not - it may have been similar for a 2x2x2 case). >>> So at least this seems to me that it is indeed volume averaging? >>> I'll have a look at the code later tonight, but hoping someone could >>> enlighten us.. >>> >>> Soren >>> >>> >>> >>> >>> >>> clear >>> >>> *%%sim image* >>> opimg=rand(512,512,2); >>> %save opimg opimg >>> %load opimg >>> [x,y]=meshgrid(1:512); >>> circ=sqrt((x-256).^2+(y-256).^2)<50; >>> opimg(128:383,128:383,1)=circ(128:383,128:383); >>> >>> *%write + reshape* >>> mymincwrite(permute(opimg,[1 2 4 3]),'test.mnc',[]) >>> system(['mincreshape -clobber -dimsize xspace=128 -dimsize yspace=128 >>> -dimsize zspace=1 test.mnc test_reshaped.mnc']) >>> >>> >>> >>> >>> *%matlab volume averaging* >>> recon=zeros(128)*nan; >>> for irow=1:128 >>> for icol=1:128 >>> rindx=(irow-1)*4+1; >>> cindx=(icol-1)*4+1; >>> zindx=1:2; >>> vals=opimg(rindx:(rindx+3),cindx:(cindx+3),zindx); >>> recon(irow,icol)=mean( vals(:)); >>> end >>> end >>> >>> >>> sc(recon) >>> m=newmr('test_reshaped.mnc'); >>> sc(m-recon) >>> tmp=m-recon; >>> maxabserr=max(abs(tmp(:))) >>> 1st image: Simulated (2 concatted slices) >>> 2nd image:Mincresahped >>> 3rd: mincreshaped-matlab reshaped - see scale >>> >>> [image: Inline image 1] >>> >>> >>> >>> On Wed, Oct 2, 2013 at 3:56 PM, Alex Zijdenbos wrote: >>> >>>> Hi Soren, >>>> >>>> Andrew can throw in his $0.02, but to my knowledge, neither >>>> mincreshape nor mincresample does the kind of volume averaging that >>>> you describe. MINC considers voxel values as a lattice of >>>> dimensionless point samples; the step sizes are distances between >>>> those points, and are therefore attributes of the volume, not the >>>> voxel. >>>> >>>> mincresample will interpolate between the point samples when it needs >>>> to, but it will not average. In other words, if you would use >>>> mincresample to downsample by a factor of 3 in all dimensions >>>> (collapse each 3x3x3 cube into a single voxel at the same point >>>> location), you are simply tossing out 26 of the 27 voxel values in >>>> each 3x3x3 cube - you are not averaging them. I have raised this a few >>>> times (very recently even), but even though it may be >>>> counter-intuitive to many, it is by Peter's design. In my scripts I >>>> usually call mincblur before mincresample when I know I will be >>>> downsampling. >>>> >>>> mincreshape will only massage how the lattice is arranged, allowing >>>> you to extract hyperslabs and etc; it does not change the point >>>> samples (voxel values), will not interpolate, and would/should >>>> certainly not do any averaging. >>>> >>>> Well that is all my understanding at least :) >>>> >>>> -- A >>>> >>>> On Wed, Oct 2, 2013 at 5:21 PM, Soren Christensen >>>> wrote: >>>> > Hi Andrew, >>>> > It's a MINC2 file. >>>> > >>>> > Sorry I meant mincresample where marked below: >>>> >> > 3) Is it correctly understood that mincreshape does volume >>>> averaging for >>>> >> > downsizing as opposed to *mincresample* that will just use the >>>> specified >>>> >> > interpolation method? >>>> >> >>>> > >>>> > Let me make sure I understand this right. Are you saying mincreshape >>>> does >>>> > no volume averaging? If you reshape from a dimsize of 512 to 256 for >>>> > example, then isn't each voxel a 4x4 average of the input? >>>> > >>>> > I just verified that it is, but maybe we mean different things by >>>> volume >>>> > averaging? >>>> > >>>> > Thanks >>>> > >>>> > Soren >>>> > >>>> > >>>> > >>>> >> >>>> >> 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 >>>> > >>>> _______________________________________________ >>>> MINC-users at bic.mni.mcgill.ca >>>> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users >>>> >>> >>> >> > From sorench at gmail.com Thu Oct 3 01:35:20 2013 From: sorench at gmail.com (Soren Christensen) Date: Wed, 2 Oct 2013 22:35:20 -0700 Subject: [MINC-users] mincreshape segfault and general behavior In-Reply-To: References: Message-ID: I did not see that before either. I don't recall segfaults when resizing to an integer multiple of the original dimension length, but conversely non integer choices do not always seem to segfault (from memory). Soren On Wed, Oct 2, 2013 at 7:52 PM, Alex Zijdenbos wrote: > Hi Soren, > > OK, you definitely have stumbled across something strange here, as far as > I am concerned. Taking one of the files from mni_models: > > $ mincreshape -dimsize xspace=128 -dimsize yspace=128 -dimsize zspace=128 > /usr/local/bic/share/mni-models/icbm_avg_152_t1_tal_lin.mnc small.mnc > Copying > chunks:................................................................................................................................Segmentation > fault > > I would say that this shouldn't happen. Although the man page does state > that the dimension resizing only applies to image dimensions, which would > be xspace and yspace here. Still, a segfault is ugly. > > $ mincreshape -clobber -dimsize xspace=128 -dimsize yspace=128 > /usr/local/bic/share/mni-models/icbm_avg_152_t1_tal_lin.mnc small.mnc > Copying > chunks:.....................................................................................................................................................................................Done. > $ mincinfo /usr/local/bic/share/mni-models/icbm_avg_152_t1_tal_lin.mnc > small.mnc > file: /usr/local/bic/share/mni-models/icbm_avg_152_t1_tal_lin.mnc > image: signed__ short 0 to 4095 > image dimensions: zspace yspace xspace > > dimension name length step start > -------------- ------ ---- ----- > zspace 181 1 -72 > yspace 217 1 -126 > xspace 181 1 -90 > > > file: small.mnc > image: signed__ short -32768 to 32767 > image dimensions: zspace yspace xspace > > dimension name length step start > -------------- ------ ---- ----- > zspace 181 1 -72 > yspace 128 2 -143.5 > xspace 128 2 -125.5 > > I thought this shouldn't happen either; in fact, I have always been under > the impression that mincreshape never changes the step values. But, from > the man page: > > *You want more!?! Okay, okay. Mincreshape makes all of the minc library > ICV operations available on the command line. For those who like things > defined, an ICV is an image conversion variable (don't ask me why I called > it that) which basically lets you tell the data what it's going to look > like. In other words, it does a bunch of conversions for you. These > conversions include changing type, range and normalization of the voxel > values, expanding or contracting images (by voxel duplication or averaging) > to give a specified image size, and converting vector images to scalar.* > > So this is actually (sort of) documented, and I stand corrected - and > learned something new about mincreshape. > > -- A > > > On Wed, Oct 2, 2013 at 10:04 PM, Soren Christensen wrote: > >> Thanks again for comments, >> >>> - I am not sure why you would simulate noise for this example, that just >>> seems to make things harder to see >>> >> Sure - I just wanted some quick values for numerical comparison. I added >> the circle to see how the edges were affected. >> >> >>> - the mincreshape call that you used simply crops the image, from >>> 512x512x2 to 128x128x1, it wouldn't change anything to the actual >>> (remaining) voxel values at all. >>> >> Mind you i am not using -dimrange here which I could have used for a crop. >> To me a crop preserves the steps. That's not the case here, the steps >> behave as you'd expect for volume averaging (and I believe inconsistent >> with a crop): >> s at s-IdeaCentre-K450:/data2/matlabwork/simcode$ mi test.mnc >> test_reshaped.mnc >> file: test.mnc >> image: signed__ float 0 to 1 >> image dimensions: time zspace yspace xspace >> dimension name length step start >> -------------- ------ ---- ----- >> time 1 unknown unknown >> zspace 2 1 0 >> yspace 512 -1 0 >> xspace 512 -1 0 >> >> file: test_reshaped.mnc >> image: signed__ float 0 to 1 >> image dimensions: time zspace yspace xspace >> dimension name length step start >> -------------- ------ ---- ----- >> time 1 1 0 >> zspace 1 2 0.5 >> yspace 128 -4 -1.5 >> xspace 128 -4 -1.5 >> >> >> >>> mincresample -like test.mnc test_reshaped.mnc test_new.mnc >>> >>> >> and look at the difference between test.mnc and test_new.mnc, you should >>> see that it has zero difference in the 128x128x1 region that you cropped. >>> >> I believe it is evident from the dims and sizes that it is not a crop >> here. If I follow your suggestion I get an empty image out (max=0), I >> believe this is because the source voxelcenter is not exactly 0.5 voxel >> from the target grid. >> >> It's definitely not a crop. If it was, the circle you see (from slice 0) >> would come out clean. It is not. It's mixed with noise (strongly assumed >> from slice 1). >> I would think a crop would require starts and lengths too - not just >> lengths. >> >> >> >>> >>> - it is not immediately clear to me why your matlab code/diff seems too >>> agree with the volume averaging idea, but I'm sure there is a logical >>> explanation for it >>> >>> >> I still don't see anything to suggest it is not volume averaging. It's >> definitely not a crop - I have used it extensively recently and I'd see >> about a quarter of my images missing. If it was a nearest neighbor >> re-sampling I would not see edge blurring. >> >> >> I had a look at the code but it is beyond me. >> I think they core of it is here: >> >> if (really_copy_the_data) { >> >> /* Read in the data */ >> (void) miicv_get(reshape_info->icvid, input_start, input_count, >> chunk_data); >> >> /* Write it out */ >> (void) ncvarputg(reshape_info->outmincid, reshape_info->outimgid, >> output_start, output_count, NULL, >> output_imapncvarput, >> output_origin); >> >> } >> >> I have trouble understanding from the ncvarputg call how this would >> iterate over inputs contained in the output voxel (assuming it does volume >> average), but maybe someone here can help. >> >> Thanks >> Soren >> >> >> -- A >>> >>> >>> On Wed, Oct 2, 2013 at 7:21 PM, Soren Christensen wrote: >>> >>>> Thanks for the feedback Alex, >>>> Well I guess a peek at the code is coming closer.. >>>> I ran a little test making a 512*512*2 noise image (std 1, mena 0 ) >>>> with a circle in the middle (to better see edge blurring). >>>> (figure below - also sent to your email to make sure you see the image) >>>> >>>> 1) Volume average in 4x4x2 blocks in Matlab >>>> 2) mincreshape to 128x128x1 >>>> >>>> The images differ by maximally 4.9596e-08 which I guess is precision >>>> issues - since I simulated a double but store a single. >>>> So unless somehow interpolation in this particular case is supposed to >>>> yield a similar result (my understanding is that biliniear interpolation >>>> uses immediate neighbors, but here we are in a 4x4 neighborhood so it >>>> should not - it may have been similar for a 2x2x2 case). >>>> So at least this seems to me that it is indeed volume averaging? >>>> I'll have a look at the code later tonight, but hoping someone could >>>> enlighten us.. >>>> >>>> Soren >>>> >>>> >>>> >>>> >>>> >>>> clear >>>> >>>> *%%sim image* >>>> opimg=rand(512,512,2); >>>> %save opimg opimg >>>> %load opimg >>>> [x,y]=meshgrid(1:512); >>>> circ=sqrt((x-256).^2+(y-256).^2)<50; >>>> opimg(128:383,128:383,1)=circ(128:383,128:383); >>>> >>>> *%write + reshape* >>>> mymincwrite(permute(opimg,[1 2 4 3]),'test.mnc',[]) >>>> system(['mincreshape -clobber -dimsize xspace=128 -dimsize yspace=128 >>>> -dimsize zspace=1 test.mnc test_reshaped.mnc']) >>>> >>>> >>>> >>>> >>>> *%matlab volume averaging* >>>> recon=zeros(128)*nan; >>>> for irow=1:128 >>>> for icol=1:128 >>>> rindx=(irow-1)*4+1; >>>> cindx=(icol-1)*4+1; >>>> zindx=1:2; >>>> vals=opimg(rindx:(rindx+3),cindx:(cindx+3),zindx); >>>> recon(irow,icol)=mean( vals(:)); >>>> end >>>> end >>>> >>>> >>>> sc(recon) >>>> m=newmr('test_reshaped.mnc'); >>>> sc(m-recon) >>>> tmp=m-recon; >>>> maxabserr=max(abs(tmp(:))) >>>> 1st image: Simulated (2 concatted slices) >>>> 2nd image:Mincresahped >>>> 3rd: mincreshaped-matlab reshaped - see scale >>>> >>>> [image: Inline image 1] >>>> >>>> >>>> >>>> On Wed, Oct 2, 2013 at 3:56 PM, Alex Zijdenbos wrote: >>>> >>>>> Hi Soren, >>>>> >>>>> Andrew can throw in his $0.02, but to my knowledge, neither >>>>> mincreshape nor mincresample does the kind of volume averaging that >>>>> you describe. MINC considers voxel values as a lattice of >>>>> dimensionless point samples; the step sizes are distances between >>>>> those points, and are therefore attributes of the volume, not the >>>>> voxel. >>>>> >>>>> mincresample will interpolate between the point samples when it needs >>>>> to, but it will not average. In other words, if you would use >>>>> mincresample to downsample by a factor of 3 in all dimensions >>>>> (collapse each 3x3x3 cube into a single voxel at the same point >>>>> location), you are simply tossing out 26 of the 27 voxel values in >>>>> each 3x3x3 cube - you are not averaging them. I have raised this a few >>>>> times (very recently even), but even though it may be >>>>> counter-intuitive to many, it is by Peter's design. In my scripts I >>>>> usually call mincblur before mincresample when I know I will be >>>>> downsampling. >>>>> >>>>> mincreshape will only massage how the lattice is arranged, allowing >>>>> you to extract hyperslabs and etc; it does not change the point >>>>> samples (voxel values), will not interpolate, and would/should >>>>> certainly not do any averaging. >>>>> >>>>> Well that is all my understanding at least :) >>>>> >>>>> -- A >>>>> >>>>> On Wed, Oct 2, 2013 at 5:21 PM, Soren Christensen >>>>> wrote: >>>>> > Hi Andrew, >>>>> > It's a MINC2 file. >>>>> > >>>>> > Sorry I meant mincresample where marked below: >>>>> >> > 3) Is it correctly understood that mincreshape does volume >>>>> averaging for >>>>> >> > downsizing as opposed to *mincresample* that will just use the >>>>> specified >>>>> >> > interpolation method? >>>>> >> >>>>> > >>>>> > Let me make sure I understand this right. Are you saying mincreshape >>>>> does >>>>> > no volume averaging? If you reshape from a dimsize of 512 to 256 for >>>>> > example, then isn't each voxel a 4x4 average of the input? >>>>> > >>>>> > I just verified that it is, but maybe we mean different things by >>>>> volume >>>>> > averaging? >>>>> > >>>>> > Thanks >>>>> > >>>>> > Soren >>>>> > >>>>> > >>>>> > >>>>> >> >>>>> >> 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 >>>>> > >>>>> _______________________________________________ >>>>> MINC-users at bic.mni.mcgill.ca >>>>> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users >>>>> >>>> >>>> >>> >> > From vladimir.fonov at gmail.com Thu Oct 3 12:18:37 2013 From: vladimir.fonov at gmail.com (Vladimir S. FONOV) Date: Thu, 03 Oct 2013 12:18:37 -0400 Subject: [MINC-users] mincreshape segfault and general behavior In-Reply-To: References: Message-ID: <524D98DD.1000003@gmail.com> Hello, take a look: https://github.com/BIC-MNI/minc-tools/issues/2 On 13-10-03 01:35 AM, Soren Christensen wrote: > I did not see that before either. I don't recall segfaults when resizing to > an integer multiple of the original dimension length, but conversely non > integer choices do not always seem to segfault (from memory). > > Soren > > > On Wed, Oct 2, 2013 at 7:52 PM, Alex Zijdenbos wrote: > >> Hi Soren, >> >> OK, you definitely have stumbled across something strange here, as far as >> I am concerned. Taking one of the files from mni_models: >> >> $ mincreshape -dimsize xspace=128 -dimsize yspace=128 -dimsize zspace=128 >> /usr/local/bic/share/mni-models/icbm_avg_152_t1_tal_lin.mnc small.mnc >> Copying >> chunks:................................................................................................................................Segmentation >> fault >> >> I would say that this shouldn't happen. Although the man page does state >> that the dimension resizing only applies to image dimensions, which would >> be xspace and yspace here. Still, a segfault is ugly. >> >> $ mincreshape -clobber -dimsize xspace=128 -dimsize yspace=128 >> /usr/local/bic/share/mni-models/icbm_avg_152_t1_tal_lin.mnc small.mnc >> Copying >> chunks:.....................................................................................................................................................................................Done. >> $ mincinfo /usr/local/bic/share/mni-models/icbm_avg_152_t1_tal_lin.mnc >> small.mnc >> file: /usr/local/bic/share/mni-models/icbm_avg_152_t1_tal_lin.mnc >> image: signed__ short 0 to 4095 >> image dimensions: zspace yspace xspace >> >> dimension name length step start >> -------------- ------ ---- ----- >> zspace 181 1 -72 >> yspace 217 1 -126 >> xspace 181 1 -90 >> >> >> file: small.mnc >> image: signed__ short -32768 to 32767 >> image dimensions: zspace yspace xspace >> >> dimension name length step start >> -------------- ------ ---- ----- >> zspace 181 1 -72 >> yspace 128 2 -143.5 >> xspace 128 2 -125.5 >> >> I thought this shouldn't happen either; in fact, I have always been under >> the impression that mincreshape never changes the step values. But, from >> the man page: >> >> *You want more!?! Okay, okay. Mincreshape makes all of the minc library >> ICV operations available on the command line. For those who like things >> defined, an ICV is an image conversion variable (don't ask me why I called >> it that) which basically lets you tell the data what it's going to look >> like. In other words, it does a bunch of conversions for you. These >> conversions include changing type, range and normalization of the voxel >> values, expanding or contracting images (by voxel duplication or averaging) >> to give a specified image size, and converting vector images to scalar.* >> >> So this is actually (sort of) documented, and I stand corrected - and >> learned something new about mincreshape. >> >> -- A >> >> >> On Wed, Oct 2, 2013 at 10:04 PM, Soren Christensen wrote: >> >>> Thanks again for comments, >>> >>>> - I am not sure why you would simulate noise for this example, that just >>>> seems to make things harder to see >>>> >>> Sure - I just wanted some quick values for numerical comparison. I added >>> the circle to see how the edges were affected. >>> >>> >>>> - the mincreshape call that you used simply crops the image, from >>>> 512x512x2 to 128x128x1, it wouldn't change anything to the actual >>>> (remaining) voxel values at all. >>>> >>> Mind you i am not using -dimrange here which I could have used for a crop. >>> To me a crop preserves the steps. That's not the case here, the steps >>> behave as you'd expect for volume averaging (and I believe inconsistent >>> with a crop): >>> s at s-IdeaCentre-K450:/data2/matlabwork/simcode$ mi test.mnc >>> test_reshaped.mnc >>> file: test.mnc >>> image: signed__ float 0 to 1 >>> image dimensions: time zspace yspace xspace >>> dimension name length step start >>> -------------- ------ ---- ----- >>> time 1 unknown unknown >>> zspace 2 1 0 >>> yspace 512 -1 0 >>> xspace 512 -1 0 >>> >>> file: test_reshaped.mnc >>> image: signed__ float 0 to 1 >>> image dimensions: time zspace yspace xspace >>> dimension name length step start >>> -------------- ------ ---- ----- >>> time 1 1 0 >>> zspace 1 2 0.5 >>> yspace 128 -4 -1.5 >>> xspace 128 -4 -1.5 >>> >>> >>> >>>> mincresample -like test.mnc test_reshaped.mnc test_new.mnc >>>> >>>> >>> and look at the difference between test.mnc and test_new.mnc, you should >>>> see that it has zero difference in the 128x128x1 region that you cropped. >>>> >>> I believe it is evident from the dims and sizes that it is not a crop >>> here. If I follow your suggestion I get an empty image out (max=0), I >>> believe this is because the source voxelcenter is not exactly 0.5 voxel >>> from the target grid. >>> >>> It's definitely not a crop. If it was, the circle you see (from slice 0) >>> would come out clean. It is not. It's mixed with noise (strongly assumed >>> from slice 1). >>> I would think a crop would require starts and lengths too - not just >>> lengths. >>> >>> >>> >>>> >>>> - it is not immediately clear to me why your matlab code/diff seems too >>>> agree with the volume averaging idea, but I'm sure there is a logical >>>> explanation for it >>>> >>>> >>> I still don't see anything to suggest it is not volume averaging. It's >>> definitely not a crop - I have used it extensively recently and I'd see >>> about a quarter of my images missing. If it was a nearest neighbor >>> re-sampling I would not see edge blurring. >>> >>> >>> I had a look at the code but it is beyond me. >>> I think they core of it is here: >>> >>> if (really_copy_the_data) { >>> >>> /* Read in the data */ >>> (void) miicv_get(reshape_info->icvid, input_start, input_count, >>> chunk_data); >>> >>> /* Write it out */ >>> (void) ncvarputg(reshape_info->outmincid, reshape_info->outimgid, >>> output_start, output_count, NULL, >>> output_imapncvarput, >>> output_origin); >>> >>> } >>> >>> I have trouble understanding from the ncvarputg call how this would >>> iterate over inputs contained in the output voxel (assuming it does volume >>> average), but maybe someone here can help. >>> >>> Thanks >>> Soren >>> >>> >>> -- A >>>> >>>> >>>> On Wed, Oct 2, 2013 at 7:21 PM, Soren Christensen wrote: >>>> >>>>> Thanks for the feedback Alex, >>>>> Well I guess a peek at the code is coming closer.. >>>>> I ran a little test making a 512*512*2 noise image (std 1, mena 0 ) >>>>> with a circle in the middle (to better see edge blurring). >>>>> (figure below - also sent to your email to make sure you see the image) >>>>> >>>>> 1) Volume average in 4x4x2 blocks in Matlab >>>>> 2) mincreshape to 128x128x1 >>>>> >>>>> The images differ by maximally 4.9596e-08 which I guess is precision >>>>> issues - since I simulated a double but store a single. >>>>> So unless somehow interpolation in this particular case is supposed to >>>>> yield a similar result (my understanding is that biliniear interpolation >>>>> uses immediate neighbors, but here we are in a 4x4 neighborhood so it >>>>> should not - it may have been similar for a 2x2x2 case). >>>>> So at least this seems to me that it is indeed volume averaging? >>>>> I'll have a look at the code later tonight, but hoping someone could >>>>> enlighten us.. >>>>> >>>>> Soren >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> clear >>>>> >>>>> *%%sim image* >>>>> opimg=rand(512,512,2); >>>>> %save opimg opimg >>>>> %load opimg >>>>> [x,y]=meshgrid(1:512); >>>>> circ=sqrt((x-256).^2+(y-256).^2)<50; >>>>> opimg(128:383,128:383,1)=circ(128:383,128:383); >>>>> >>>>> *%write + reshape* >>>>> mymincwrite(permute(opimg,[1 2 4 3]),'test.mnc',[]) >>>>> system(['mincreshape -clobber -dimsize xspace=128 -dimsize yspace=128 >>>>> -dimsize zspace=1 test.mnc test_reshaped.mnc']) >>>>> >>>>> >>>>> >>>>> >>>>> *%matlab volume averaging* >>>>> recon=zeros(128)*nan; >>>>> for irow=1:128 >>>>> for icol=1:128 >>>>> rindx=(irow-1)*4+1; >>>>> cindx=(icol-1)*4+1; >>>>> zindx=1:2; >>>>> vals=opimg(rindx:(rindx+3),cindx:(cindx+3),zindx); >>>>> recon(irow,icol)=mean( vals(:)); >>>>> end >>>>> end >>>>> >>>>> >>>>> sc(recon) >>>>> m=newmr('test_reshaped.mnc'); >>>>> sc(m-recon) >>>>> tmp=m-recon; >>>>> maxabserr=max(abs(tmp(:))) >>>>> 1st image: Simulated (2 concatted slices) >>>>> 2nd image:Mincresahped >>>>> 3rd: mincreshaped-matlab reshaped - see scale >>>>> >>>>> [image: Inline image 1] >>>>> >>>>> >>>>> >>>>> On Wed, Oct 2, 2013 at 3:56 PM, Alex Zijdenbos wrote: >>>>> >>>>>> Hi Soren, >>>>>> >>>>>> Andrew can throw in his $0.02, but to my knowledge, neither >>>>>> mincreshape nor mincresample does the kind of volume averaging that >>>>>> you describe. MINC considers voxel values as a lattice of >>>>>> dimensionless point samples; the step sizes are distances between >>>>>> those points, and are therefore attributes of the volume, not the >>>>>> voxel. >>>>>> >>>>>> mincresample will interpolate between the point samples when it needs >>>>>> to, but it will not average. In other words, if you would use >>>>>> mincresample to downsample by a factor of 3 in all dimensions >>>>>> (collapse each 3x3x3 cube into a single voxel at the same point >>>>>> location), you are simply tossing out 26 of the 27 voxel values in >>>>>> each 3x3x3 cube - you are not averaging them. I have raised this a few >>>>>> times (very recently even), but even though it may be >>>>>> counter-intuitive to many, it is by Peter's design. In my scripts I >>>>>> usually call mincblur before mincresample when I know I will be >>>>>> downsampling. >>>>>> >>>>>> mincreshape will only massage how the lattice is arranged, allowing >>>>>> you to extract hyperslabs and etc; it does not change the point >>>>>> samples (voxel values), will not interpolate, and would/should >>>>>> certainly not do any averaging. >>>>>> >>>>>> Well that is all my understanding at least :) >>>>>> >>>>>> -- A >>>>>> >>>>>> On Wed, Oct 2, 2013 at 5:21 PM, Soren Christensen >>>>>> wrote: >>>>>>> Hi Andrew, >>>>>>> It's a MINC2 file. >>>>>>> >>>>>>> Sorry I meant mincresample where marked below: >>>>>>>>> 3) Is it correctly understood that mincreshape does volume >>>>>> averaging for >>>>>>>>> downsizing as opposed to *mincresample* that will just use the >>>>>> specified >>>>>>>>> interpolation method? >>>>>>>> >>>>>>> >>>>>>> Let me make sure I understand this right. Are you saying mincreshape >>>>>> does >>>>>>> no volume averaging? If you reshape from a dimsize of 512 to 256 for >>>>>>> example, then isn't each voxel a 4x4 average of the input? >>>>>>> >>>>>>> I just verified that it is, but maybe we mean different things by >>>>>> volume >>>>>>> averaging? -- Best regards, Vladimir S. FONOV ~ vladimir.fonov gmail.com From peter.neelin at gmail.com Thu Oct 3 22:48:54 2013 From: peter.neelin at gmail.com (Peter Neelin) Date: Thu, 3 Oct 2013 22:48:54 -0400 Subject: [MINC-users] mincreshape segfault and general behavior In-Reply-To: <524D98DD.1000003@gmail.com> References: <524D98DD.1000003@gmail.com> Message-ID: Alex, a segfault IS a bug. Also, note the documentation for -dimsize - the image dimensions are extended to include the specified dimension. Normally there are only two image dimensions (ignoring vector images, for the moment), but the parameters of an icv conversion can be modified to include more dimensions. I believe that it was a mistake to add this functionality to mincreshape, particularly since it has been used so little. There are some unit tests for the icv library (I had the right idea, but looking back at code and man pages from 20 years ago is rather embarrassing), however the coverage is very limited (see, for example, minc/testdir/icv_dim.c). The icv library was originally written to facilitate migration of programs like Alan's ROI program from the old "MNI" format (with only power of 2 dimension sizes) to minc. It actually got very little use but left around this ugly library of some fairly complicated code which is really only exposed through some of the mincreshape options. (Okay, that's not quite accurate - the dimension conversion code is used very little, whilst the intensity normalization code is used quite a lot.) Anyway, still a bug. I would strongly recommend using another tool for voxel averaging - there must be one. Andrew or Alex - any suggestions? Peter On Thu, Oct 3, 2013 at 12:18 PM, Vladimir S. FONOV wrote: > > Hello, > > > take a look: > > https://github.com/BIC-MNI/minc-tools/issues/2 > > > > > On 13-10-03 01:35 AM, Soren Christensen wrote: >> >> I did not see that before either. I don't recall segfaults when resizing >> to >> an integer multiple of the original dimension length, but conversely non >> integer choices do not always seem to segfault (from memory). >> >> Soren >> >> >> On Wed, Oct 2, 2013 at 7:52 PM, Alex Zijdenbos >> wrote: >> >>> Hi Soren, >>> >>> OK, you definitely have stumbled across something strange here, as far as >>> I am concerned. Taking one of the files from mni_models: >>> >>> $ mincreshape -dimsize xspace=128 -dimsize yspace=128 -dimsize zspace=128 >>> /usr/local/bic/share/mni-models/icbm_avg_152_t1_tal_lin.mnc small.mnc >>> Copying >>> >>> chunks:................................................................................................................................Segmentation >>> fault >>> >>> I would say that this shouldn't happen. Although the man page does state >>> that the dimension resizing only applies to image dimensions, which would >>> be xspace and yspace here. Still, a segfault is ugly. >>> >>> $ mincreshape -clobber -dimsize xspace=128 -dimsize yspace=128 >>> /usr/local/bic/share/mni-models/icbm_avg_152_t1_tal_lin.mnc small.mnc >>> Copying >>> >>> chunks:.....................................................................................................................................................................................Done. >>> $ mincinfo /usr/local/bic/share/mni-models/icbm_avg_152_t1_tal_lin.mnc >>> small.mnc >>> file: /usr/local/bic/share/mni-models/icbm_avg_152_t1_tal_lin.mnc >>> image: signed__ short 0 to 4095 >>> image dimensions: zspace yspace xspace >>> >>> dimension name length step start >>> -------------- ------ ---- ----- >>> zspace 181 1 -72 >>> yspace 217 1 -126 >>> xspace 181 1 -90 >>> >>> >>> file: small.mnc >>> image: signed__ short -32768 to 32767 >>> image dimensions: zspace yspace xspace >>> >>> dimension name length step start >>> -------------- ------ ---- ----- >>> zspace 181 1 -72 >>> yspace 128 2 -143.5 >>> xspace 128 2 -125.5 >>> >>> I thought this shouldn't happen either; in fact, I have always been under >>> the impression that mincreshape never changes the step values. But, from >>> the man page: >>> >>> *You want more!?! Okay, okay. Mincreshape makes all of the minc library >>> ICV operations available on the command line. For those who like things >>> defined, an ICV is an image conversion variable (don't ask me why I >>> called >>> it that) which basically lets you tell the data what it's going to look >>> like. In other words, it does a bunch of conversions for you. These >>> conversions include changing type, range and normalization of the voxel >>> values, expanding or contracting images (by voxel duplication or >>> averaging) >>> to give a specified image size, and converting vector images to scalar.* >>> >>> So this is actually (sort of) documented, and I stand corrected - and >>> learned something new about mincreshape. >>> >>> -- A >>> >>> >>> On Wed, Oct 2, 2013 at 10:04 PM, Soren Christensen >>> wrote: >>> >>>> Thanks again for comments, >>>> >>>>> - I am not sure why you would simulate noise for this example, that >>>>> just >>>>> seems to make things harder to see >>>>> >>>> Sure - I just wanted some quick values for numerical comparison. I added >>>> the circle to see how the edges were affected. >>>> >>>> >>>>> - the mincreshape call that you used simply crops the image, from >>>>> 512x512x2 to 128x128x1, it wouldn't change anything to the actual >>>>> (remaining) voxel values at all. >>>>> >>>> Mind you i am not using -dimrange here which I could have used for a >>>> crop. >>>> To me a crop preserves the steps. That's not the case here, the steps >>>> behave as you'd expect for volume averaging (and I believe inconsistent >>>> with a crop): >>>> s at s-IdeaCentre-K450:/data2/matlabwork/simcode$ mi test.mnc >>>> test_reshaped.mnc >>>> file: test.mnc >>>> image: signed__ float 0 to 1 >>>> image dimensions: time zspace yspace xspace >>>> dimension name length step start >>>> -------------- ------ ---- ----- >>>> time 1 unknown unknown >>>> zspace 2 1 0 >>>> yspace 512 -1 0 >>>> xspace 512 -1 0 >>>> >>>> file: test_reshaped.mnc >>>> image: signed__ float 0 to 1 >>>> image dimensions: time zspace yspace xspace >>>> dimension name length step start >>>> -------------- ------ ---- ----- >>>> time 1 1 0 >>>> zspace 1 2 0.5 >>>> yspace 128 -4 -1.5 >>>> xspace 128 -4 -1.5 >>>> >>>> >>>> >>>>> mincresample -like test.mnc test_reshaped.mnc test_new.mnc >>>>> >>>>> >>>> and look at the difference between test.mnc and test_new.mnc, you should >>>>> >>>>> see that it has zero difference in the 128x128x1 region that you >>>>> cropped. >>>>> >>>> I believe it is evident from the dims and sizes that it is not a crop >>>> here. If I follow your suggestion I get an empty image out (max=0), I >>>> believe this is because the source voxelcenter is not exactly 0.5 voxel >>>> from the target grid. >>>> >>>> It's definitely not a crop. If it was, the circle you see (from slice 0) >>>> would come out clean. It is not. It's mixed with noise (strongly assumed >>>> from slice 1). >>>> I would think a crop would require starts and lengths too - not just >>>> lengths. >>>> >>>> >>>> >>>>> >>>>> - it is not immediately clear to me why your matlab code/diff seems too >>>>> agree with the volume averaging idea, but I'm sure there is a logical >>>>> explanation for it >>>>> >>>>> >>>> I still don't see anything to suggest it is not volume averaging. It's >>>> definitely not a crop - I have used it extensively recently and I'd see >>>> about a quarter of my images missing. If it was a nearest neighbor >>>> re-sampling I would not see edge blurring. >>>> >>>> >>>> I had a look at the code but it is beyond me. >>>> I think they core of it is here: >>>> >>>> if (really_copy_the_data) { >>>> >>>> /* Read in the data */ >>>> (void) miicv_get(reshape_info->icvid, input_start, input_count, >>>> chunk_data); >>>> >>>> /* Write it out */ >>>> (void) ncvarputg(reshape_info->outmincid, reshape_info->outimgid, >>>> output_start, output_count, NULL, >>>> output_imapncvarput, >>>> output_origin); >>>> >>>> } >>>> >>>> I have trouble understanding from the ncvarputg call how this would >>>> iterate over inputs contained in the output voxel (assuming it does >>>> volume >>>> average), but maybe someone here can help. >>>> >>>> Thanks >>>> Soren >>>> >>>> >>>> -- A >>>>> >>>>> >>>>> >>>>> On Wed, Oct 2, 2013 at 7:21 PM, Soren Christensen >>>>> wrote: >>>>> >>>>>> Thanks for the feedback Alex, >>>>>> Well I guess a peek at the code is coming closer.. >>>>>> I ran a little test making a 512*512*2 noise image (std 1, mena 0 ) >>>>>> with a circle in the middle (to better see edge blurring). >>>>>> (figure below - also sent to your email to make sure you see the >>>>>> image) >>>>>> >>>>>> 1) Volume average in 4x4x2 blocks in Matlab >>>>>> 2) mincreshape to 128x128x1 >>>>>> >>>>>> The images differ by maximally 4.9596e-08 which I guess is precision >>>>>> issues - since I simulated a double but store a single. >>>>>> So unless somehow interpolation in this particular case is supposed to >>>>>> yield a similar result (my understanding is that biliniear >>>>>> interpolation >>>>>> uses immediate neighbors, but here we are in a 4x4 neighborhood so it >>>>>> should not - it may have been similar for a 2x2x2 case). >>>>>> So at least this seems to me that it is indeed volume averaging? >>>>>> I'll have a look at the code later tonight, but hoping someone could >>>>>> enlighten us.. >>>>>> >>>>>> Soren >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> clear >>>>>> >>>>>> *%%sim image* >>>>>> opimg=rand(512,512,2); >>>>>> %save opimg opimg >>>>>> %load opimg >>>>>> [x,y]=meshgrid(1:512); >>>>>> circ=sqrt((x-256).^2+(y-256).^2)<50; >>>>>> opimg(128:383,128:383,1)=circ(128:383,128:383); >>>>>> >>>>>> *%write + reshape* >>>>>> mymincwrite(permute(opimg,[1 2 4 3]),'test.mnc',[]) >>>>>> system(['mincreshape -clobber -dimsize xspace=128 -dimsize yspace=128 >>>>>> -dimsize zspace=1 test.mnc test_reshaped.mnc']) >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> *%matlab volume averaging* >>>>>> recon=zeros(128)*nan; >>>>>> for irow=1:128 >>>>>> for icol=1:128 >>>>>> rindx=(irow-1)*4+1; >>>>>> cindx=(icol-1)*4+1; >>>>>> zindx=1:2; >>>>>> vals=opimg(rindx:(rindx+3),cindx:(cindx+3),zindx); >>>>>> recon(irow,icol)=mean( vals(:)); >>>>>> end >>>>>> end >>>>>> >>>>>> >>>>>> sc(recon) >>>>>> m=newmr('test_reshaped.mnc'); >>>>>> sc(m-recon) >>>>>> tmp=m-recon; >>>>>> maxabserr=max(abs(tmp(:))) >>>>>> 1st image: Simulated (2 concatted slices) >>>>>> 2nd image:Mincresahped >>>>>> 3rd: mincreshaped-matlab reshaped - see scale >>>>>> >>>>>> [image: Inline image 1] >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Oct 2, 2013 at 3:56 PM, Alex Zijdenbos >>>>>> wrote: >>>>>> >>>>>>> Hi Soren, >>>>>>> >>>>>>> Andrew can throw in his $0.02, but to my knowledge, neither >>>>>>> mincreshape nor mincresample does the kind of volume averaging that >>>>>>> you describe. MINC considers voxel values as a lattice of >>>>>>> dimensionless point samples; the step sizes are distances between >>>>>>> those points, and are therefore attributes of the volume, not the >>>>>>> voxel. >>>>>>> >>>>>>> mincresample will interpolate between the point samples when it needs >>>>>>> to, but it will not average. In other words, if you would use >>>>>>> mincresample to downsample by a factor of 3 in all dimensions >>>>>>> (collapse each 3x3x3 cube into a single voxel at the same point >>>>>>> location), you are simply tossing out 26 of the 27 voxel values in >>>>>>> each 3x3x3 cube - you are not averaging them. I have raised this a >>>>>>> few >>>>>>> times (very recently even), but even though it may be >>>>>>> counter-intuitive to many, it is by Peter's design. In my scripts I >>>>>>> usually call mincblur before mincresample when I know I will be >>>>>>> downsampling. >>>>>>> >>>>>>> mincreshape will only massage how the lattice is arranged, allowing >>>>>>> you to extract hyperslabs and etc; it does not change the point >>>>>>> samples (voxel values), will not interpolate, and would/should >>>>>>> certainly not do any averaging. >>>>>>> >>>>>>> Well that is all my understanding at least :) >>>>>>> >>>>>>> -- A >>>>>>> >>>>>>> On Wed, Oct 2, 2013 at 5:21 PM, Soren Christensen >>>>>>> wrote: >>>>>>>> >>>>>>>> Hi Andrew, >>>>>>>> It's a MINC2 file. >>>>>>>> >>>>>>>> Sorry I meant mincresample where marked below: >>>>>>>>>> >>>>>>>>>> 3) Is it correctly understood that mincreshape does volume >>>>>>> >>>>>>> averaging for >>>>>>>>>> >>>>>>>>>> downsizing as opposed to *mincresample* that will just use the >>>>>>> >>>>>>> specified >>>>>>>>>> >>>>>>>>>> interpolation method? >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> Let me make sure I understand this right. Are you saying mincreshape >>>>>>> >>>>>>> does >>>>>>>> >>>>>>>> no volume averaging? If you reshape from a dimsize of 512 to 256 for >>>>>>>> example, then isn't each voxel a 4x4 average of the input? >>>>>>>> >>>>>>>> I just verified that it is, but maybe we mean different things by >>>>>>> >>>>>>> volume >>>>>>>> >>>>>>>> averaging? > > > > -- > 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 -- Peter Neelin (peter.neelin at gmail.com) From eskild at gmail.com Fri Oct 4 03:51:14 2013 From: eskild at gmail.com (Simon Eskildsen) Date: Fri, 4 Oct 2013 09:51:14 +0200 Subject: [MINC-users] mincreshape segfault and general behavior In-Reply-To: References: <524D98DD.1000003@gmail.com> Message-ID: For simple down sampling with voxel averaging, I'm using Vlad's tool minc_downsample, which is part of EZminc. https://github.com/BIC-MNI/EZminc/blob/master/tools/minc_downsample.cpp This is included in the minc-toolkit metaproject. Simon On Fri, Oct 4, 2013 at 4:48 AM, Peter Neelin wrote: > Alex, a segfault IS a bug. Also, note the documentation for -dimsize - > the image dimensions are extended to include the specified dimension. > Normally there are only two image dimensions (ignoring vector images, > for the moment), but the parameters of an icv conversion can be > modified to include more dimensions. > > I believe that it was a mistake to add this functionality to > mincreshape, particularly since it has been used so little. There are > some unit tests for the icv library (I had the right idea, but looking > back at code and man pages from 20 years ago is rather embarrassing), > however the coverage is very limited (see, for example, > minc/testdir/icv_dim.c). The icv library was originally written to > facilitate migration of programs like Alan's ROI program from the old > "MNI" format (with only power of 2 dimension sizes) to minc. It > actually got very little use but left around this ugly library of some > fairly complicated code which is really only exposed through some of > the mincreshape options. (Okay, that's not quite accurate - the > dimension conversion code is used very little, whilst the intensity > normalization code is used quite a lot.) > > Anyway, still a bug. I would strongly recommend using another tool for > voxel averaging - there must be one. Andrew or Alex - any suggestions? > > Peter > > On Thu, Oct 3, 2013 at 12:18 PM, Vladimir S. FONOV > wrote: > > > > Hello, > > > > > > take a look: > > > > https://github.com/BIC-MNI/minc-tools/issues/2 > > > > > > > > > > On 13-10-03 01:35 AM, Soren Christensen wrote: > >> > >> I did not see that before either. I don't recall segfaults when resizing > >> to > >> an integer multiple of the original dimension length, but conversely non > >> integer choices do not always seem to segfault (from memory). > >> > >> Soren > >> > >> > >> On Wed, Oct 2, 2013 at 7:52 PM, Alex Zijdenbos > >> wrote: > >> > >>> Hi Soren, > >>> > >>> OK, you definitely have stumbled across something strange here, as far > as > >>> I am concerned. Taking one of the files from mni_models: > >>> > >>> $ mincreshape -dimsize xspace=128 -dimsize yspace=128 -dimsize > zspace=128 > >>> /usr/local/bic/share/mni-models/icbm_avg_152_t1_tal_lin.mnc small.mnc > >>> Copying > >>> > >>> > chunks:................................................................................................................................Segmentation > >>> fault > >>> > >>> I would say that this shouldn't happen. Although the man page does > state > >>> that the dimension resizing only applies to image dimensions, which > would > >>> be xspace and yspace here. Still, a segfault is ugly. > >>> > >>> $ mincreshape -clobber -dimsize xspace=128 -dimsize yspace=128 > >>> /usr/local/bic/share/mni-models/icbm_avg_152_t1_tal_lin.mnc small.mnc > >>> Copying > >>> > >>> > chunks:.....................................................................................................................................................................................Done. > >>> $ mincinfo /usr/local/bic/share/mni-models/icbm_avg_152_t1_tal_lin.mnc > >>> small.mnc > >>> file: /usr/local/bic/share/mni-models/icbm_avg_152_t1_tal_lin.mnc > >>> image: signed__ short 0 to 4095 > >>> image dimensions: zspace yspace xspace > >>> > >>> dimension name length step start > >>> -------------- ------ ---- ----- > >>> zspace 181 1 -72 > >>> yspace 217 1 -126 > >>> xspace 181 1 -90 > >>> > >>> > >>> file: small.mnc > >>> image: signed__ short -32768 to 32767 > >>> image dimensions: zspace yspace xspace > >>> > >>> dimension name length step start > >>> -------------- ------ ---- ----- > >>> zspace 181 1 -72 > >>> yspace 128 2 -143.5 > >>> xspace 128 2 -125.5 > >>> > >>> I thought this shouldn't happen either; in fact, I have always been > under > >>> the impression that mincreshape never changes the step values. But, > from > >>> the man page: > >>> > >>> *You want more!?! Okay, okay. Mincreshape makes all of the minc library > >>> ICV operations available on the command line. For those who like things > >>> defined, an ICV is an image conversion variable (don't ask me why I > >>> called > >>> it that) which basically lets you tell the data what it's going to > look > >>> like. In other words, it does a bunch of conversions for you. > These > >>> conversions include changing type, range and normalization of the voxel > >>> values, expanding or contracting images (by voxel duplication or > >>> averaging) > >>> to give a specified image size, and converting vector images to > scalar.* > >>> > >>> So this is actually (sort of) documented, and I stand corrected - and > >>> learned something new about mincreshape. > >>> > >>> -- A > >>> > >>> > >>> On Wed, Oct 2, 2013 at 10:04 PM, Soren Christensen > >>> wrote: > >>> > >>>> Thanks again for comments, > >>>> > >>>>> - I am not sure why you would simulate noise for this example, that > >>>>> just > >>>>> seems to make things harder to see > >>>>> > >>>> Sure - I just wanted some quick values for numerical comparison. I > added > >>>> the circle to see how the edges were affected. > >>>> > >>>> > >>>>> - the mincreshape call that you used simply crops the image, from > >>>>> 512x512x2 to 128x128x1, it wouldn't change anything to the actual > >>>>> (remaining) voxel values at all. > >>>>> > >>>> Mind you i am not using -dimrange here which I could have used for a > >>>> crop. > >>>> To me a crop preserves the steps. That's not the case here, the steps > >>>> behave as you'd expect for volume averaging (and I believe > inconsistent > >>>> with a crop): > >>>> s at s-IdeaCentre-K450:/data2/matlabwork/simcode$ mi test.mnc > >>>> test_reshaped.mnc > >>>> file: test.mnc > >>>> image: signed__ float 0 to 1 > >>>> image dimensions: time zspace yspace xspace > >>>> dimension name length step start > >>>> -------------- ------ ---- ----- > >>>> time 1 unknown unknown > >>>> zspace 2 1 0 > >>>> yspace 512 -1 0 > >>>> xspace 512 -1 0 > >>>> > >>>> file: test_reshaped.mnc > >>>> image: signed__ float 0 to 1 > >>>> image dimensions: time zspace yspace xspace > >>>> dimension name length step start > >>>> -------------- ------ ---- ----- > >>>> time 1 1 0 > >>>> zspace 1 2 0.5 > >>>> yspace 128 -4 -1.5 > >>>> xspace 128 -4 -1.5 > >>>> > >>>> > >>>> > >>>>> mincresample -like test.mnc test_reshaped.mnc test_new.mnc > >>>>> > >>>>> > >>>> and look at the difference between test.mnc and test_new.mnc, you > should > >>>>> > >>>>> see that it has zero difference in the 128x128x1 region that you > >>>>> cropped. > >>>>> > >>>> I believe it is evident from the dims and sizes that it is not a crop > >>>> here. If I follow your suggestion I get an empty image out (max=0), I > >>>> believe this is because the source voxelcenter is not exactly 0.5 > voxel > >>>> from the target grid. > >>>> > >>>> It's definitely not a crop. If it was, the circle you see (from slice > 0) > >>>> would come out clean. It is not. It's mixed with noise (strongly > assumed > >>>> from slice 1). > >>>> I would think a crop would require starts and lengths too - not just > >>>> lengths. > >>>> > >>>> > >>>> > >>>>> > >>>>> - it is not immediately clear to me why your matlab code/diff seems > too > >>>>> agree with the volume averaging idea, but I'm sure there is a logical > >>>>> explanation for it > >>>>> > >>>>> > >>>> I still don't see anything to suggest it is not volume averaging. It's > >>>> definitely not a crop - I have used it extensively recently and I'd > see > >>>> about a quarter of my images missing. If it was a nearest neighbor > >>>> re-sampling I would not see edge blurring. > >>>> > >>>> > >>>> I had a look at the code but it is beyond me. > >>>> I think they core of it is here: > >>>> > >>>> if (really_copy_the_data) { > >>>> > >>>> /* Read in the data */ > >>>> (void) miicv_get(reshape_info->icvid, input_start, input_count, > >>>> chunk_data); > >>>> > >>>> /* Write it out */ > >>>> (void) ncvarputg(reshape_info->outmincid, > reshape_info->outimgid, > >>>> output_start, output_count, NULL, > >>>> output_imapncvarput, > >>>> output_origin); > >>>> > >>>> } > >>>> > >>>> I have trouble understanding from the ncvarputg call how this would > >>>> iterate over inputs contained in the output voxel (assuming it does > >>>> volume > >>>> average), but maybe someone here can help. > >>>> > >>>> Thanks > >>>> Soren > >>>> > >>>> > >>>> -- A > >>>>> > >>>>> > >>>>> > >>>>> On Wed, Oct 2, 2013 at 7:21 PM, Soren Christensen > >>>>> wrote: > >>>>> > >>>>>> Thanks for the feedback Alex, > >>>>>> Well I guess a peek at the code is coming closer.. > >>>>>> I ran a little test making a 512*512*2 noise image (std 1, mena 0 ) > >>>>>> with a circle in the middle (to better see edge blurring). > >>>>>> (figure below - also sent to your email to make sure you see the > >>>>>> image) > >>>>>> > >>>>>> 1) Volume average in 4x4x2 blocks in Matlab > >>>>>> 2) mincreshape to 128x128x1 > >>>>>> > >>>>>> The images differ by maximally 4.9596e-08 which I guess is precision > >>>>>> issues - since I simulated a double but store a single. > >>>>>> So unless somehow interpolation in this particular case is supposed > to > >>>>>> yield a similar result (my understanding is that biliniear > >>>>>> interpolation > >>>>>> uses immediate neighbors, but here we are in a 4x4 neighborhood so > it > >>>>>> should not - it may have been similar for a 2x2x2 case). > >>>>>> So at least this seems to me that it is indeed volume averaging? > >>>>>> I'll have a look at the code later tonight, but hoping someone could > >>>>>> enlighten us.. > >>>>>> > >>>>>> Soren > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> clear > >>>>>> > >>>>>> *%%sim image* > >>>>>> opimg=rand(512,512,2); > >>>>>> %save opimg opimg > >>>>>> %load opimg > >>>>>> [x,y]=meshgrid(1:512); > >>>>>> circ=sqrt((x-256).^2+(y-256).^2)<50; > >>>>>> opimg(128:383,128:383,1)=circ(128:383,128:383); > >>>>>> > >>>>>> *%write + reshape* > >>>>>> mymincwrite(permute(opimg,[1 2 4 3]),'test.mnc',[]) > >>>>>> system(['mincreshape -clobber -dimsize xspace=128 -dimsize > yspace=128 > >>>>>> -dimsize zspace=1 test.mnc test_reshaped.mnc']) > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> *%matlab volume averaging* > >>>>>> recon=zeros(128)*nan; > >>>>>> for irow=1:128 > >>>>>> for icol=1:128 > >>>>>> rindx=(irow-1)*4+1; > >>>>>> cindx=(icol-1)*4+1; > >>>>>> zindx=1:2; > >>>>>> vals=opimg(rindx:(rindx+3),cindx:(cindx+3),zindx); > >>>>>> recon(irow,icol)=mean( vals(:)); > >>>>>> end > >>>>>> end > >>>>>> > >>>>>> > >>>>>> sc(recon) > >>>>>> m=newmr('test_reshaped.mnc'); > >>>>>> sc(m-recon) > >>>>>> tmp=m-recon; > >>>>>> maxabserr=max(abs(tmp(:))) > >>>>>> 1st image: Simulated (2 concatted slices) > >>>>>> 2nd image:Mincresahped > >>>>>> 3rd: mincreshaped-matlab reshaped - see scale > >>>>>> > >>>>>> [image: Inline image 1] > >>>>>> > >>>>>> > >>>>>> > >>>>>> On Wed, Oct 2, 2013 at 3:56 PM, Alex Zijdenbos > >>>>>> wrote: > >>>>>> > >>>>>>> Hi Soren, > >>>>>>> > >>>>>>> Andrew can throw in his $0.02, but to my knowledge, neither > >>>>>>> mincreshape nor mincresample does the kind of volume averaging that > >>>>>>> you describe. MINC considers voxel values as a lattice of > >>>>>>> dimensionless point samples; the step sizes are distances between > >>>>>>> those points, and are therefore attributes of the volume, not the > >>>>>>> voxel. > >>>>>>> > >>>>>>> mincresample will interpolate between the point samples when it > needs > >>>>>>> to, but it will not average. In other words, if you would use > >>>>>>> mincresample to downsample by a factor of 3 in all dimensions > >>>>>>> (collapse each 3x3x3 cube into a single voxel at the same point > >>>>>>> location), you are simply tossing out 26 of the 27 voxel values in > >>>>>>> each 3x3x3 cube - you are not averaging them. I have raised this a > >>>>>>> few > >>>>>>> times (very recently even), but even though it may be > >>>>>>> counter-intuitive to many, it is by Peter's design. In my scripts I > >>>>>>> usually call mincblur before mincresample when I know I will be > >>>>>>> downsampling. > >>>>>>> > >>>>>>> mincreshape will only massage how the lattice is arranged, allowing > >>>>>>> you to extract hyperslabs and etc; it does not change the point > >>>>>>> samples (voxel values), will not interpolate, and would/should > >>>>>>> certainly not do any averaging. > >>>>>>> > >>>>>>> Well that is all my understanding at least :) > >>>>>>> > >>>>>>> -- A > >>>>>>> > >>>>>>> On Wed, Oct 2, 2013 at 5:21 PM, Soren Christensen < > sorench at gmail.com> > >>>>>>> wrote: > >>>>>>>> > >>>>>>>> Hi Andrew, > >>>>>>>> It's a MINC2 file. > >>>>>>>> > >>>>>>>> Sorry I meant mincresample where marked below: > >>>>>>>>>> > >>>>>>>>>> 3) Is it correctly understood that mincreshape does volume > >>>>>>> > >>>>>>> averaging for > >>>>>>>>>> > >>>>>>>>>> downsizing as opposed to *mincresample* that will just use the > >>>>>>> > >>>>>>> specified > >>>>>>>>>> > >>>>>>>>>> interpolation method? > >>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>>> Let me make sure I understand this right. Are you saying > mincreshape > >>>>>>> > >>>>>>> does > >>>>>>>> > >>>>>>>> no volume averaging? If you reshape from a dimsize of 512 to 256 > for > >>>>>>>> example, then isn't each voxel a 4x4 average of the input? > >>>>>>>> > >>>>>>>> I just verified that it is, but maybe we mean different things > by > >>>>>>> > >>>>>>> volume > >>>>>>>> > >>>>>>>> averaging? > > > > > > > > -- > > 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 > > > > -- > Peter Neelin > (peter.neelin at gmail.com) > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > From a.janke at gmail.com Fri Oct 4 06:35:50 2013 From: a.janke at gmail.com (Andrew Janke) Date: Fri, 4 Oct 2013 20:35:50 +1000 Subject: [MINC-users] mincreshape segfault and general behavior In-Reply-To: References: Message-ID: On 3 October 2013 07:21, Soren Christensen wrote: > It's a MINC2 file. Well, scratch that idea then.... > Sorry I meant mincresample where marked below: >> > 3) Is it correctly understood that mincreshape does volume averaging for >> > downsizing as opposed to *mincresample* that will just use the specified >> > interpolation method? > > Let me make sure I understand this right. Are you saying mincreshape does > no volume averaging? If you reshape from a dimsize of 512 to 256 for > example, then isn't each voxel a 4x4 average of the input? Correct. mincreshape does no volume averaging/blurring/interpolating that I know of. In this case mincresample is what you want. This sort of doubling/halving of step sizes is voered by autocrop with the -isostep style options. Because I like making my own toys I have a few incarnations of this here: http://packages.bic.mni.mcgill.ca/scripts/voliso I see Vlad has also responded with his own tool to do this. a From a.janke at gmail.com Fri Oct 4 06:39:44 2013 From: a.janke at gmail.com (Andrew Janke) Date: Fri, 4 Oct 2013 20:39:44 +1000 Subject: [MINC-users] mincreshape segfault and general behavior In-Reply-To: References: Message-ID: On 3 October 2013 08:56, Alex Zijdenbos wrote: > mincresample will interpolate between the point samples when it needs > to, but it will not average. In other words, if you would use > mincresample to downsample by a factor of 3 in all dimensions > (collapse each 3x3x3 cube into a single voxel at the same point > location), you are simply tossing out 26 of the 27 voxel values in > each 3x3x3 cube - you are not averaging them. I have raised this a few > times (very recently even), but even though it may be > counter-intuitive to many, it is by Peter's design. In my scripts I > usually call mincblur before mincresample when I know I will be > downsampling. This is only if you are using mincresample in old-school trilinear/tricubic/nearest mode. I, along with others asked Bert a long while back to add some better options for this and -sinc option was the result. Note also the -width, -hanning and -hamming options. If you want to go whole hog first principles regridding, take a look at volregrid. https://github.com/andrewjanke/volregrid This was originally written for k-space spiral trajectory regridding but since then has been abused for all sorts of other reasons. a From zijdenbos at gmail.com Fri Oct 4 15:44:25 2013 From: zijdenbos at gmail.com (Alex Zijdenbos) Date: Fri, 4 Oct 2013 15:44:25 -0400 Subject: [MINC-users] mincreshape segfault and general behavior In-Reply-To: References: Message-ID: On Fri, Oct 4, 2013 at 6:35 AM, Andrew Janke wrote: >> Let me make sure I understand this right. Are you saying mincreshape does >> no volume averaging? If you reshape from a dimsize of 512 to 256 for >> example, then isn't each voxel a 4x4 average of the input? > > Correct. mincreshape does no volume averaging/blurring/interpolating > that I know of. So apparently mincreshape does do volume averaging when you use the -dimsize option, as Soren noted and Peter confirmed; so it seems that in this sense mincreshape -dimsize does the same thing as Vlad's EZminc minc_downsample. > In this case mincresample is what you want. This sort > of doubling/halving of step sizes is voered by autocrop with the > -isostep style options. Because I like making my own toys I have a few > incarnations of this here: > > http://packages.bic.mni.mcgill.ca/scripts/voliso > > I see Vlad has also responded with his own tool to do this. Not quite - none of these do any kind of volume averaging when you downsample. I did some tests using a simple binary sphere, generated with 1mm isotropic voxel dims and subsequently downsampling that to 3mm voxel dims in a few ways: https://www.dropbox.com/s/env1l9iorejex92/downsample.jpg The 4 images are: 1) orginal 1mm 2) resampled to 3mm using mincresample -sinc 3) reshaped to 3mm using mincreshape -dimsize 4) mincblur -fwhm 3, followed by mincresamle -nearest Note that for 2), it makes absolutely no difference what interpolant you select for mincresample; the result is always identical to this image (which is probably not what most people would want/expect). Same for autocrop/voliso, which also don't add averaging as they simply calls mincresample. I usually use method 4); and until yesterday wasn't aware that 3) works. The difference between them is really the choice of the blurring kernel; in 4) a Gaussian, in 3) it's just a rect. -- A From sorench at gmail.com Fri Oct 4 22:21:03 2013 From: sorench at gmail.com (Soren Christensen) Date: Fri, 4 Oct 2013 19:21:03 -0700 Subject: [MINC-users] mincreshape segfault and general behavior In-Reply-To: References: Message-ID: Andrew, as Alex says mincreshape does do volume averaging - lucky for me it works for my purposes (at least some basic numerical tests support that). Thanks for pointing me to the width option of mincresample, but I am not sure it can do a relatively simple downsample-volume-averaging, it seems to relate to sinc-windowing. Does volregrid volume average when downsampling? If so, then maybe that is a suitable replacement for mincreshape when it comes to downsampling? Soren On Fri, Oct 4, 2013 at 12:44 PM, Alex Zijdenbos wrote: > On Fri, Oct 4, 2013 at 6:35 AM, Andrew Janke wrote: > >> Let me make sure I understand this right. Are you saying mincreshape > does > >> no volume averaging? If you reshape from a dimsize of 512 to 256 for > >> example, then isn't each voxel a 4x4 average of the input? > > > > Correct. mincreshape does no volume averaging/blurring/interpolating > > that I know of. > > So apparently mincreshape does do volume averaging when you use the > -dimsize option, as Soren noted and Peter confirmed; so it seems that > in this sense mincreshape -dimsize does the same thing as Vlad's > EZminc minc_downsample. > > > In this case mincresample is what you want. This sort > > of doubling/halving of step sizes is voered by autocrop with the > > -isostep style options. Because I like making my own toys I have a few > > incarnations of this here: > > > > http://packages.bic.mni.mcgill.ca/scripts/voliso > > > > I see Vlad has also responded with his own tool to do this. > > Not quite - none of these do any kind of volume averaging when you > downsample. I did some tests using a simple binary sphere, generated > with 1mm isotropic voxel dims and subsequently downsampling that to > 3mm voxel dims in a few ways: > > https://www.dropbox.com/s/env1l9iorejex92/downsample.jpg > > The 4 images are: > > 1) orginal 1mm > 2) resampled to 3mm using mincresample -sinc > 3) reshaped to 3mm using mincreshape -dimsize > 4) mincblur -fwhm 3, followed by mincresamle -nearest > > Note that for 2), it makes absolutely no difference what interpolant > you select for mincresample; the result is always identical to this > image (which is probably not what most people would want/expect). Same > for autocrop/voliso, which also don't add averaging as they simply > calls mincresample. > > I usually use method 4); and until yesterday wasn't aware that 3) > works. The difference between them is really the choice of the > blurring kernel; in 4) a Gaussian, in 3) it's just a rect. > > -- A > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > From a.janke at gmail.com Mon Oct 7 16:02:43 2013 From: a.janke at gmail.com (Andrew Janke) Date: Tue, 8 Oct 2013 06:02:43 +1000 Subject: [MINC-users] mincreshape segfault and general behavior In-Reply-To: References: Message-ID: > Does volregrid volume average when downsampling? If so, then maybe that is > a suitable replacement for mincreshape when it comes to downsampling? Indeed it does. You can choose between linear, gaussian or a kaiser-bessel function and define a regrid radius/sigma. https://github.com/andrewjanke/volregrid Note that it was primarily written for defining a new sampling but does have a -like option. So if you want to halve the dimensions you might want to write a quick wrapper for it in perl based upon voliso or some other script. a From nikhil.bhagwat at mail.utoronto.ca Mon Oct 7 16:19:13 2013 From: nikhil.bhagwat at mail.utoronto.ca (Nikhil Bhagwat) Date: Mon, 7 Oct 2013 20:19:13 +0000 Subject: [MINC-users] STAPLE Implementation Message-ID: <368947C5C19FEE4BA6E91CF30F51C692835F7E@BY2PRD0310MB390.namprd03.prod.outlook.com> Hello, I am new to MINC, and I am trying to figure out if anyone has implemented STAPLE algorithm using MINC data. Original implementation can be found on the following link, but it seems to have issues with MINC files. http://crl.med.harvard.edu/software/STAPLE/ Thanks, Nikhil From a.janke at gmail.com Mon Oct 7 23:54:38 2013 From: a.janke at gmail.com (Andrew Janke) Date: Tue, 8 Oct 2013 13:54:38 +1000 Subject: [MINC-users] STAPLE Implementation In-Reply-To: <368947C5C19FEE4BA6E91CF30F51C692835F7E@BY2PRD0310MB390.namprd03.prod.outlook.com> References: <368947C5C19FEE4BA6E91CF30F51C692835F7E@BY2PRD0310MB390.namprd03.prod.outlook.com> Message-ID: Hi Nikhil, Not that I know of. Probably best to investigate mnc2nii to convert your data to Nifti format. a On 8 October 2013 06:19, Nikhil Bhagwat wrote: > Hello, > > I am new to MINC, and I am trying to figure out if anyone has implemented STAPLE algorithm using MINC data. Original implementation can be found on the following link, but it seems to have issues with MINC files. > > http://crl.med.harvard.edu/software/STAPLE/ > > Thanks, > Nikhil > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users From francois.hebert007 at gmail.com Wed Oct 16 15:35:30 2013 From: francois.hebert007 at gmail.com (francois hebert) Date: Wed, 16 Oct 2013 15:35:30 -0400 Subject: [MINC-users] minccmp bug Message-ID: Hi All, In the help of minccmp it is explained that minccmp will calculate simple statistical measures between two minc files or more by comparing all subsequent files to the first. but when I try to compare one file to several minccmp just return the comparison of the 2 first files. Here the version of minccmp and minc package I'm using: program: 2.1.00 libminc: 2.1.00 netcdf : 3.6.1 of Feb 18 2011 13:31:33 $ HDF5 : 1.8.5 Francois Hebert From a.janke at gmail.com Wed Oct 16 22:45:13 2013 From: a.janke at gmail.com (Andrew Janke) Date: Thu, 17 Oct 2013 12:45:13 +1000 Subject: [MINC-users] minccmp bug In-Reply-To: References: Message-ID: Hi Francois, Seems that I am a goose, I go to all the trouble in the code to calculate the comparisons and then only print the first one! see: https://github.com/BIC-MNI/minc-tools/blob/master/progs/minccmp/minccmp.c#L275 If you are a coder this is a simple fix, just add a loop at the output phase. If not I'll add this into the next release. Thanks for the bug report. a On 17 October 2013 05:35, francois hebert wrote: > Hi All, > > In the help of minccmp it is explained that minccmp will calculate simple > statistical measures between two minc files or more by comparing all > subsequent files to the first. but when I try to compare one file to > several minccmp just return the comparison of the 2 first files. > > Here the version of minccmp and minc package I'm using: > program: 2.1.00 > libminc: 2.1.00 > netcdf : 3.6.1 of Feb 18 2011 13:31:33 $ > HDF5 : 1.8.5 > > > Francois Hebert > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users From francois.hebert007 at gmail.com Thu Oct 17 08:55:56 2013 From: francois.hebert007 at gmail.com (francois hebert) Date: Thu, 17 Oct 2013 08:55:56 -0400 Subject: [MINC-users] minccmp bug In-Reply-To: References: Message-ID: Hi Andrew, Thanks I already fixed the bug on my side. Francois 2013/10/16 Andrew Janke > Hi Francois, > > Seems that I am a goose, I go to all the trouble in the code to > calculate the comparisons and then only print the first one! > > see: > > > https://github.com/BIC-MNI/minc-tools/blob/master/progs/minccmp/minccmp.c#L275 > > If you are a coder this is a simple fix, just add a loop at the output > phase. If not I'll add this into the next release. Thanks for the bug > report. > > a > > On 17 October 2013 05:35, francois hebert > wrote: > > Hi All, > > > > In the help of minccmp it is explained that minccmp will calculate > simple > > statistical measures between two minc files or more by comparing all > > subsequent files to the first. but when I try to compare one file to > > several minccmp just return the comparison of the 2 first files. > > > > Here the version of minccmp and minc package I'm using: > > program: 2.1.00 > > libminc: 2.1.00 > > netcdf : 3.6.1 of Feb 18 2011 13:31:33 $ > > HDF5 : 1.8.5 > > > > > > Francois Hebert > > _______________________________________________ > > 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 >