[MINC-development] label volumes

Alex Zijdenbos alex at bic.mni.mcgill.ca
Tue Jul 31 11:10:09 EDT 2007


> >> But that still begs the question: has MINC2 been accepted enough yet
> >> that the MINC tools can slowly begin to branch off from backwards
> >> compatibility with MINC1? Or would that be premature?
> >>
> >
> > I think this comes down to the fact that at this stage there is no new
> > tool needed by anybody. :)  And if there is, I suspect that they would
> > use something like minc_simple.h to do it.  (well at least I hope they
> > would!)
> >
> I'm not talking about new tools - and I think this entire thread sort of
> disproves your assertion. Many MINC tools would benefit from treating
> label volumes differently than regular volumes. mincmath and minccalc
> could treat complex numbers (for which there is also support in MINC2)
> correctly. And so on. Nothing essential, as these issues can be
> circumnavigated, yet doing so often results in unnecessary and ugly hacks.

I would agree. I've been handling label volumes for a looong time now
and had gotten somewhat used to the extra mincreshape call to invoke
at the end, but it's not terribly intuitive (that's called
'understatement') to anybody who may not be too familiar with this.
But what i was not aware of is that voxel-loop based code *always*
generates slice-specific ranges which really muck up label volumes. I
think at the very least a user should be able to force the intensity
range calculation to be turned off.

Which in turn begs the question why the set of 'standard' options is
not uniform across all minc tools. Why would I have to know to use
mincreshape to fix the ranges, while really i don't want to reshape
anything? It seems to me the same set of range options should/could be
present in minc*. This way at least a simple advice to anybody
manipulating label volumes, would be to always make add the right
range-preserving options to the tool they run.

But i agree with Jason - it would be much better still to properly
define a label datatype and teach all minc tools how to handle them
the Right Way. Better, but obviously much more involved.

-- A


More information about the MINC-development mailing list