WIP: Reduce the default tolerance in threshold_li

[jni]

Fixes #3605

In that issue, I found that a tolerance of range / 2**15 was
sufficient. However, I don't know whether this is generally true, so an
extra factor of 2 is probably a good margin, and gets us to a nice
round number.

Still to do:

• Find an appropriate test case. I might end up using pooch/external data for this, so that I can use the example image from that issue.
• Update the release notes both for dev and 0.14.1.
• Write a dev gallery example about threshold_li. Possibly after merging attribute_operators.

Checklist

[It's fine to submit PRs which are a work in progress! But before they are merged, all PRs should provide:]

• Clean style in the spirit of PEP8
• Docstrings for all functions
• Gallery example in ./doc/examples (new features only)
• Benchmark in ./benchmarks, if your changes aren't covered by an
  existing benchmark
• Unit tests

For reviewers

• Check that the PR title is short, concise, and will make sense 1 year
  later.
• Check that new functions are imported in corresponding __init__.py.
• Check that new features, API changes, and deprecations are mentioned in
  doc/release/release_dev.rst.
• Consider backporting the PR with @meeseeksdev backport to v0.14.x

[jni]

A small update: while I was playing around with the test image, I indeed found that a factor of 2 over the empirically found limit above was insufficient to ensure robustness. After I sampled pixels from the test image in #3605 to get a 1024x1024 image, range / 2**16 still got stuck in the low-gradient area. Part of the problem was that the image has a range greater than 8, but 98% of the pixels are in a much smaller range of less than 1. So the image range is inflated by outliers. But I think this is a general problem, regardless of the number of outliers.

In the end, I found a threshold that I think works in all cases: the tolerance should be strictly less than the smallest difference between two consecutive intensity values. I've made that (half the smallest gap) the default. I think in some cases you might end up making more updates than if you just brute-forced the threshold, but at least it will always be correct (and on average it should be much faster).

There's a chance that we could dramatically speed this up by sorting the intensities and only updating the foreground and background means incrementally, but I leave that for a later PR.

The rest of my to-do list remains to be done, just wanted to update with the current status.

[soupault]

Thanks Juan! Kind reminder about the other bullets.

[lumberbot-app]

Owee, I'm MrMeeseeks, Look at me.

There seem to be a conflict, please backport manually. Here are approximate instructions:

1. Checkout backport branch and update it.

$ git checkout v0.14.x
$ git pull

2. Cherry pick the first parent branch of the this PR on top of the older branch:

$ git cherry-pick -m1 42ff04c884b84e69ec66ce6e56cd380c73e0f6e9

3. You will likely have some merge/cherry-pick conflict here, fix them and commit:

$ git commit -am 'Backport PR #3622: WIP: Reduce the default tolerance in threshold_li'

4. Push to a named branch :

git push YOURFORK v0.14.x:auto-backport-of-pr-3622-on-v0.14.x

5. Create a PR against branch v0.14.x, I would have named this PR:

"Backport PR #3622 on branch v0.14.x"

And apply the correct labels and milestones.

Congratulation you did some good work ! Hopefully your backport PR will be tested by the continuous integration and merged soon!

If these instruction are inaccurate, feel free to suggest an improvement.