[MINC-development] label volumes

[Jason Lerch]

MINC2 has explicit support for label volumes, right? At what point 
should the various MINC tools take advantage of such features, even if 
that breaks backwards compatibility?

(see http://www.bic.mni.mcgill.ca/software/minc/minc2_format/node23.html 
- though I don't know if this has actually been implemented yet)

Jason

Andrew Janke wrote:
>> Claude and I have been looking at a problem relating to the handling
>> of label volumes (e.g., atlases) in minc (1.x). There exist a number
>> of atlas files associated with ANIMAL which have intensity scaling in
>> them (real range != voxel range). This  causes the labels to appear as
>> floating point values, which can sometime be several decimal points
>> away from the integer label value; this in turn can cause label values
>> to switch over to the adjacent label when manipulated by certain minc
>> tools.
>>
>> There are two issues or questions:
>> 1. How *should* label volumes be constructed?
>>
>>      The simple answer I believe is to make sure that the intensity
>> mapping is the identity mapping, so that in effect the real values are
>> equal to the voxel values.
>>     
>
> Correct, the way I have always done this is do a mincreshape to files
> that are misbehaving..
>
>    mincreshape -image_range 0 255 -valid_range 0 255 ...
>
> If you are dealing with a byte file.  The problem occurs in that the
> notion of a label volume really is just that in MINC, there is no real
> support for it. There is however support for it in volume_io.
>
> Take a look at the end part of the code in mincmorph for one example
> of how you can make sure that things are "right" in C code.
>
>   
>> 2. How do existing minc tools handle label volumes?
>>     
>
> Not all that well if only because there are no easy heuristics that
> you can use to figure out if the input file is indeed a "label" volume
> and there is no special tag for this.
>
>   
>>     It turns out that tools like mincmath and minccalc do not have a
>> -keep_real_range option, and will *always* create slice-specific
>> intensity mappings. This wreaks havoc on label files. A simple
>> solution may be to add a -keep_real_range option to tools like
>> mincmath and minccalc.
>>     
>
> Correct, this really is true of not just these two in isolation but
> rather any program that uses voxel_loop.  Still I dont think that
> there is a better way in code to do it without rewriting vast swathes
> of code in each of the MINC tools with a big "if(label)" at the top.
>
>   
>> Thoughts, comments?
>>     
>
> Well my approach is as such.
>
>    1. labels are bad.   (personal view, I much prefer to stick with
> probabilistic maps!)
>
>    2. Use float.  It is the only way that you can guarantee that you
> are getting what you (think you) want.
>
>    3. Use byte and religiously reset the range after each operation.
>
> It is for these reasons that tools like mincstats have the options
> like -mask_binvalue you can generally be sure that +/- 0.5 will work..
> ;)  This at least was always Peters impression of how a label volume
> should work.
>
>
> a
> _______________________________________________
> MINC-development mailing list
> MINC-development at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development
>