-
-
Notifications
You must be signed in to change notification settings - Fork 2.2k
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
Phase unwrapping: Branch cut algorithm #680
base: main
Are you sure you want to change the base?
Conversation
@josteinbf Sorry for the delay. I am not sure if we really need a separate queue implementation. Is it performance critical (if not, we could use PyList)? Otherwise the queue implementation should be moved to skimage/_shared. Apart from that the implementation looks very good! |
@ahojnnes Thanks for looking into this, and thanks for your complements on the implementation. Performance-wise I guess it should be good enough, but I'm worried about readability. How does readability look to someone who did not code it? Do you feel you need to struggle to understand what's going on? With regards to the queue, it is used rather intensively, but I have not really researched the options here much---I just figured any basic BSD-licensed C implementation would do. The average number of items in the queue is probably proportional to the number of pixels in the image (the proportionality constant is likely highly dependent on the input, but it could in bad cases get close to one), and items are enqueued and dequeued at a high frequency (all pixels enter the queue at least twice). By PyList, do you mean a python list, just accessed from C? I have no idea how efficient that is, never used something like that before. In summary, I'd very much appreciate advise on the queue implementation :) As this implementation only deals with 2D images the memory overhead of the queue is not critical, but using more memory for the queue could hurt performance through more fetches/stores (the number of flops per queue item is small). |
skimage/exposure/unwrap.py
Outdated
|
||
|
||
def find_branch_cuts(residues): | ||
'''Connect residues with branch cuts such that the length of the cuts |
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-liner as a short description.
@josteinbf Let's keep the current queue implementation, but move it to skimage/_shared. Maybe we can also wrap it into a nice class, e.g. http://docs.cython.org/src/tutorial/clibraries.html ? |
Here's one description of the allocation pattern: http://www.laurentluce.com/posts/python-list-implementation/ |
from libc.math cimport M_PI | ||
|
||
|
||
def unwrap_naive_1d(double[::1] image, double[::1] unwrapped_image): |
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.
double[::1] => double[:]
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.
Can you please explain the difference? I thought double[::1] would assume a C-ordered array (not patched together by memory chunks scattered in different places, but one continuous allocation), and allow cython to deal with this more efficiently?
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.
Sorry, you are right, of course. Disregard my suggestion ;-)
@ahojnnes Thanks for your comments. This week is too busy for me to respond properly to this, but I hope to get to it next week. |
@ahojnnes The queue OO wrapper is done now and in shared. It does indeed look a lot better, good suggestion. One question: I have assumed that cython will deallocate the queue for me when the |
@stefanv Thanks for the link on allocation patterns. The contents convince me that PyList is not an option for this code, since |
@ahojnnes I think I have addressed all of your comments now. Where I have not answered to your comment, I have just implemented your suggestion. There are a few questions for you that I hope you can answer above. |
I'm in the process of rebasing this, which will require a fair few changes, since there is a substantial overlap with #644, which was just merged. Some decisions need to be made; I plan to do the following:
Comments welcome. |
@josteinbf This sounds like a perfect plan to me! Maybe you can combine both examples into one script comparing the methods side-by-side? |
I'll have a look at what the differences between the methods really are. However, I fear that since we have only relatively unrealistic example data, we will not be able to demonstrate how the methods are different. If we want to do that, we would probably have to include an extra image. Would that be possible? It would of course increase the size of the distribution. |
What kind of images do you have and what size are they? |
The C code comes from the C-algorithms library: http://c-algorithms.sourceforge.net/ We provide the cython wrapper class developed as part of a Cython tutorial: http://docs.cython.org/src/tutorial/clibraries.html
@ahojnnes Rebased. Is there an easy way I can view a test coverage report from this fancy coverall thing? With the modified API, I'm certain there are some untested lines lying around relating to the |
@ahojnnes Regarding comparisons in the example: I think we should do that in a separate PR (if we should do it at all---the papers cited will certainly have information on this). This one's big enough already. |
A single doctest is failing, and I'm having trouble seeing what the problem is:
I can only see a single difference, the |
A bit of googling turned up the solution to the blank line issue. I expect tests to pass now. |
c86aae2 should have failing tests. These tests may mean that the branch cuts implementation has a bug related to handling masked regions---I don't know yet. Until I know, please don't merge. |
This PR's birthday is almost here! |
Hi. Myself, @darrenbatey and @pierrethibault are currently looking at phase unwrapping, and possibly extending this functionality in scikit-image. What's the state of this PR? If we were to update it so that the files are in the right place, what's left to do to get the PR through? Aaron |
@aaron-parsons That's excellent news; a thorough review at this point would be most welcome and helpful, especially given that the PR has been dormant since 2014. Thank you! |
My other PR on phase unwrapping, #644, is stalled (copyright issues), but I've had another implementation lying around for a while which is perfectly safe to include.
This PR implements the branch cut algorithm. Anyone wanting to review this in detail is encouraged to have a look at Goldstein's classic paper on phase unwrapping[1] before diving in; I've implemented the same algorithm with some slight modifications, mostly to allow treating masked arrays properly.
Functionality, tests, docs and examples should be about complete. I lack a test case for masked array input---ideas for good test cases welcome!
[1] R. M. Goldstein, H. A. Zebker, C. L. Werner, "Satellite radar
interferometry: Two-dimensional phase unwrapping", Radio Science 23
(1988) 4, pp 713--720.