[MINC-users] mincreshape segfault and general behavior
Soren Christensen
sorench at gmail.com
Wed Oct 2 22:04:25 EDT 2013
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 <sorench at gmail.com>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 <zijdenbos at gmail.com>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?
>>> >
>>> > 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
>>>
>>
>>
>
More information about the MINC-users
mailing list