8000 [WIP] Add distance transform function by leGIT-bot · Pull Request #4051 · scikit-image/scikit-image · GitHub
[go: up one dir, main page]

Skip to content

[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

Open
wants to merge 57 commits into
base: main
Choose a base branch
from

Conversation

leGIT-bot
Copy link
Contributor
@leGIT-bot leGIT-bot commented Jul 24, 2019

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


peakmem_reference                                         172M
peakmem_scipy_2d                                          312M
peakmem_skimage_2d                                     256M
time_scipy_2d                                                   814±0ms
time_skimage_2d                                              925±0ms


peakmem_reference                                         2.9G
peakmem_scipy_3d                                           7.73G
peakmem_skimage_3d                                      9.31G
time_scipy_3d                                                    1.68±0m
time_skimage_3d                                               54.6±0s

Checklist

For reviewers

  • Check that the PR title is short, concise, and will make sense 1 year
    later.
  • Check that new functions are imported in corresponding __init__.py.
  • Check that new features, API changes, and deprecations are mentioned in
    doc/release/release_dev.rst.
  • Consider backporting the PR with @meeseeksdev backport to v0.14.x

8000
out = INFINITY
return out

cdef double manhattan_dist(Py_ssize_t a, double b, double c) nogil:
Copy link
Member

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

Copy link
Contributor Author

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

Copy link
Contributor Author

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,
Copy link
Member

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

Copy link
Contributor Author
@leGIT-bot leGIT-bot Jul 29, 2019

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

Copy link
Contributor Author

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

Copy link
Member

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.

Copy link
Contributor Author

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

Copy link
Member

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?

Copy link
Contributor Author

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

Copy link
Member

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.

Copy link
Contributor Author

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

@hmaarrfk
Copy link
Member

@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.

@leGIT-bot
Copy link
Contributor Author
leGIT-bot commented Jul 29, 2019

@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
thanks for the help with the gil

@SebastienEske
Copy link

Hello, just a little comment: does it produce the same (rotated) output if the image is rotated? With this for example?
input

It's worth testing by rotation increments of 5 degree between 0 and 90 degrees.

I know opencv's distance transform has this issue. So even if this algorithm has it, you can just mention it as a limitation.

@sciunto sciunto removed this from the 0.17 milestone Apr 8, 2020
Base automatically changed from master to main February 18, 2021 18:23
@imagesc-bot
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants
0