Morphology: possibility of prune improvement

[karnoldbio]

Description

i have been testing out the morphology functions and i was wondering if there might be other ways to implement a prune function. it is useful but i often find myself segmenting my skeletons by accident. rather than trimming off a designated amount of pixels from every end segment, there are two methods that may work better: 1) trimming the segment of a specific ID

2)trimming all segments shorter than X pixels

Details

i think this would greatly help in the ease of use of the function and would help in adding it to more high throughput scenarios with slightly more accuracy

Completion Criteria

• [ ] Discuss possibility / feasibility for prune improvement / adding more prune functions
• [ ] Create issues for next steps

[HaleySchuhl]

Hello @karnoldbio ,

I think this is a good suggestion! I hadn't considered doing segmentation before pruning but I think the method of trimming all segments shorter than size pixels would be really useful. This would likely make the function slower but it's already a pretty computationally expensive function. We had been trying to think of a way to avoid pruning off true leaf tips (especially since they are influential in some cases in measurements such as segment_curvature and segment_tangent_angle) and this would be a great option to offer to users.

[karnoldbio]

Yes prune is currently a fairly expensive function, as for every pixel you want to remove you need scan for leaf tips, and then remove those tips, then re-scan and repeat for every pixel you are removing.

however if removing_segment_shorter_than_size function is called after segmentation, we could possibly use the list of objects it produces to create a subtraction image consisting of all undesired segments and remove an entire segment(s) at a time. i hope this would provide a small speed up as it should remove the need to repeatedly iterate through pixels, but it is hard to say until implementation is started.

Now this is still a high level idea and i understand that it will be much more complicated than my initial description to implement, that you likely have other more pressing issues to implement/fix, and that there a lot of complications and issues that could arise when trying to implement it i.e. in my initial understanding whether or not the list of pixel positions for each segment includes the branch point from which it originated unclear and we would need to be careful that is not removed. Please take your time and let me know if there is any way i can help / clarify.

[HaleySchuhl]

Upon starting on this enhanced function this morning, I think it will be best to remove short segments after sorting. There are cases where primary segments (stem) are shorter than the barbs I am to prune off. Maybe the function can call the sorting function so users don't have to run pcv.morphology.sort_segments before and after pruning.

Right now I think I'll add a method argument to the function, rather than making a new one, that allows users to pick whether they want to prune by iteratively removing tips or if they'd like to prune by removing segments.

I expect to have this done this week. Thanks again for the suggestion @karnoldbio !

[HaleySchuhl]

After writing the new function I'm wondering if it would be beneficial to combine pcv.morphology.segment_skeleton and pcv.morphology.prune into a single function. In order to just perform a segmentation step the user could always provide size=0 (maybe this ought to be a default?).

[karnoldbio]

i think that is a great idea. if the new pcv.morphology.prune is going the need that, there is no need to call pcv.morphology.segment_skeleton twice. it also becomes slightly easier to iteratively find the best size needed for pruning, making it a one step process rather than two.