Skip to content

Use max_size in remove_small_(holes|objects)#7739

Merged
mkcor merged 12 commits intoscikit-image:mainfrom
lagru:deprecate_area_threshold
Mar 17, 2025
Merged

Use max_size in remove_small_(holes|objects)#7739
mkcor merged 12 commits intoscikit-image:mainfrom
lagru:deprecate_area_threshold

Conversation

@lagru
Copy link
Copy Markdown
Member

@lagru lagru commented Mar 5, 2025

Description

Closes #4003.

In 0.16, in skimage.morphology.remove_small_holes, min_size has been replaced definitely by area_threshold. But for skimage.morphology.remove_small_objects, it is still min_size. This attempts to solve that inconsistency by using a more sensible max_size parameter for both. At the same time, this threshold is now inclusive, meaning objects equal to it will be removed as well.

Having dug through the past issues and discussions on this, it seems to me that each discussed option will be a trade-off between consistency and matching the context of each function.

Since remove_small_objects and remove_small_holes are so similar, I definitely give consistency more weight. Ignoring past deprecations, min_size seems to be the least controversial option. The main argument against it was that we'd have to revert a previous deprecation.

That's not ideal, but addressing previous mistakes is precisely what skimage2 is about. So, I propose to deprecate area_threshold in remove_small_holes back to min_size and only finalize the deprecation in 2.0.0.

I think we can keep using area_threshold in area_opening and area_closing, since area is a prominent term and I anticipate less user confusion.

#4003 (comment)

This comment got two thumbs up so I'm going with that suggestion.

Checklist

Release note

For maintainers and optionally contributors, please refer to the instructions on how to document this PR for the release notes.

In `skimage.morphology.remove_small_objects`, deprecate the `min_size` parameter
in favor of the new `max_size` parameter to make API and behavior clearer. This new
threshold removes objects smaller than **or equal to** its value, while the
previous parameter only removed smaller ones.
In `skimage.morphology.remove_small_holes`, deprecate the `area_threshold` parameter
in favor of the new `max_size` parameter to make API and behavior clearer. This new
threshold removes holes smaller than **or equal to** its value, while the
previous parameter only removed smaller ones.

In 0.16, in remove_small_holes, min_size has been replaced definitely
by area_threshold. But for remove_small_objects, it is still min_size.
This attempts to solve that inconsistency.

Having dug through the past issues and discussions on this, it seems to
me that each discussed option will be a trade-off between consistency
and matching the context of each function.

Since remove_small_objects and remove_small_holes are so similar, I
definitely give consistency more weight. Ignoring past deprecations,
min_size seems to be the least controversial option. The main argument
against it was that we'd have to revert a previous deprecation.

That's not ideal, but addressing previous mistakes is precisely what
skimage2 is about. So, I propose to deprecate area_threshold in
remove_small_holes back to min_size and only finalize the deprecation
in 2.0.0.

I think we can keep using area_threshold in area_opening and
area_closing, since area is a prominent term and I anticipate less user
confusion.
@lagru lagru added 🔽 Deprecation Involves deprecation 📜 type: API Involves API change(s) 🥾 Path to skimage2 A step towards the new "API 2.0" labels Mar 5, 2025
@lagru lagru added this to skimage2 Mar 5, 2025
@github-project-automation github-project-automation bot moved this to To Do in skimage2 Mar 5, 2025
@lagru lagru moved this from To Do to To Review in skimage2 Mar 5, 2025
@lagru lagru requested review from mkcor and stefanv March 5, 2025 11:14
@lagru lagru added this to the 0.26 milestone Mar 5, 2025
> From remove_small_holes(a, min_size=...), I don't think a user can
> figure out what min_size means, whereas
> remove_small_holes(a, max_size=...) reads pretty clearly as
> "remove small holes, but don't go beyond max_size".

– Stéfan
@lagru lagru changed the title Deprecate area_threshold in remove_small_holes Use max_size in remove_small_(holes|objects) Mar 7, 2025
Co-authored-by: Stefan van der Walt <github@mentat.za.net>
@lagru lagru requested a review from stefanv March 8, 2025 17:03
Copy link
Copy Markdown
Member

@mkcor mkcor left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll submit this for now, seeing that I'm supposed to refresh the page of changed files.

as a side effect, the existing argument "connectivity" can be made
keyword-only as well.
@lagru lagru force-pushed the deprecate_area_threshold branch from 2997be7 to 332e86c Compare March 11, 2025 15:49
Copy link
Copy Markdown
Member

@mkcor mkcor left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, @lagru!

I noticed there was a strange sentence under Notes for function remove_small_holes ("It is suggested that labeling is completed after using this function.") but this is probably being the scope of this PR. I'm happy to create an issue for this, so it doesn't fall in the cracks.

Co-authored-by: Marianne Corvellec <marianne.corvellec@ens-lyon.org>
@lagru lagru requested a review from mkcor March 11, 2025 22:00
lagru and others added 3 commits March 12, 2025 14:20
Co-authored-by: Stefan van der Walt <github@mentat.za.net>
Co-authored-by: Marianne Corvellec <marianne.corvellec@ens-lyon.org>
Co-authored-by: Stefan van der Walt <stefanv@berkeley.edu>
Copy link
Copy Markdown
Member

@mkcor mkcor left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Almost there!

Co-authored-by: Marianne Corvellec <marianne.corvellec@ens-lyon.org>
@lagru
Copy link
Copy Markdown
Member Author

lagru commented Mar 16, 2025

Thanks for catching the places were I forgot to decrement the max_size by one. I've found two more. Should be ready to go now. 🤞

@lagru lagru requested a review from mkcor March 16, 2025 13:36
Copy link
Copy Markdown
Member

@mkcor mkcor left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I found three leftovers!

Co-authored-by: Marianne Corvellec <marianne.corvellec@ens-lyon.org>
@lagru lagru force-pushed the deprecate_area_threshold branch from 1f616da to 41fd0d9 Compare March 17, 2025 14:38
Copy link
Copy Markdown
Member

@mkcor mkcor left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🎉

@mkcor mkcor merged commit 17cb184 into scikit-image:main Mar 17, 2025
23 checks passed
@github-project-automation github-project-automation bot moved this from To Review to Done in skimage2 Mar 17, 2025
@lagru lagru deleted the deprecate_area_threshold branch March 17, 2025 15:06
lagru added a commit that referenced this pull request Jan 14, 2026
…s deprecation (#8003)

Fixes #8001

The renaming of `min_size`/`area_threshold` to `max_size` in #7739 was actually
accompanied by a change in behaviour for the same value, due to using
`>` in the old nomenclature and `>=` in the new one.

Unfortunately our deprecation machinery was until now not smart enough
to know whether a renamed parameter was provided under its old name or
its new name. To address this, this PR:

- Updates the deprecation machinery to detect when a parameter was given
with the old name/position, and
- Uses this updated machinery to modify `min_size`/`area_threshold` by 1
to ensure that the new behaviour matches the old one.

Co-authored-by: Jeremy Muhlich <jmuhlich@bitflood.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

🔽 Deprecation Involves deprecation 🥾 Path to skimage2 A step towards the new "API 2.0" 📜 type: API Involves API change(s)

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

API inconsistency between remove_small_holes and remove_small_objects

3 participants