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

[Vladimir S. FONOV]

Unfortunately, as I said, it breaks compatibility with minc1 api, which 
is basis for most minc tools. So, it doesn't work with minccalc as far 
as I know. You can see example in
https://github.com/BIC-MNI/libminc/blob/master/testdir/minc2-label-test.c
- one can even store a lookup table describing what the numeric values 
mean (i.e 1 - CSF,  2 - Gray Matter, 3 - White Matter etc. ).


On 12-11-20 04:53 PM, Alex Zijdenbos wrote:
> !! Who'd have thunk. Those who implemented MINC2 I guess :)
>
> But this is so far not used above-hood - in any of the minc* tools, is it?
>
> -- A
>
> On Tue, Nov 20, 2012 at 11:33 AM, Vladimir S. FONOV
> <vladimir.fonov at gmail.com> wrote:
>> Hello,
>>
>>
>> Actually MINC2 even has a 'label' data type , which breaks compatibility
>> with minc1 layer, but behaves in a way that you want.
>>
>>
>> On 12-11-20 09:30 AM, Alex Zijdenbos wrote:
>>>
>>> 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?


-- 
Best regards,

  Vladimir S. FONOV ~ vladimir.fonov <at> gmail.com