[MINC-users] default slice min/max in mincreshape?

[Alex Zijdenbos]

On Fri, Jun 1, 2012 at 1:02 AM, Andrew Janke <a.janke at gmail.com> wrote:
> Hi Alex,
>
> On 1 June 2012 13:51, Alex Zijdenbos <zijdenbos at gmail.com> wrote:
>> It's easy to fix by adding -normalize to the mincreshape call; but the
>> question I have is: why is the image-max for added, empty slices set
>> to 1 (instead of 0 for example)? It seems to me that this may cause
>> trouble for all volumes with real values much smaller than 1.
>
> My bet for this one is definitely on a rounding error given you
> combination of a very (very) small range and a byte datatype. I'd be
> curious to know if the same thing happens if you first convert the
> volume to float.

Well that works; and in fact it turns out that the byte volume is also
still correct (contains all the data). mincstats for example gives
meaningful output, and a warning:

*** mincstats - reported max (0.00048708) doesn't equal header (1)

so the problem actually (and arguably) may not be with the minc volume
itself, but with some other tools, such as mincblur, that probably
rely on the header-reported max instead of the real (data) max, and as
a result scale the very very small data values into nothingness.
Either way it still seems to me that the fundamental problem is that
mincreshape adds the blank slices with image-max=1, which is much
higher as the image-max(es) before the padding.

-- A