[Insight-developers] binary object and label definitions in ITK

[Luis Ibanez]

Hi Gaetan,


I agree with you that we should make a decision on this issue.


I would vote for the following:


   1) Label types must be on of : "unsigned" { char, short, long }

   2) In binary cases the values would be max() and ZeroValue()



It will be easier to enforce these policy if we introduce a
LabelPixel type, just as the RGBPixel type. In this way, developers
and users will not have to be wondering about the details of the
labels. It will help also to enforce the type of the image produced
as output or expected as input by filters related to labels.


       Luis


-----------------------
Gaetan Lehmann wrote:
> Dear developers,
> 
> Would it be possible to take a decision ?
> I have a filter to submit to the journal which manipulates labels, and plan to 
> work on another one.
> 
> There is no revolution here, just a decision to take
> 
> Gaetan
> 
> 
> On Wednesday 01 March 2006 14:54, Gaetan Lehmann wrote:
> 
>>On Tue, 28 Feb 2006 17:25:23 +0100, Miller, James V (GE, Research)
>>
>><millerjv at crd.ge.com> wrote:
>>
>>>For binary designation:
>>>
>>>Personally, I prefer using "zero" for background and "one" for foreground
>>>for binary objects (as opposed to max()). 'Course, I really don't have
>>>a problem with any nonzero value being identified as foreground.
>>>
>>>The only drawback to using "one" for foreground is that when you write
>>>out the image, you may not be able to see the objects because both
>>>the foreground and background are in the low end of dynamic range.
>>>
>>>I understand the interest for standardizing this, as I was bit once
>>>when I assumed a filter was producing 0/1 for binary images but was
>>>producing 0/255.
>>
>>I prefer zero-max than zero-one for the reason you give, but I can live
>>with zero-one solution too :-)
>>The important things are:
>>- it must be documented
>>- try to use the same convention in all filters, without breaking the API
>>- the new filters must use that convention
>>
>>There is some new filters contributed to the Insight Journal which are
>>manipulating those notions, so we should choose a clear definition before
>>integrating those new filters in ITK, and so limit inconsistencies
>>
>>
>>>For labels:
>>>
>>>The idea of allowing any value to be a valid label is reasonable. In
>>>fact, I think the watershed algorithm makes this assumption.  The
>>>relabel component filter currently assumes zero is the background.
>>>A mode could be added to this filter to treat zero as background or not.
>>>This would ensure backward compatibility from a results perspective.
>>
>>agree :-)
>>
>>
>>>Jim
>>>
>>>
>>>
>>>-----Original Message-----
>>>From: insight-developers-bounces+millerjv=crd.ge.com at itk.org
>>>[mailto:insight-developers-bounces+millerjv=crd.ge.com at itk.org]On Behalf
>>>Of Gaetan Lehmann
>>>Sent: Monday, February 27, 2006 4:42 PM
>>>To: insight-developers at itk.org
>>>Subject: [Insight-developers] binary object and label definitions in ITK
>>>
>>>
>>>
>>>Hi,
>>>
>>>While talking about types usable to manipulate binary objects and labels
>>>with
>>>Zach, we found that they don't seem to be clearly defined in ITK.
>>>
>>>For example, ConnectedComponentImageFilter consider that binary objects
>>>are
>>>connected set of non-zero pixels, while BinaryDilateImageFilter use a
>>>value
>>>setted by the user to manipulate the binary object.
>>>Also, while we can consider as label any value allowed by a type, some
>>>filters
>>>may fail if those values are negative.
>>>
>>>I think we should clearly define those 2 notions to avoid inconsistency
>>>in the
>>>toolkit. I would like to propose the following ones - please correct and
>>>comment them:
>>>- The binary objects are defined with a foreground value, by default
>>>itk::NumericTraits<PixelType>::max(), so we can manipulate several
>>>objects
>>>(labels). If a background value is needed, by default we should have
>>>always
>>>the same: itk::NumericTraits<PixelType>::NonnegativeMin() (or
>>>itk::NumericTraits<PixelType>::Zero, it just need to be chosen). That's
>>>what
>>>BinaryDilateImageFilter does, but it would break
>>>ConnectedComponentImageFilter behavior.
>>>- labels are any values allowed by a type. If a type need to exclude some
>>>values, to define a background for example, the user should be able to
>>>set
>>>those values - it would break the RelabelComponentImageFilter behavior.
>>>
>>>Comments are welcome !
>>>
>>>Gaetan
>>>
>>>
>>>------------------------------------------------------------------------
>>>
>>>_______________________________________________
>>>Insight-developers mailing list
>>>Insight-developers at itk.org
>>>http://www.itk.org/mailman/listinfo/insight-developers