-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[ENH] add strided tiles #202
Comments
I think the most transparent way would be to simply leave all (overlapping) tiles in the csv and let the user (or consumer, e.g. the qupath extension) decide how to handle them. Doing things like averaging could work for simple binary models, but it might not do what the user expects in multiclass classification tasks and in edge cases (such as edge tiles :) ). However I might be mistaken and averaging might be the most convenient choice. I'm interested in other opinions and will be following this thread. Thanks for the ping! p.s. doing inference on strided tiles might open up room for performance improvements (model architecture-dependent). But it's best if we discuss these later. |
the step size in these lines would have to be updated to support strided patches. i think we could add an argument to this function like in the case of 0 overlap (default), the step size would be the wsinfer/wsinfer/patchlib/patch.py Lines 157 to 164 in 0b1208c
|
fixes #202 This adds a command line option '--patch-overlap-ratio' that controls the level of overlap between adjacent patches. Negative values create space between patches, and values closer to 1 makes patches overlap more.
@xalexalex - strided patches are implemented now! please see #218 for examples of output. the main change is the addition of the in the case of 10% overlap... let's say the patches are 100 um by 100 um. 10% overlap in this case means that each patch would overlap with the next patch by 10 um. a negative value for here's an example of a command line call that skips every other patch.
please let me know what you think! |
add inference on overlapping patches. this can smooth outputs and could be more informative.
we will need to resolve how to save these outputs. at the moment, each row of the output CSVs holds one patch. we could simply include all of the patches, despite overlapping. or we could do some post-processing of the outputs, where we merge patch outputs and recover non-overlapping patches. i'm not sure yet.
i would appreciate any thoughts on how the outputs should be structured
cc: @xalexalex
related to qupath/qupath-extension-wsinfer#46
The text was updated successfully, but these errors were encountered: