[MINC-development] label volumes

[Jason Lerch]

Andrew Janke wrote:
> 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.
>   
Don't forget RMINC!

Somewhere on my todo list is writing a tutorial on programming with the 
MINC2 API ... sometime this century, I promise, unless someone beats me 
to it.

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?

Jason
> 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
>>
>>     
>
>
>