[MINC-development] label volumes

[Andrew Janke]

> 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