[MINC-development] label volumes

[Andrew Janke]

Correct

Forgot to mention that bit (thanks)

however this would require someone to write something using the minc2
API! :) The only thing that I know of so far that uses this feature is
leila's MINC2 ITK binding.

a

On 7/31/07, Jason Lerch <jason at bic.mni.mcgill.ca> wrote:
> 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
> >
>
> _______________________________________________
> MINC-development mailing list
> MINC-development at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development
>


-- 
Andrew Janke   (a.janke at gmail.com || http://a.janke.googlepages.com/)
Canberra->Australia    +61 (402) 700 883