[Insight-developers] OtsuThresholdCalculator versus OtsuMultipleThresholdsCalculator

[Richard Beare]

Hi,
I think the order was - I introduced new filters copied from ImageJ, then
Gaetan started refactoring to use the histogram framework. We both did some
work to make that correspond to old versions. I don't remember working on
the MultipleThreshold  version, but the code does look similar, so perhaps
it was done somewhere along the way - will need to check the logs.

I'm pretty sure that Otsu was producing the same results that it used to -
I didn't compare to other implementations. Thus, if the original Otsu was
correct then the current one should be too, which would suggest that the
MultipleThresholds version should probably change.

Not sure when I'll get a chance to look at this in detail.

I don't have a current email for Gaetan to CC for confirmation.


On Mon, Jul 1, 2013 at 11:02 PM, Bradley Lowekamp <blowekamp at mail.nih.gov>wrote:

> Dirk,
>
> I believe Richard Beare did the refactoring of the thresholding framework
> an Insight Journal Article. He will likely know why it is this way better
> than anyone else.
>
> You also didn't say which implementation is correct.
>
> Brad
>
>
> On Jun 30, 2013, at 10:03 PM, "Padfield, Dirk R (GE Global Research)" <
> padfield at research.ge.com> wrote:
>
> > Hi ITK Developers,
> >
> > I was just looking through the OtsuThresholdCalculator and
> OtsuMultipleThresholdsCalculator to see whether I could refactor them so
> that the Otsu inherits from the OtsuMultiple since the latter is a more
> general case of the former.  Currently, the code for these two filters is
> totally different resulting in significant code duplication and a need to
> keep both filters in sync.
> >
> > As a first step, I wrote a CMake test to check that the output of the
> OtsuMultiple with 1 threshold is the same as the output of the Otsu.
>  Unfortunately, they are not!  The two filters output thresholds that are
> different by 1 histogram bin!  This can be a quite extreme difference when
> the numberOfHistogramBins is low, and it leads to different thresholds even
> when the numberOfHistogramBins is reasonably high (say 256).  I tracked it
> down to this code in the Calculators:
> >
> > The relevant code from Otsu:
> >   const double tolerance = 0.00001;
> >   if ( (varBetween - tolerance) > maxVarBetween )
> >     {
> >     maxVarBetween = varBetween;
> >     maxBinNumber = j;
> >     }
> >   }
> > this->GetOutput()->Set( static_cast<OutputType>(
> histogram->GetMeasurement( maxBinNumber + 1, 0 ) ) );
> >
> > The relevant code from MultipleOtsu:
> >   if ( varBetween > maxVarBetween )
> >     {
> >     maxVarBetween = varBetween;
> >     maxVarThresholdIndexes = thresholdIndexes;
> >     }
> >   }
> > for ( j = 0; j < m_NumberOfThresholds; j++ )
> >   {
> >   m_Output[j] = histogram->GetBinMax(0, maxVarThresholdIndexes[j]);
> >   }
> >
> > The difference is that the Otsu adds one to the computed threshold
> whereas the MultipleOtsu does not.  This is problematic because users would
> expect them to give the same result.
> >
> > My question is: how should we proceed?  If we change one or the other,
> people's code that use the changed one will give slightly different
> answers.  If we don't change them, the two filters will give different
> outputs for the same input, and it will not be possible to refactor them to
> share code.
> >
> > What are your thoughts?
> >
> > Thanks,
> > Dirk
> > _______________________________________________
> > Powered by www.kitware.com
> >
> > Visit other Kitware open-source projects at
> > http://www.kitware.com/opensource/opensource.html
> >
> > Kitware offers ITK Training Courses, for more information visit:
> > http://kitware.com/products/protraining.php
> >
> > Please keep messages on-topic and check the ITK FAQ at:
> > http://www.itk.org/Wiki/ITK_FAQ
> >
> > Follow this link to subscribe/unsubscribe:
> > http://www.itk.org/mailman/listinfo/insight-developers
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/pipermail/insight-developers/attachments/20130702/d6ba2daf/attachment.htm>