search

jni / skan

Python module to analyse skeleton (thin object) images
https://skeleton-analysis.org
BSD 3-Clause "New" or "Revised" License
118 stars 39 forks source link

I think a simple network is better #43

Open yxdragon opened 7 years ago

yxdragon commented 7 years ago

Hi Jni: some advice:

  1. I try the csr and nx. they build all pixels as node. As a togpgraph, I think some times we do not care about the path coordinates. I think we can build network just based on junctions, and the length of the path be the distance value, then attach the path coordinates on. It will be faster and use less memory.

  2. the count mask should be uint8, that's enough to 2d/3d. when process a large stack 3d ndarrays, the memory is precious. and if build the network just based on junctions, the label mask should be uint16, 65536 is enough to label all junctions.

jni commented 7 years ago

Hi @yxdragon!

Thanks for checking it out, and for your feedback!

1) The junction graph can be built trivially from the branch statistics (output of csr.branch_statistics and csr.summarise), the columns node-id-0 and node-id-1 together represent an edge list. I think it would be far too much work to remove the intermediate step of the pixel skeleton, which anyway only takes up a fraction of the space of the original image.

2) "count mask", you mean degrees? Yes I think you are right, that would definitely work — you have to go up to a 6-dimensional volume before you exceed 255 possible neighbours! =P I'm less comfortable with setting the junction id maximum to 65536, because theoretically it could certainly be bigger, and it wouldn't require a particularly big volume. And at any rate I think it would add quite a bit of complexity to the code to make sure that the junctions are all the "low" labels, since the junction IDs and the path node IDs are in the same space.

Thanks for raising the issue, I'll definitely look into minimising the memory footprint! And additional tips are of course appreciated! =)