Created attachment 141
Files to illustrate bug

The number of slab voxels reported by the table popped up by the AnalyzeSkeleton plugin is not the same as the number of slab voxels in the actual skeleton.

As an example, I've analyzed the skeleton of the sample 121x154x114 3D image of a bat cochlea included with Fiji. The table from AnalyzeSkeleton (saved as bat-cochlea-results.txt in the attached tarball) indicates that the number of end point voxels is 31, the number of junction voxels is 49, and the number of slab voxels is 533.

The AnalyzeSkeleton plugin also generates a tagged skeleton (i.e., one where the voxels are colored according to what type they are), which I saved as "bat-cochlea-tagged-skeleton.raw" in the attached tarball and translated to a newline-separated list of ASCII values, "bat-cochlea-tagged-skeleton.dat", using the Python script "readRaw8bit.py", also in the tarball. The results of runnning "sort bat-cochlea-tagged-skeleton.dat | uniq -c > bat-cochlea-pixel-val-counts.dat" is as follows:

2123631 0
    565 127
     31 30
     49 70

So in the tagged skeleton there are 31 end-point voxels (labeled with voxel value 30) and 49 junction voxels (labeled with voxel value 70) -- just as there should be -- but the number of slab voxels (labeled with voxel value 127) is *565*, greater than the value of slab voxels given in the table produced by the plugin.

I've had other skeletons where the number of slab voxels reported in AnalyzeSkeleton's table is about *half* that of the number of actual slab voxels, so it's not like the number of slab voxels in the table is always only slightly estimated.