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

Alex Zijdenbos zijdenbos at gmail.com
Tue Nov 20 09:30:25 EST 2012


>> or to explicitly specify the output type. Maybe adding an option such
>> as "minccalc -like file.mnc -expression ...." would be an easy way to
>> remind the user to choose an output data type.
>
> This sounds like a very sensible idea. There is a "-filetype" option
> for minccalc that probably few know of which is along this track.

Well - mincmath has this option too, but this is currently a no-op, is
it not? It is the default and there is no alternative, other than
specifying the data type explicitly; so the option might as well not
exist :) I doubt that anybody has ever used it, for that reason.
Perhaps it could be re-used to do what Claude suggest - but it would
then have to take an argument.

> would prefer to not use -like given that this is already used for a
> different purpose in mincresample so would prefer not to muddy the
> waters.

Agreed. And if a -like option is going to be added anywhere, I vote
for mincreshape :)

> So I'm open to suggestions. -outtype?

Seems reasonable to me. Note that this option still requires that the
user is aware which file to use as a model, which I was hoping to
avoid. I think that conceptually, if I want to add two volumes (with
different data types) using

  mincmath -add A.mnc B.mnc sum.mnc

I shouldn't have to figure out which has the larger data type, but I
would nevertheless still expect to get the same result if I switch A
and B. That is currently not the case.

>> About loss of data, I think this is a separate issue. Binarization
>> of data is part of the minc concept, but what I don't like about it,
>> especially for integer data types, are the different min/max scaling
>> values by slice. This means a value of 100 can vary from slice to
>> slice. This is particularly annoying with labels. I think Andrew
>> once pointed out a global compilation variable to set to obtain
>> a global min/max for the entire volume, but I forgot it since. I
>> would very much like to be able to enable this feature on a per
>> file basis via a command line option.
>
> This would mean some changes to voxel_loop.{c,h} which would then have
> to be exposed via some C/L switch. Probably the easiest way to achieve
> this functionality is to simple specify the -range option (eg: -range
> 0 255) in minccalc.

The issue of label values and scaling comes up regularly, and in my
mind is one of the biggest problems MINC has/has had. I have scripts
that manipulate label volumes that call 'mincreshape -valid_range -
image_range' after practically *every* call to one of the other MINC
tools, which is really tedious. It is also quite difficult to explain
to novice users; I probably have a lengthy discussion about this with
somebody at least once a month.

Would there be any conceivable way to make MINC aware of a pure
integer data type without rewriting large swaths of the library? For
instance, could the scaling simply be turned off (like I assume it is
for float), under command-line control and/or a header attribute? Like
a -noscale option or some such?

-- A


More information about the MINC-users mailing list