[MINC-users] mincreshape segfault and general behavior
Simon Eskildsen
eskild at gmail.com
Fri Oct 4 03:51:14 EDT 2013
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 <peter.neelin at gmail.com> 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
> <vladimir.fonov at gmail.com> 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 <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
> > _______________________________________________
> > 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
>
More information about the MINC-users
mailing list