[MINC-users] mincresample along a dimension with *-width variables

Andrew Wood andrew at biospective.com
Fri Feb 7 08:43:18 EST 2014


This file came from some some buggy code which artificially inserted
it (was supposed to insert on the time dimension). I thought it was
something
worth looking into as a generic issue, but perhaps the volume should be
considered malformed, and the issue forgotten?

- Andrew


On Thu, Feb 6, 2014 at 6:23 PM, Andrew Janke <a.janke at gmail.com> wrote:

> Hi all,
>
> As others have commented, the width parameters are typically for data
> with a time dimension, but there are use cases for irregular spacing
> in an image dimension. I have used it for microscopy data in which we
> dynamically change a vibratome slice thickness from 20um -> 80um
> depending if we are in an "interesting" part of the tissue or not.
>
> Peter, Bert and I had a long discussion about the use case that Alex
> mentioned of capturing slice thickness and gap. This used to be common
> in MRI acquisition to avoid slice cross talk but has (thankfully)
> faded from use with interleaved sequences. I argued strongly that we
> shouldn't support this type of acquisition as it would introduce too
> many special cases, what for example do you do when you resample? you
> can no longer capture the gaps. Peter as I recall agreed so Bert
> didin't get to vote!
>
> History out of the way, I am surprised that your volume has both slice
> widths and has a regular__ spacing type. These from my understanding
> should be mutually exclusive of each other and I'm guessing is what is
> causing the problem.
>
> Why also the use of mincresample to add a few slices? I'd generally do
> this (no interpolation needed).
>
>     mincreshape -dimrange zspace=-1,49 in.mnc out.mnc
>
> Do your dimension widths survive the above? I'd suspect not given the
> regular__ type. Where did this file originate from?
>
>
> a
>
> On 7 February 2014 06:00, Alex Zijdenbos <zijdenbos at gmail.com> wrote:
> > In my conceptual understanding, the -width attributes allow you to
> separate
> > the "thickness" from the sample step size. Indeed most commonly used
> along
> > a time dimension; but I could imagine an image volume being a stack of
> 3mm
> > thick slices with a slice gap of 1mm; making the step size 4mm (a lot of
> > MRI data used to be acquired like that). But I doubt that in reality this
> > is used much, and I have no idea whether something like mincresample
> > actually uses this information during resampling (I suspect not) - but it
> > seems to me that it shouldn't break, either.
> >
> > -- A
> >
> >
> > On Thu, Feb 6, 2014 at 1:17 PM, Andrew Wood <andrew at biospective.com>
> wrote:
> >
> >> Are they ever used for spatial dimensions? It was actually a mistake
> that
> >> it ended up in my affected volumes.
> >>
> >>
> >> On Thu, Feb 6, 2014 at 12:31 PM, Vladimir S. FONOV <
> >> vladimir.fonov at gmail.com
> >> > wrote:
> >>
> >> > I've seen them used in dynamic acquisition where they are used with
> >> > time dimension, for example in PET data
> >> >
> >> > On Thu, Feb 6, 2014 at 12:25 PM, Andrew Wood <andrew at biospective.com>
> >> > wrote:
> >> > > HI All,
> >> > >
> >> > > I ran into a issue when resampling a volume along a dimension which
> has
> >> > > *-width attribute values. It seems that such a dimension can't be
> >> > resampled
> >> > > to have a different number of elements.
> >> > >
> >> > > An example input volume:
> >> > > $ mincinfo in.mnc
> >> > > file: in.mnc
> >> > > image: signed__ short -32768 to 32767
> >> > > image dimensions: zspace yspace xspace
> >> > >     dimension name         length         step        start
> >> > >     --------------         ------         ----        -----
> >> > >     zspace                     47        3.375     -1027.16
> >> > >     yspace                    128     -2.65336      363.575
> >> > >     xspace                    128     -2.65336      171.012
> >> > >
> >> > > $ mincheader in.mnc | grep zspace-width
> >> > >         double zspace-width(zspace) ;
> >> > >                 zspace-width:dimorder = "zspace" ;
> >> > >                 zspace-width:varid = "MINC standard variable" ;
> >> > >                 zspace-width:vartype = "dim-width____" ;
> >> > >                 zspace-width:version = "MINC Version    1.0" ;
> >> > >                 zspace-width:filtertype = "square____" ;
> >> > >                 zspace-width:spacing = "regular__" ;
> >> > >                 zspace-width:width = -3.375 ;
> >> > >  zspace-width = -3.375, -3.375, -3.375, -3.375, -3.375, -3.375,
> -3.375,
> >> > >
> >> > > Now, add a voxel to each dimension:
> >> > > $ mincresample -clobber in.mnc out.mnc -nelements 129 129 48
> >> > > (from miattputstr): Function 'dimrename' not implemented
> >> > >
> >> > > $ mincinfo out.mnc
> >> > > file: out.mnc
> >> > > image: signed__ short -32768 to 32767
> >> > > image dimensions: zspace yspace xspace
> >> > >     dimension name         length         step        start
> >> > >     --------------         ------         ----        -----
> >> > >     zspace                     47        3.375     -1027.16
> >> > >     yspace                    129     -2.65336      363.575
> >> > >     xspace                    129     -2.65336      171.012
> >> > >
> >> > >
> >> > > I dug around the mincresample source code, and the the first thing
> done
> >> > > when creating the output volume is a copy of all variable
> definitions
> >> > from
> >> > > the input, excluding {x,y,z}space, image, and image-{min,max}. It
> >> appears
> >> > > that copying the zspace-width actually forces zspace to be copied,
> >> > > resulting in a naming conflict between the original zspace and our
> new
> >> > > zspace. To work around this, it tries to rename the copied zspace to
> >> > > zspace0, which is where we see the "Function 'dimrename' not
> >> implemented"
> >> > > error message. The result is being stuck with the size of the
> original
> >> > > zspace.
> >> > >
> >> > > The problem goes away if {x,y,z}space-width is added to the
> exclusion
> >> > list
> >> > > for the original variable copy operation. I'm having trouble
> imagining
> >> > when
> >> > > those *-width variables are used though, so I'm not sure if this'd
> be a
> >> > > sane fix.
> >> > >
> >> > > Does anyone have any thoughts that might clear up this situation?
> >> > >
> >> > > Thanks,
> >> > > Andrew
> >> > > _______________________________________________
> >> > > MINC-users at bic.mni.mcgill.ca
> >> > > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
> >> >
> >> >
> >> >
> >> > --
> >> > Best regards,
> >> >
> >> >  Vladimir S. Fonov ~ vladimir <dot> fonov <at> gmail <dot> com
> >> > _______________________________________________
> >> > 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
> _______________________________________________
> 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