-
Notifications
You must be signed in to change notification settings - Fork 532
FIX+ENH: refactor area weighted surface distance + fields operations #1016
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
Conversation
oesteban
commented
Jan 13, 2015
- Fix area-weighted path
- Refactor former code to be more robust (now using numpy when possible)
- Add zero-distance regression test
- Add translation-distance regression tests
- Add area-weighting regression tests
This PR is ready for code-review :) |
|
||
.. warning: | ||
|
||
A point-to-point correspondence between surfaces is required |
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 if these two files are spheres? is there a way to weight them differently, for example with curvature information or some such?
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.
You're right, I did not observe that detail, but I could add a new weighting keyword that reads the vertex-wise properties of the vtk file, and definitely curvature may be a potential weight. I'll look at this ASAP.
also as a side note, i wanted to write compy (a python computational geometry library) a while back that would allow us to do such operations easily (perhaps with vtk this is not longer necessary, or something already exists that i haven't followed), i implemented a set of computational geometry algorithms (on triangular meshes) a long while back in matlab. they should be relatively straightforward to convert to python + cython. https://github.com/satra/SLT/tree/master/SurfTools if you are interested we can start compy (if no such other library exists) and chip away at this. |
Hi @satra, I definitely agree on that computational geometry algorithms would be much better developed and maintained as a package different from nipype. The algorithms you had implemented in matlab look as a good starting point, but also we could benefit a lot from vtk. From this side, everythings looks good to me in favor of compy. However, I am currently struggling to finish up my PhD. For now, I can only contribute with stuff I really need for the results of my thesis... Thus, compy would start with a very particular and limited choice of algorithms from my side. What do you think? |
Conflicts: CHANGES