[MINC-users] multi-input output type/range

[Alex Zijdenbos]

> Ah, OK. Problem of course being is what to do with the ones who have
> gotten used to the current behaviour.

Well we don't necessarily need to take the old behaviour away :)

> Well if we are just adding then I think this one is already reasonably
> covered. Adding in multiplication and other nasty things like division
> and everything goes bad. Still I can't think of a good way around this
> as if you are dynamically calculating what the output should be you
> are just going to end up with a double 99.9% of the time due to
> outliers and noise in the image with really small values.

Obviously - there is no magic bullet. However I think that the vast
majority of MINC volumes out there are either byte or short, and often
have shrunken data ranges. Many of those are label volumes as well.
More than a few times I have been presented with a scenario like this:
"help! In my script I am masking volume X with the gray matter from
the classification, but my output looks funny". What would be
happening is something like this:

minccalc -expression "abs(A[0] - 2) < 0.5 ? A[1] : 0" <cls.mnc>
<in.mnc> <masked.mnc>

where <cls.mnc> happened to be "unsigned byte 0 4"; now resulting in
<masked.mnc> quantized to 5 values. Yes, easily solved by putting
<in.mnc> first; but I can't blame people for finding this at the very
least counter-intuitive. To me it seems (more) reasonable that if you
perform some sort of math/calc operation on two integer volumes, to
inherit the one with the widest range, not simply the first one. But
that is just my $0.02.

>> I actually cannot come up with a situation where I would *want* to
>> lose data in quantization, so I am curious: can you give an example of
>> how you relied on the current behaviour?
>
> Primarily it's about disk space. In my case models are nearly always
> computed as float but the resulting model is generally converted to
> short. So, this means that during the resampling and intensity
> rescaling you be sure to put the model second or else you double the
> amount of $TMPDIR required.

Right - but the difference being that in this case you are most likely
explicitly aware of the types you are using; so you could probably
also just add -short to the call.

In a lot of my code I have actually gone to the extent of - when I
don't want to clutter my tmp space with float volumes - writing subs
or wrappers that first run mincinfo on all input volumes, and then
force the output data type and range. It just seemed to me it would be
more natural to build that into minccalc/math.

-- A