[MINC-users] mincreshape segfault and general behavior
Vladimir S. FONOV
vladimir.fonov at gmail.com
Thu Oct 3 12:18:37 EDT 2013
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 <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?
--
Best regards,
Vladimir S. FONOV ~ vladimir.fonov <at> gmail.com
More information about the MINC-users
mailing list