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

Gaetan Lehmann gaetan.lehmann at jouy.inra.fr
Sun Mar 12 10:29:30 EST 2006


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
Url : http://www.itk.org/mailman/private/insight-developers/attachments/20060312/fe551366/attachment.pgp


More information about the Insight-developers mailing list