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

[Dr. Uwe Köhler]

Dear Karthik,

I can confirm that there is a problem with the histogram class. From my 
earlier posting:

I hope somebody can help me out with a (hopefully) easy, but important 
question. When using the ImageHistogram1 example to look at a grayscale image 
with 15 gray values in the range from 0 to 255, I get all the gray values 
listed correctly appart from the ones valued 255. My guess is that this has 
to do with the fact that the histogram size is given as 255 for 256 possible 
gray value, but I am not sure. I tried a size of 256, but it leads to an 
unsigned char overflow and the results are wrong.

I had to write my own histogram class to avoid the problem for now.

Cheers

Uwe

> Message: 5
> Date: Wed, 07 Jun 2006 17:53:37 -0400
> From: Karthik Krishnan <Karthik.Krishnan at kitware.com>
> Subject: Re: [Insight-users] Histogram bug with maximum possible value
> 	?
> To: Gaetan Lehmann <gaetan.lehmann at jouy.inra.fr>
> Cc: "insight-users at itk.org" <insight-users at itk.org>,
> 	"Insight-developers \(E-mail\)" <insight-developers at itk.org>
> Message-ID: <44874AE1.5090407 at kitware.com>
> Content-Type: text/plain; charset=ISO-8859-15; format=flowed
>
> 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/itkListSamp
>leToHistogramGenerator.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
>