Lars Grüter

Re https://github.com/scikit-image/scikit-image/pull/7771#issuecomment-2793811560, I can live happily with `from_estimate`. :smile: Regarding raising on failure, this would be a way to tell users why an estimation failed. Just returning `None` has a...

Could we perhaps use a nice sentinel value other than `None`? That should result in nice error messages like "\ has no attribute...". I would also provide a nice container...

> What would be the advantage over raising an error? As stated above, it's easier to handle. `try...except` forces users to lookup and match the correct exception. But perhaps still...

Another idea building on `FailedEstimation`: what do we think about patching the existing estimation classes in a way that they can represent the failed estimation? Basically you get a transform...

And after dealing a bit with the actual execution of this refactor in https://github.com/scikit-image/scikit-image/pull/7740, I'm not sure anymore that the current proposal is the right call. Mainly for 3 reasons:...

> I think the problem with the existing setup is that we have filters, as well as threshold calculations, and we don't distinguish clearly enough between them. Once we do,...

That I get. Is there another module we could put these in? E.g. could we consider thresholds a "feature" or a "metric"? Just checking that we have thought about this...

Chiming in is greatly appreciated! 😊 That said, we should probably avoid having non-unique names, even if they are located in different submodules. I feel like this could get confusing...

From the [Wikipedia article on thresholding](https://en.wikipedia.org/wiki/Thresholding_(image_processing)) > [...] thresholding is the simplest method of segmenting images. Which suggest that `skimage.segmentation` might be a good new home for these. I'll make...

> I'm aligned with all of Juan's comments Same. I'm not very familiar with the API yet. Happy to keep the convenience for people. > I think it's unnecessarily confusing...