Proposals:Defining Label Images: Difference between revisions
No edit summary |
|||
Line 1: | Line 1: | ||
== Background == | == Background == | ||
Initial email from Gaetan Lehmann: | |||
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. | |||
== Problem == | == Problem == |
Latest revision as of 17:51, 7 April 2006
Background
Initial email from Gaetan Lehmann:
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.
Problem
Proposed Solutions
- Defining a set of conventions
- Introducing a new pixel type