On Thu, Oct 13, 2011 at 6:45 AM, Neil Yager email@example.com wrote:
I really like the looks of this project and I'm hoping to add a few things. However, I've never contributed to open source before, so I'll definitely need some guidance along the way.
Welcome! We look forward to your contributions.
I've written some code to perform thinning on binary objects (i.e. skeletonization). I've created a file that contains the logic, another file with an example of usage, and one for unit tests.
It would be very interesting to compare what you've done with the skeletonization code already in progress. We tried to merge it just before the release, but since it was part of another, massive patch, it didn't make it. Have a look here:
- Which package is best for this function? I've put it in the
'morphology' package, but I'm not sure it really belongs there because I don't use any morphological operations. (note: this implementation should be significantly faster than a morphology-based approach)
We had the other patch in morphology too, so that's probably as good a place as any.
- Unit test: I've written a few tests checking IO, but I can't see
how to write tests to check if it is creating the "correct" skeleton, because there isn't really a "correct" skeleton. There's lots of thinning algorithms out there, and they often give different results (e.g. the medial axis transform gives different skeletons than this implementation). How does one write useful unit tests in these cases?
In this case, it's quite reasonable to construct a test case, thin it with your algorithm, and inspect the result to ensure that it is correct. You then store that result (e.g. in a .npz or .png file), and use it in the comparison.
- github: I've never used git before, and I'm still getting used to
the terminology. What is the best way for someone to review my code? I've now pushed it to a branch (neil_yager-skeletonize) in my repo (NeilYager). If you were to test it out, would you fork it or pull it?
You previously made a successful pull request against the main repository--that's exactly the right way to go. We review the pull requests on GitHub, and leave comments inline.
I'm thinking about doing a thresholding algorithm next, followed by perhaps gabor filters or gray-level co-occurance matrices (if no one is already working on these).
I've got some old grey-level c.o.m. code here, if you want to have a look:
Adaptive / auto-thresholding should be fun!