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

[Andrew Janke]

> Actually, the motivation for changing this is not a "current itch" - I
> can scratch my current itch just fine. It is a concern that the
> current default behaviour has a very high probability of giving
> "wrong" output that will likely go unnoticed. With "wrong" I mean with
> possibly severe quantization errors that the user did not expect; and
> with "user" I mean those who may not have the knowledge of the ins and
> outs of MINC like some of us do.

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

> I was under the impression that one of the central ideas behind MINC
> was that the user wouldn't need to care about or be aware of data
> type.

In general that is the idea, and in general 16bits (short) is enough
for most people WRT precision, then of course you add in a divide
sign...  At this point it doesn't really matter if you are using
double, you still can't see your result!

> So in order to avoid this, one
> would either have to use a blunt hammer and force a float output
> volume; or first figure out what datatypes the input volumes have and
> then do the right (or better) thing. Neither of these are obvious to
> the average user who just wants to add two volumes together.

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.

> 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.


a