[Insight-users] Histogram bug with maximum possible value ?

[Luis Ibanez]

This is a known behavior of the Histogram.

The correct way to use the histogram class for an image of 8-bits
is to set the minimum and maximum to values such as -0.5 and 255.5

Note that the types for setting min and max are not the image pixel
type but its RealType.

The reason is that the min and max that we pass to the histogram
class are the values for the min of the first bin and the max of
the last bin.

If you want to include all the samples, the min value of the bin
bounds must be lower that the actual minimum value expected in the
population, and the max value of the bin bounds must be larger
than the minimum value expected in the population.  This is standard
for computing histogram.

The unfortunate fact is that there are too many bad habits acquired
for people that got used to work only with 8-bit images, and expect
the min and max of the histogram to be 0 and 255. Those are actually
the mid-values of the bins, not the bounds of the bins.

It may be convenient to have a helper initializer class to set the
min and max values for images of (char) and (unsigned char) so that
user's do not have to think about these details.



     Luis



=========================
Karthik Krishnan wrote:
> The histogram class is a widely used class. Please file a bug report and 
> assign it to me with a high priority.
> 
> -----
> 
> That said, I am surprised, it does not handle pixels with intensity 255. 
> See lines 90-102 of 
> http://www.itk.org/cgi-bin/viewcvs.cgi/Code/Numerics/Statistics/itkListSampleToHistogramGenerator.txx?annotate=1.14&root=Insight 
> 
> 
>        h_upper[i] = ((THistogramMeasurement) upper[i]) +
>          NumericTraits< THistogramMeasurement >::One ;
>        if(h_upper[i] <= upper[i])
>          {
>          // an overflow has occurred therefore set upper to upper
>          h_upper[i] = upper[i];
>          // Histogram measurement type would force the clipping the max 
> value.
>          // Therefore we must call the following to include the max value:
>          m_Histogram->SetClipBinsAtEnds(false);
>          }
> 
> If pixel type is UCHAR, it should go into that if block and do the 
> SetClipBinsAtEnds(false) thing. That would mean that the bins at the 
> edges of the histogram extend to infinity, so really 255 should be 
> considered.   [ In the default case, the ends are clipped, See 
> constructor of itk::Histogram with sets ClipBinsAtEnds to true (so 255 
> won't be considered), but that's not the case with you since you are 
> using the ScalarImageToHistogramGenerator.  ]
> 
> 
> Thanks for reporting this.
> -karthik
> 
> 
> Gaetan Lehmann wrote:
> 
>>
>> Hi,
>>
>> I am the only one to have this problem ?
>> Should I file a bug report ?
>>
>> Gaetan
>>
>>
>> On Fri, 02 Jun 2006 17:11:45 +0200, Gaetan Lehmann  
>> <gaetan.lehmann at jouy.inra.fr> wrote:
>>
>>>
>>> I forgot to say I'm using ITK 2.6.0 with gcc 4.0
>>>
>>> On Fri, 02 Jun 2006 16:23:25 +0200, Gaetan Lehmann  
>>> <gaetan.lehmann at jouy.inra.fr> wrote:
>>>
>>>>
>>>> Hi,
>>>>
>>>> I'm trying to manipulate histograms, with itk::Histogram. I'm 
>>>> generating
>>>> the histogram from an image with the ScalarImageToHistogramGenerator
>>>> class. The pixel type of the input image is unsigned char.
>>>> Everything seems to work, as long as there is no pixel value = 255 
>>>> in  the
>>>> image.
>>>> All the pixels with an intensity of 255 are not counted in the  
>>>> histogram.
>>>> For example, the attached image (a 10x10 black image with 4 white (255)
>>>> pixels) produce an histogram with 96 pixels according to the
>>>> GetTotalFrequency() result.
>>>>
>>>> Is it a bug ?
>>>> Or I have missed something ?
>>>>
>>>> Regards,
>>>>
>>>> Gaetan
>>>>
>>>
>>>
>>>
>>
>>
>>
> _______________________________________________
> Insight-users mailing list
> Insight-users at itk.org
> http://www.itk.org/mailman/listinfo/insight-users
> 
>