Feature request: implement generalized histogram thresholding

[jni]

Description

There was a badass paper last year that unified and generalized Otsu and other thresholding methods (arXiv).

As usual, since it's a new algorithm the argument can be made that we should wait to see it in practice, but my gut feeling is that (a) it's really good, and (b) it's a generalization of an existing algorithm that we have in the library, so it does not add much code, and minimum error thresholding (Kittler & Illingworth, 1986) is also generalized by this method, so we would automatically gain an implementation of a thresholding algorithm that has 2600+ citations.

So, I would vote to include it in the library, e.g. as threshold_generalized_histogram. Furthermore, since there is Apache-licensed code available already (notebook), this might be a good first issue for someone who wants to get started contributing to the library.

[Monishver]

Hello @jni , I'm new to open source and would like to make my first contribution to the community. Can you explain this issue in detail.

[sciunto]

@Monishver The main idea is:

• implement the function (based on the notebook) with a full docstring.
• add unittests
• add an example in the gallery

[jni]

@Monishver have you seen our contributing guide?

https://scikit-image.org/docs/dev/contribute.html

Please let us know if you have more questions after reading this!

[Monishver]

Thanks, @sciunto and @jni for helping me get started, I will look into it and get back to you if I have any doubts.

[divyank0]

I guess I can close this. :)

[jni]

@divyank0 that would be much appreciated! 🎉

[divyank0]

I am preparing the ticket , few questions I have

• What is meant by ndarray : (N, M[, …, P])

[divyank0]

I am wondering what could be ideal signature for the function

def theshold_generalized_histogram(n, x=None, nu=0, tau=0, kappa=0, omega=0.5):
or
def theshold_generalized_histogram(image, x=None)

where x is the array of bin intensities , n is histogram and others are algorithm specific parameters.

The first one is definitely going to there, however we can name it to GHT.
Supplying all 4 parameters for GHT algorithm requires advance knowledge, for which we have to understand algorithm.

However for 2nd one, we have to supply default parameters, which might not suffice the problem. The user will need more control to optimally solve his thresholding problem.

If my understanding is correct, This algorithm is for advanced User, since this requires tuning of 4 parameters.

[sciunto]

I vote for the first proposition, parameters must be adjustable. We have also other algorithms requiring some knowledge in scikit-image. We must do our best in the docstring to provide an intuition of the behavior of each parameter (with a formula or with typical effects).

[divyank0]

I have a created a pull request for this. do have a look.

one suggestion made by mkcor is to use default Parameter values. It might be a good idea, what does everyone think about it?

As to what those values could be? We could set values of nu, tau, omega, and kappa corresponding to Otsu's method.
Hence by default generalized histogram thresholding will work as Otsu's method.

[jni]

The signature should take an image or a histogram, where the histogram can be either just the set of frequencies or the bin centres and the frequencies. See the code for Otsu's thresholding for details. The idea is that you can provide the image (as all thresholding methods do), or, if you have a precomputed histogram, you can provide the histogram, which is more efficient.

The parameters should all be accessible and yes, defaulting to Otsu's is probably the most sensible default.