[Insight-developers] Re: [Insight-users] Histogram bug with
maximum possible value ?
Jim Miller
millerjv at gmail.com
Sat Jun 10 08:36:22 EDT 2006
Karthik,
I think the ScalarImageToHistogramGenerator should set the min/max bounds
to be k-0.5, k+0.5 as Luis indicated. This is how I build my histograms for
integral types.
I think the code
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);
}
should be scrapped for integral types and specify the bins with as k-0.5
,k+0.5.
Then the ClipBinsAtEnds does not need to be used.
On a side note, we may want to come up with a synonym/antonym for
ClipBinsAtEnds.
What this mode is doing is deciding whether to include all the mass in the
distribution that is outside the histogram domain in the first/last bin
verses
just ignoring that mass. I just don't know a better name right now..
AutoExpandHistogramDomain()
IgnoreDataOutsideHistogramDomain(),
IngoreMeasurementsOutsideHistogramDomain()
IncludeDataOutsideHistogramDomain(),
IncludeMeasurementsOutsideHistogramDomain()
These modes bring up an interesting question. If the ClipBinsAtEnds is off,
then the first/last
bin runs to -+ infinity respectively. If you then ask for the bin bounds,
should the first/last bin
report that their bounds are -+ infinity respectively? Probably should.
Jim
On 6/8/06, Karthik Krishnan <Karthik.Krishnan at kitware.com> wrote:
>
> Gaetan, Uwe, Luis:
>
> My point was that despite all that the histogram would be computed the
> right way, without any user intervention, *even if you don't set the
> bounds* (if you are using ScalarImageToHistogramGenerator. Otsu uses
> that)...
>
> See
>
> http://www.itk.org/cgi-bin/viewcvs.cgi/Code/Numerics/Statistics/itkListSampleToHistogramGenerator.txx?annotate=1.14&root=Insight
>
> The min and max are automatically computed for you in line 63 and that
> will be 255 in your case
> Line 90 : The upper bound of the histogram is set to 255 + 1 = 256. So
> the histogram should be fine too.
>
> I just checked the code snippets with a debugger to see if there were
> overflows due to datatype etc.. and its fine..
>
> So what is the bug here ? Could I please have a minimal code where it
> doesn't work.
>
> [ You can run Examples/Statistics/ImageHistogram2.cxx after commenting
> out the SetHistogramMin/Max part on a binary image, such as
> Insight/Examples/Data/Circle.png - UCHAR image with pixels 0/255 and
> your histogram will still be fine].
>
> Am I mistaken here ?
>
> Thanks
> -karthik
>
>
>
> Gaetan Lehmann wrote:
>
> >
> > Hi Luis,
> >
> > So it explain the observed behavior :-)
> > However, a naive user (let say me) would think the following code
> > (stollen from itkOtsuMultipleThresholdsImageFilter.txx to implement
> > my own filter) will return an histogram with all the values:
> >
> > // Create a histogram of the image intensities
> > typename HistogramGeneratorType::Pointer histogramGenerator =
> > HistogramGeneratorType::New();
> > histogramGenerator->SetInput( this->GetInput() );
> > histogramGenerator->SetNumberOfBins( m_NumberOfHistogramBins );
> > histogramGenerator->Compute();
> >
> > By the way, does it mean that OtsuMultipleThresholdsImageFilter code
> > is broken ?
> > Perhaps the class ScalarImageToHistogramGenerator should be modified
> > to set the min and max values to include all the values ?
> >
> > Gaetan
> >
> >
> > On Thu, 08 Jun 2006 14:00:25 +0200, Luis Ibanez
> > <luis.ibanez at kitware.com> wrote:
> >
> >>
> >> For mor details, you may want to look at the Examples:
> >>
> >>
> >> Insight/
> >> Examples/
> >> Statistics/
> >> ImageHistogram1.cxx
> >> ImageHistogram2.cxx
> >>
> >> in particular to the call for the methods:
> >>
> >> SetHistogramMin()
> >> SetHistogramMax()
> >>
> >>
> >> Note again that the min and max values of the histogram
> >> refer here to the values of the bin bounds, not the the
> >> values to be accepted in the bins.
> >>
> >> For an image of integer pixel type, the bounds of the
> >> bins must be of the type K-0.5,K+0.5, so that the bin
> >> accepts the value K (where K is an integer).
> >>
> >>
> >> Luis
> >>
> >>
> >> ---------------------
> >> Luis Ibanez wrote:
> >>
> >>> 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
> >>>>
> >>>>
> >>> _______________________________________________
> >>> Insight-developers mailing list
> >>> Insight-developers at itk.org
> >>> http://www.itk.org/mailman/listinfo/insight-developers
> >>>
> >>
> >>
> >> _______________________________________________
> >> Insight-users mailing list
> >> Insight-users at itk.org
> >> http://www.itk.org/mailman/listinfo/insight-users
> >
> >
> >
> >
> _______________________________________________
> Insight-developers mailing list
> Insight-developers at itk.org
> http://www.itk.org/mailman/listinfo/insight-developers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.itk.org/mailman/private/insight-developers/attachments/20060610/488c7ff9/attachment.html
More information about the Insight-developers
mailing list