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

[Gaetan Lehmann]

I'm bored of asking this question, and I really can't understand the  
silence about it. That's not a complex subject where lot of time have to  
be spent. No one in itk developers have been able to make a decision -  
that will be more inconsistency in the toolkit with the new classes from  
the insight journal, and more backward compatibility problems when finally  
someone will make that decision.

By the way, the insight journal is a complete disaster for discussions -  
there is some exceptions, but the more interesting ones are on the mailing  
lists. And talking about a contribution a few days before (perhaps) adding  
it in the toolkit is definitively a bad idea: how can we have time to  
improve such or such thing?
I thought the insight journal can enhance the contribution process. It's  
still a pain.
ISC have not understand that some contributors, like me, are spending lot  
of time on the toolkit? It looks like a chance for ISC - some work at  
nearly no cost - and should not be discourage by this lack of  
communication effort.

For the ones interested in labels, you can have a look at the label  
overlay article. The examples show that it can be useful to be able to use  
a background label or not, and that it can be useful to choose the  
background label value.

Gaetan


On Wed, 19 Apr 2006 17:42:58 +0200, Gaetan Lehmann  
<gaetan.lehmann at jouy.inra.fr> wrote:

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