[MINC-users] negative zstep causes trouble

[Marc Schoenwiesner]

Hi Andrew,

your suggestion worked well (I reshaped the data to have all negative steps,
though, since positive steps don't work with fmr_preprocess [$nelem gets
negative...]).
Dimentions are now (works with minctracc):
zspace    19           -4      68.7014
yspace    64     -3.12497      95.4729
xspace    64     -3.12497      97.9577

before (crashes minctracc):
zspace    19            4     -3.29857
yspace    64     -3.12497      95.4729
xspace    64     -3.12497      97.9577

So it looks more like the negative zstart might be the problem? I am slowly
loosing the overview here...
Mincstats says the CoM (real) is  0.8057721547 -4.288294074 35.31203982
volume_cog gives about the same: 0.942109 -4.382087 35.610321

The file is at /scratch2/marcs/run1.mnc, feel free to play around with it.
I am using whatever version is at /usr/local/mni/bin/minctracc

Cheers,
Marc

Quoting Andrew Janke <a.janke at gmail.com>:

> Hi Marc,
>
> Looks like an "amusing" bug you have found...  Out of interest, what
> does mincstats return on this file as the CoM?
>
> As for +dimension not working, have a read of the man page for
> mincreshape, there is some functionality left in mincreshape that
> treats slice dimensions differently to image dimensions. I think this
> should now be deprecated myself, but then that is just me.
>
> The safest thing to do would be to reshape your data to have all
> positive steps as such:  (note that this will not in any way cause
> flips of the volume)
>
>    mincreshape +direction \
>       -dimsize zspace=-1 \
>       -dimsize zspace=-1 \
>       -dimsize zspace=-1 \
>      <infile.mnc> <outfile.mnc>
>
> Do this before any other processing.
>
> the -1's indicate to flip the dimensions specified irrespective of
> their position in the file. Still the minctracc bug should be fixed!
> Can I have a copy of the file you are using?  And which version of
> minctracc are you using?
>
>
> Andrew