3D Object Counter versus Particle Analyser

Tags: #<Tag:0x00007fb884bf31e8>


Hi all,

I have recently used both 3D Object Counter and Particle Analyser (from BoneJ) for analyzing the morphology of colloids in a porous medium.

What are the differences in the algorithms that would cause differences for similar characteristics? Is there a preferred plugin for this type of analysis?

Any advice would help. Thanks!


It’s been a while (years) since I looked at 3D OC’s code, when I did some work to speed it up for BoneJ that ended up unfortunately forking it (it would be great to merge features back together into some Ops for ImageJ2, but that is another story for another day). The primary difference in the labelling is speed: the result of connected components labelling should be identical. BoneJ achieves labelling with ~O(n) scaling, which means it doesn’t exponentially slow down like the original 3D OC did as you feed it bigger data sets. However, I don’t know how 3D OC performs today.

As for analysis, BoneJ is set up for porous media of which bone is one example - the analysis tools that are there are designed with things like bone’s trabeculae and osteocyte lacunae in mind, which have geometric parallels in other fields. There are quite a number of soil papers and other materials science papers that have used BoneJ for this reason. If you can be more specific about the characteristics you’re interested in, we can guide you towards the most appropriate measurements and discuss implementation differences that might lead to variation in results. Perhaps the most useful thing you could do is run 3D OC and Particle Analyser on the same data and point out any inconsistencies to us here.


Thank you very much for the informed response.

The quality of images used in our analysis is similar to the fields mentioned above (bone trabeculae, etc.) in that the image data was acquired through tomography.

We processed multiple sets of data with both 3D OC and Particle Analyser. We found that the identification system of particles is the same (or could be easily adjusted to match). We also found that the volume values are the same. However, the largest discrepancy is between the calculation of the surface area values.

Our data includes particles in amorphous clusters ranging from 1 voxel to 1000s of voxels. Surface area of a 1 voxel particle in 3D OC is given a value of 6, whereas Particle Analyser gives a value of 0 for the same voxel. I understand the Particle Analyser derives the surface area value based on a surface mesh that is created from the voxels. Having looked at the data from Particle Analyser, we saw clusters of upwards to 50 voxels with surface area values of 0. We assume that this value was because the lack of a surface mesh created due to the arrangement of voxels. Further we saw a convergence between surface area values from 3D OC and Particle Analyser at larger volumes, and a divergence between values at lower volumes.

What are the types of arrangements and the minimum number of voxels to warrant a surface mesh, and further a value for surface area, in Particle Analyser?


Thanks for looking into it and reporting back, that’s very helpful.

That’s correct. The main thing that you can change for Particle Analyser to give a non-0 result is the mesh smoothing. It’s likely that your fine and small particles are getting smoothed to oblivion so then no mesh gets fitted and you get a 0 surface area. You can try reducing the Surface resampling value in the setup dialog.

If I remember it correctly, 3D OC calculates surface area based on finding surface pixels, modelling them as little cubes then adding up the exposed faces of the cubes.

Whether a single pixel has any surface area at all, and if so what it should be, is a matter of some debate that turns up here and on the old email list from time to time. If you consider a pixel as a ‘little cube’, which some consider a kind of heresy against digital imaging, then 1 pixel has 6 × 1 px^2 surface area. But, if you consider it as an infinitesimal point in space that represents a kind of fuzzy blob domain in the imaged object (the MTF, limited by instrument resolution), you might model its surface differently e.g. as a sphere with d = 1, so area = 4π(d/2)^2 = π px^2 (or as something else entirely - surface area of an Airy function, anyone?)

The above analysis suggests that you ought to be very careful indeed (by which I mean, consider not doing it) about trying to measure lengths, areas and volumes when pixel spacing approaches feature size. It’s like trying to measure peas with a ruler that has 1cm hatch marks. This is Mandelbrot’s “Coast of Britain” problem taken to the extreme of a very large ruler.

I’m curious to know whether you noticed a speed difference between BoneJ and 3D OC, and how big and complex your images are (numbers of pixels and numbers of particles).