[Insight-developers] Re: binary object and label definitions

[Gaetan Lehmann]

I'm looking at http://www.itk.org/Wiki/ITK_Release_Schedule and see  
several new filters which use labels and/or binary objects.
It would be nice to have the same usage of binary objects and labels for  
those new filters before inclusion in the library. The experience again  
shown me yesterday that the mixed definition is confusing in ITK.
Is there finally a consensus about what is a label and what is a binary  
object ?

Also, LabelOverlayImageFilter I have submited is wrong, if we follow what  
I have proposed some time ago for labels (0 can be a label), and it would  
be nice to have time to correct the code.

Gaetan


On Fri, 17 Mar 2006 02:10:29 +0100, Richard Beare  
<richard.beare at gmail.com> wrote:

> Hi everyone,
>
> A few thoughts on types for label images:
>
> I'm not sure I'd go with the concept of unsigned types for label
> images, or with a new type. However I would agree that filters
> producing label images should use positive label values and use zero
> to indicate absence. My thinking here is based on the following:
>
> In label propogation algorithms that involve queues it is often
> necessary to mark which pixels are on the queue have already been
> processed, or the equivalent. Using the negative half of the image
> range is often a convenient way of doing this if it is guaranteed to
> be available. The alternative is to allocate marker images, which is
> obviously possible but more expensive.
>
> Another reason not to insist on unsigned types, or a new type, is the
> impact on the size of the libraries used in the interpreter
> interfaces. In addition, it is reasonably common to manipulate label
> images using masking and other standard image operations, and
> introducing a new type is surely going to make this sort of thing even
> more complicated, especially for interpreter interfaces.
>
> Now, if an application is never going to do anything radical with a
> label image then the unsigned types will be fine, and are likely to be
> more efficient. So perhaps the conventions should be:
>
> any integer type (perhaps we should relax this, but I can't see an
> obvious reason), zero is "blank", valid labels are positive.
>
> Then rely on the concept checking to deal with signed/unsigned issues
> and anything else that crops up for filters that process labels.
> _______________________________________________
> Insight-developers mailing list
> Insight-developers at itk.org
> http://www.itk.org/mailman/listinfo/insight-developers



-- 
Gaëtan Lehmann
Biologie du Développement et de la Reproduction
INRA de Jouy-en-Josas (France)
tel: +33 1 34 65 29 66    fax: 01 34 65 29 09
http://voxel.jouy.inra.fr