mincreshape +/-direction options

[andrewjanke]

I occasionally bump into the fact that the mincreshape *direction
options operate on image dimensions (the two fastest varying
dimensions, i.e., a slice) only. Things like this:

$ mincreshape -xdirection test.mnc test-x.mnc
Copying chunks:..................................................................................................................................................................................................................Done.

$ mincinfo test.mnc test-x.mnc
file: test.mnc
image: unsigned byte 0 to 165
image dimensions: xspace yspace zspace
dimension name length step start
-------------- ------ ---- -----
xspace 210 0.06 -6.33
yspace 274 0.06 -9.663
zspace 141 0.06 -4.8

file: test-x.mnc
image: unsigned byte 0 to 255
image dimensions: xspace yspace zspace
dimension name length step start
-------------- ------ ---- -----
xspace 210 0.06 -6.33
yspace 274 0.06 -9.663
zspace 141 0.06 -4.8

So I told mincreshape to force the step in x to be negative; but my
volume comes out unchanged. The explanation lives in the man page
under the +direction option:

+direction
Flip images to give positive step value for spatial
axes. Note that the flipping of spatial axes only applies to "image
dimensions". These are the two fastest varying (non-vector) dimensions
in the file. If you want to flip a non-image dimension, you can
convert it to an image dimension with -dimsize dimname=-1 (the -1
means don't really change the size). Check out the examples.

However, this is at best very confusing, if not just wrong. It seems
to me that a very specific instruction like -xdirection should "just
work" regardless of whether or not xspace happens to be an image
dimension. I have seen several posts over the years where people
scratch their heads over this (myself included :)

I can think of a few ways to address this:

• modify mincreshape to "just work" for [+-][xyz]direction
• throw a warning or error when [+-][xyz]direction is used while the
  corresponding [xyz]space is not an image dimension
• make this rather counterintuitive behaviour abundantly clear (e.g.,
  description with every such option in the man page/help)