[Insight-developers] Re: [Insight-users] Histogram bug with
maximum possible value ? (octave)
Karthik Krishnan
Karthik.Krishnan at kitware.com
Sat Jun 10 10:34:36 EDT 2006
Hi Jim,
I agree. This code snippet, should be scrapped, now that histograms for
this class are always represented with double as the precision type.
http://www.itk.org/cgi-bin/viewcvs.cgi/Code/Numerics/Statistics/itkListSampleToHistogramGenerator.h?root=Insight&r1=1.13&r2=1.14
To be correct, the precision of histograms should always be double.
(that shouldn't be a template parameter. To maintain backward
compatibility, I guess we still need to support any datatype for the
measurements within the histogram class itself). However IMHO any
class that internally uses a histogram should be changed to have
double/float as the precision.
-------
Here's what GNU Octave does (don't have matlab)
octave:2> help hist
/usr/share/octave/2.1.72/m/plot/hist.m
Function File: hist (Y, X, NORM)
Produce histogram counts or plots.
With one vector input argument, plot a histogram of the values with
10 bins. The range of the histogram bins is determined by the
range of the data.
Given a second scalar argument, use that as the number of bins.
Given a second vector argument, use that as the centers of the
bins, with the width of the bins determined from the adjacent
values in the vector.
...
Extreme values are lumped in the first and last bins.
-----
So in Octave, you specify the centers of bins as arguments, (dual of
ITK, where you specify the ends of bins). By specifying the centers of
bins you are always having the first and last bins extend to +-inf.
-----
Thanks
-karthik
On Sat, 2006-06-10 at 08:40 -0400, Jim Miller wrote:
> Another thought along these lines is to refer to the defacto standard
> in these
> issues, namely MATLAB. MATLAB will autocalculate bins for you or you
> can specify bin centers (off the top of my head, I think it does
> centers not bounds
> but I could be wrong). What does matlab do with the data far outside
> a specified
> first/last bin?
>
> Jim
>
> On 6/10/06, Jim Miller <millerjv at gmail.com> wrote:
> 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
>
>
>
> _______________________________________________
> Insight-developers mailing list
> Insight-developers at itk.org
> http://www.itk.org/mailman/listinfo/insight-developers
More information about the Insight-developers
mailing list