[MINC-users] mincreshape segfault and general behavior
Soren Christensen
sorench at gmail.com
Thu Oct 3 01:35:20 EDT 2013
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 <zijdenbos at gmail.com> 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 <sorench at gmail.com>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 <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