-
-
Notifications
You must be signed in to change notification settings - Fork 2.3k
[WIP] Add distance transform function #4051
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
base: main
Are you sure you want to change the base?
Conversation
add a modified version of numpy.applyalongaxis as well as a simple test; optional variables can only be set to defult value for now until an input method is decided upon
remove debug warnings
Make the 1D optional inputs compulsary since it will be inaccessible. It works by converting the 1D function to a patial function with the optional upper function inputs filled
Split 1d func into three for speed. Moved auxilary funcs into cython
out = INFINITY | ||
return out | ||
|
||
cdef double manhattan_dist(Py_ssize_t a, double b, double c) nogil: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why is b
a double here, while in other cases it is Py_ssize_t
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
mahattan meet is used by manhattan_dist which can pass an inf value which is a double
There was a problem hiding this comment.
Choose a reason for hiding this comment
8000 The reason will be displayed to describe this comment to others. Learn more.
euclidean meet does not use euclidean dist
out[i] = euclidean_dist(i,centers[current_domain],cost_arr[<Py_ssize_t>centers[current_domain]]) | ||
return out | ||
|
||
def _generalized_distance_transform_1d_manhattan(double[:] arr, double[:] cost_arr, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this the same as the code above? maybe look at
https://github.com/scikit-image/scikit-image/blob/master/skimage/transform/_warps_cy.pyx#L156
to see how you can combine the two codes
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
one of the manhattan functions has a different signature
other than that the code is the same
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the code used to be different though
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the code used to be different though
funny how that evolves.
Well, I might just do all the meet and distance computation in floats and call it a day. Your benchmarks might be able to show you that it makes no difference.
Generally, when things are the same, they are easier to maintain.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
changed it, did the benchmarking and checked
it does make a difference
from mid 40s to about a minute
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
no. unless you want to write it for arm, ppc64le, arm32bit, arm64bit, x86, x86 64bit
but I admire the enthusiasm.
What would you like to optimize?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought that euclidean_dist, euclidean_meet... are very short and called often
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What does the Cython look like? The generated C that is?
Vectorization might be better than you think. You might want to try numba or pythran.
This comment was marked as off-topic.
This comment was marked as off-topic.
Sorry, something went wrong.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think first cython needs to be merged and then worry about whether others are more efficient
@leGIT-bot i don't want you to do busy work, so I think the big thing that is left to figure out is why your code doesn't perform well small image size case. You can parametrize your benchamrk (which I recommend) and start profiling your code. I think you got the GIL release right. so for now, I don't think I can help on that front anymore. |
it uses a different algorithm and C |
This pull request has been mentioned on Image.sc Forum. There might be relevant details there: https://forum.image.sc/t/expanding-cell-label-boundaries-adaptively/60131/6 |
Description
New distance transform function
#904
http://www.cs.cornell.edu/~dph/papers/dt.pdf
pull request was recreated due to an 'unknown repository' problem
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
.@meeseeksdev backport to v0.14.x