Difference between ImageJ local thickness and porespy local thickness

[DMaxJ]

I am doing some calculations on an image stack of size 400x400x744 (voxel). I am calculating local thickness in ImageJ. I have tried to do the same using porespy. The documentation mentions that the implementation is different from ImageJ. The results are also different. ImageJ produces maximum and mean sizes of 60 and 18 pixels. Porespy produces 28.4 and 9.4 respectively. Could you please explain from where and how the difference arises?

[jgostick]

The first thing is the our results are in radii, while imagej must be in diameter. Most of the difference vanishes after that. The end results should be pretty close, since both just draw large spheres in the image. I think imagej extracts the skeleton and inserts spheres at each point, while we use a more global approach based on the distance transform. I have not looked at the imagej function too closely though. BTW, how do they compare for speed? Would you mind reporting roughly what you get for each?

[DMaxJ]

Thank you very much for the prompt response. When the results are in radii, I get comparable results with both the tools. Now some update about performance

My system details are: i9 11950H @2.6 GHz with 8 cores and 16GB RAM

3D stack dimension 400x400x744
ImageJ: 20-22s

Porespy:
1 proc = 260-320 s
2 proc = 128-138 s
3 proc = 143 s
4 proc = 170 s

Porespy was run multiple times with default parameters except for "divs". It appears that for the file, the benefit of parallelization diminishes after n=2 as the communication cost increases.

[ma-sadeghi]

@DMaxJ That's right, div=2 means 2 divisions per axis, hence 8 chunks in total, and since you have 8 physical cores, it makes sense that further increase div just hurts performance. Actually, you might get slightly better performance by decreasing the number of divisions. Could you also try with div=[2,2,1], so it's only 4 chunks in total?

[DMaxJ]

I have checked. The best performance is for divs=2. But your answer has made one thing clear for me which I did not notice before. divs refers to the number of chunks that the file is divided into, right? I considered it to be the number of CPU cores. In that case 2 should be the best option with 8 cores. Higher number of chunks will be beneficial only with more processor cores.

[jgostick]

Hmmm, so imagej is quite a bit quicker. I'll make a mental note to investigate this in the future. Thanks for the help!

[ma-sadeghi]

@DMaxJ Yes, that's right. Maybe if you try on a larger image, you'll get better scaling, or maybe just our implementation is not 100% parallelizable.