[Insight-users] relabelComponentImageFilter: bug and comments

[jerome schmid]

Hi itk users,

I have a few comments on the relabelComponentImageFilter.

First of all the "bug":

in .h the container for size of connected component in physical units in
defined as:
std::vector<float> m_SizeOfObjectsInPhysicalUnits;

But the Get function GetSizeOfObjectsInPhysicalUnits() const returns

const std::vector<unsigned long>& GetSizeOfObjectsInPhysicalUnits() const,
i.e an unsigned *long* vector instead of a *float* vector.

Here are my remarks:

This filter enlarges the requested region setting it to the largest
possible, because it considers that for connected components (CC) reasons,
all the image must be considered. In the attached picture you can see that
the shape is one CC but in the requested region ( red square ), if this
region is considered alone, there a 2 CCs. So the filter explore all the
image in order to return *1* CC for the requested region. But sometimes we
may know that this phenomenum can appear and we can, for instance, add a
border to image in order to connect the 2 CCs in one. The advantage of doing
this is that you must *not* explore the whole image and study the CCs, and
you save a lot of time. I have so created a localRelabelComponentImage
filter simply by removing the enlarge region function.

Now another remark. Imagine that you have images which pixel type is
unisgned char. It means that there are only 256 possible labels for relabel
component filter or, 1 for background and 255 for the rest. The problem is
that if you have more than *255* CCs, there will be an "overlap": the label
256 will be added in the label 1 for casting reason ( unisgned char i =
static_cast< unisgned char >( 256 ). i == 1! ). So if you are looking for
the biggest CC, and it can be the case often, you will find a lot of regions
*disconnected* ( so it is not a CC...!) with label 1...In order to avoid
this, because it is my particular use, I have considered that every label
superior to 255 wil be added to the last label group:

		if( m_NumberOfObjects > ( NumericTraits<OutputPixelType>::max() - 1 ) )
		{
			// There are not enough labels in output image due to its internal type
limitations
			// set highest label to max
			while ( !oit.IsAtEnd() )
			{
			inputValue = it.Get();

			if (inputValue != NumericTraits<InputPixelType>::Zero)
			{
				// Test in order to detect label too high
				unsigned long label	= relabelMap[inputValue];
				// lookup the mapped label
				if( static_cast< double >( label ) > maxOutputValueDbl )
				{
					// our strategy every too big label is set to max
					outputValue	= maxOutputValue;
				}
				else
				{
					outputValue = static_cast<OutputPixelType>(label);
				}

				oit.Set( outputValue );
			}

			// increment the iterators
			++it;
			++oit;
			progress.CompletedPixel();
			}

		}
		else
		{
			// no limitation problem
			while ( !oit.IsAtEnd() )
			{
			inputValue = it.Get();

			if (inputValue != NumericTraits<InputPixelType>::Zero)
			{
				unsigned long label	= relabelMap[inputValue];
				outputValue = static_cast<OutputPixelType>(label);
				oit.Set( outputValue );
			}

			// increment the iterators
			++it;
			++oit;
			progress.CompletedPixel();
			}
		}

I think so that a good idea will be to put a flag like:

limitationOn	== m_NumberOfObjects > (
NumericTraits<OutputPixelType>::max() - 1 )

and the user will check it, to see if there is a limitation problem. I write
this because it takes me a lot of time to understand what happened the first
time!!!!

Here all these remarks have been already submitted sorry!

Regards,

Jerome Schmid
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CC.jpg
Type: application/octet-stream
Size: 6670 bytes
Desc: not available
Url : http://public.kitware.com/pipermail/insight-users/attachments/20040723/7dcd7135/CC-0001.obj