add int64 support to filters.rank_order and morphology.reconstruction#6342
Merged
alexdesiqueira merged 11 commits intoscikit-image:mainfrom Jun 14, 2022
Merged
add int64 support to filters.rank_order and morphology.reconstruction#6342alexdesiqueira merged 11 commits intoscikit-image:mainfrom
filters.rank_order and morphology.reconstruction#6342alexdesiqueira merged 11 commits intoscikit-image:mainfrom
Conversation
implement an int64 variant as well
expand data type tests also use minimum necessary integer dtype in skimage.filters.rank_order
will remove the Pythran code in a future commit Co-authored-by: James Sample <james.e.sample@gmail.com>
Contributor
|
@grlee77 I think the issue is that pythran cannot prove that array accesses are inbound. I'll investigate that :-) |
Contributor
|
This looks fantastic @grlee77 ! Thanks for your help with this! Especially for the stuff involving fused types in Cython - it's great to have a version that chooses the most appropriate type automatically. |
Member
|
Thank you @grlee77 @JamesSample! |
4 tasks
jmuhlich
added a commit
to jmuhlich/scikit-image
that referenced
this pull request
Nov 10, 2025
While scikit-image#6342 added code to support passing int64 arrays to reconstruction_loop, the local variables that hold values from these arrays are still 32-bit. This change uses the appropriate fused int types instead.
stefanv
pushed a commit
that referenced
this pull request
Nov 10, 2025
I was experiencing segfaults in the reconstruction_loop cython code when reconstruction was called with very large images, even after #6342 added code to support passing int64 arrays. I discovered that the local variables that hold the values from these arrays are still 32-bit. This change uses the appropriate fused int types instead. --------- Co-authored-by: Lars Grüter <lagru@mailbox.org>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
7 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
closes #6277
This PR resumes work from #6295, using fused types to support both 32 and 64-bit integer types in
morphology.reconstructionandfilters.rank_order. This allows extremely large images to be used with these functions.Additional changes:
skimage.filters.rank_ordernow uses the minimum required unsigned integer size rather than always using uint32seednow returns single precision output (this function was missed during previous float32 work)Performance remains approximately the same as before. Memory usage is now a bit less for float32 inputs.
Pythran version
In the earlier commits, I tried converting to Pythran, but measured 5-10x slower performance in that case for the larger sizes in the benchmarks. @serge-sans-paille, if you are interested in taking a look see commit d5295bc which has both Cython and pythran versions present (which one is called can be chosen by editing the import at the top of grayreconstruct.py). The pythran code is a bit cleaner (no cdefs required), but it is not obvious to me where the performance difference comes from.
Checklist
./doc/examples(new features only)./benchmarks, if your changes aren't covered by anexisting benchmark
For reviewers
later.
__init__.py.doc/release/release_dev.rst.example, to backport to v0.19.x after merging, add the following in a PR
comment:
@meeseeksdev backport to v0.19.xrun-benchmarklabel. To rerun, the labelcan be removed and then added again. The benchmark output can be checked in
the "Actions" tab.