[MINC-development] Grid transforms

[Vladimir S. FONOV]

That's usual MINC wired behavior with zero dynamic range volume. Have
nothing to do with representing a transform.

On Dec 21, 2016 11:01 PM, "Andrew Janke" <a.janke at gmail.com> wrote:

> Yup, this does work, (along with using anything other than a signed type).
>
> The problem is that this only goes awry when you pass the file as part
> of an xfm to xfmconcat, not during routine mincreshape/mincmath games.
>
> So, I'd argue it's a bug in volume_io (concatenate_general_transforms)
> but it comes down to what is defined behaviour in MINC with grid
> transforms. As far as I am aware this isn't defined and largely
> "whatever minctracc puts out".
>
> If this is the case should we:
>
> a) Warn the user if an input grid file is given which isn't either
> unsigned short or double (currently used options by minctracc)
>
> b) Convert it to something that will work.
>
>
> ta
>
> a
>
>
>
> On 22 December 2016 at 11:54, Vladimir S. FONOV
> <vladimir.fonov at gmail.com> wrote:
> > Try specifying -image_range 0 1 -valid_range 0 1 in mincreshape
> >
> > On Dec 21, 2016 8:47 PM, "Andrew Janke" <a.janke at gmail.com> wrote:
> >>
> >> Hi all,
> >>
> >> I understand that a while back the precision of grid transforms went
> >> from short to double. This was probably around the -50 -> + 50
> >> wierdness that used to happen within minctracc.  Perhaps there were
> >> also other rationales.
> >>
> >> Were there also other changes to libminc/volume_io to support this? I
> >> ask as I'm getting wierdness with xfmconcat when I feed in a zero grid
> >> transform.  ie:
> >>
> >> mincresample -xstep 32 -ystep 32 -zstep 32 \
> >>    -xnelements 10 -ynelements 10 -znelements 10 \
> >>    /opt/minc/share/icbm152_model_09c/mni_icbm152_t1_tal_nlin_
> sym_09c.mnc
> >> /tmp/like.mnc
> >>
> >> minclookup -signed -short -lut_string '0 0 0 0;1 0 0 0'  /tmp/like.mnc
> >> /tmp/like_vector.mnc
> >>
> >> mincreshape -dimorder vector_dimension,zspace,yspace,xspace \
> >>    /tmp/like_vector.mnc /tmp/zero_grid_0.mnc
> >>
> >> echo "MNI Transform File" > /tmp/zero.xfm
> >> echo "Transform_Type = Grid_Transform;" >> /tmp/zero.xfm
> >> echo "Displacement_Volume = zero_grid_0.mnc;" >> /tmp/zero.xfm
> >>
> >> xfmconcat /tmp/zero.xfm /tmp/z.xfm
> >>
> >> mincstats /tmp/z.xfm
> >>
> >> cai-zeep:tmp$ mincstats z_grid_0.mnc
> >> *** mincstats - reported max (-32768) doesn't equal header (32767)
> >> File:              z_grid_0.mnc
> >> Mask file:         (null)
> >> Total voxels:      3000
> >> # voxels:          3000
> >> % of total:        100
> >> Volume (mm3):      98304000
> >> Min:               -32768
> >> Max:               -32768
> >>
> >> Note the messed up min and max. This will work however if you make an
> >> unsigned short volume at the minclookup stage.   If I then use this
> >> transform things of course go awry instead of it being a zero xfm.
> >>
> >> So, is this defined or unexpected behaviour? If I use a double, I get
> >> a more interesting error instead of a failure.
> >>
> >> xfmconcat ident-32.xfm /tmp/d.xfm
> >> Volume has invalid min and max voxel value
> >>
> >>
> >> ta
> >>
> >>
> >> a
> >> _______________________________________________
> >> MINC-development mailing list
> >> MINC-development at bic.mni.mcgill.ca
> >> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development
> >
> >
> > _______________________________________________
> > MINC-development mailing list
> > MINC-development at bic.mni.mcgill.ca
> > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development
> >
> _______________________________________________
> MINC-development mailing list
> MINC-development at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.bic.mni.mcgill.ca/pipermail/minc-development/attachments/20161222/52df4127/attachment-0001.html>