Object Counter 3D

[Thomas Elliot]

Greetings.

In using the Object Counter 3D (or the original 3D Object Counter), we  
noted that the surface area reported is often the same value as the  
volume.  Which is an impossibility.

To examine this, I created a 5x5x5 voxel image with the central voxel  
(at 3,3,3) being a single value of 255 and the remaining 124 voxels  
set to 0.  The results from the plugin operation were:
Volume = 1
Surface Area = 1

In comparison, I inverted the very same stack, ran the plugin again  
and received:
Volume = 123
Surface Area = 56.

Now, you would expect that for the inverse the Volume would be 124,  
and the Surface Area = 156 (25 surfaces per side of the cube x 6 sides  
+ 6 sides of the internal 'particle' at the center), or at the very  
least it could identify that there were 104 voxels acting as direct  
'surface' volume elements [(9 voxels per side x 6 sides) + (44 voxels  
as external edges of image cube) + 6 internal) with the remaining  
surface area (of the 156) being accounted for by counting multiple  
faces of singular voxels.

What we do have is 56 surface area, which I am assuming is derived  
from the 25 voxels at Z+ (Slice 1) and 25 voxels at Z- (Slice 5), with  
the 6 internal voxels.

There is no universal 'scaling factor' that can be used on both  
scenarios (i.e. if the first scenario of the singular voxel is to  
attain the actual surface area, it would have to be multiplied by 6,  
which when applied to the second scenario results in an unreasonable  
surface area for the structure) and apparently medial and axial edges  
of the image are not accounted for in the plugin.

I am having doubts as to the validity of this plugin and would like  
someone to verify that data acquired and published (fortunately I have  
not made that plunge yet) using this plugin is not erroneous.

Regards,

Tom Elliot

[Fabrice Cordelières]

Dear Thomas,

As I am the one who "committed" this plugin, I will briefly answer your
questioning.
3D object counter is grouping object pixels into particles by looking at one
pixel's 8 neighbors in 2D and 26 neighbors in 3D. Doing so it will label all
particles and return as "volume" the number of pixels/voxels forming each
particle, and as "surface" the number of pixels/voxels lacking at least one
of its neighbors. The way one pixel is "lacking neighbors" might vary in
many ways (for example, one surface along xy plane or one surface along xz
plane may not result in the same surface, as you've mentioned).  This is
obviously not a true measure of the surface therefore I will change the
denomination of this line within the table of results so that no one could
be mistaken. I'm currently working on an updated version of the plugin and
will take your comment into account.

Fabrice




Fabrice Cordelières, PhD
 
Institut Curie - Section de recherche/ CNRS UMR 146
Plateforme d'Imagerie Cellulaire et Tissulaire
Bâtiment 112 - Centre universitaire
91405 Orsay Cedex
FRANCE
 
Tél. : [phone]
Fax. : [phone]

Consultez mes disponibilités sur
http://www.google.com/calendar/embed?src=fabrice.cordelieres%40gmail.com

-----Message d'origine-----
De : ImageJ Interest Group [mailto:[hidden email]] De la part de Thomas
Elliot
Envoyé : vendredi 2 novembre 2007 13:16
À : [hidden email]
Objet : Object Counter 3D

Greetings.

In using the Object Counter 3D (or the original 3D Object Counter), we  
noted that the surface area reported is often the same value as the  
volume.  Which is an impossibility.

To examine this, I created a 5x5x5 voxel image with the central voxel  
(at 3,3,3) being a single value of 255 and the remaining 124 voxels  
set to 0.  The results from the plugin operation were:
Volume = 1
Surface Area = 1

In comparison, I inverted the very same stack, ran the plugin again  
and received:
Volume = 123
Surface Area = 56.

Now, you would expect that for the inverse the Volume would be 124,  
and the Surface Area = 156 (25 surfaces per side of the cube x 6 sides  
+ 6 sides of the internal 'particle' at the center), or at the very  
least it could identify that there were 104 voxels acting as direct  
'surface' volume elements [(9 voxels per side x 6 sides) + (44 voxels  
as external edges of image cube) + 6 internal) with the remaining  
surface area (of the 156) being accounted for by counting multiple  
faces of singular voxels.

What we do have is 56 surface area, which I am assuming is derived  
from the 25 voxels at Z+ (Slice 1) and 25 voxels at Z- (Slice 5), with  
the 6 internal voxels.

There is no universal 'scaling factor' that can be used on both  
scenarios (i.e. if the first scenario of the singular voxel is to  
attain the actual surface area, it would have to be multiplied by 6,  
which when applied to the second scenario results in an unreasonable  
surface area for the structure) and apparently medial and axial edges  
of the image are not accounted for in the plugin.

I am having doubts as to the validity of this plugin and would like  
someone to verify that data acquired and published (fortunately I have  
not made that plunge yet) using this plugin is not erroneous.

Regards,

Tom Elliot

[Thomas Elliot]

Fabrice,

Thank you for the clarification.  It is the case in material sciences  
that the surface area to volume ratio of objects, particularly  
conductive objects, is of primary relevance.  As it turns out, the  
Object Counter 3D plugin on first glance was exactly what was needed  
for further analysis of 3D objects in a matrix.  Our mistaken missive  
of the 'surface area' values did, however, restrict the applicability  
and as a result we have gone forward with an alternative method.

Particularly, I was wondering if you had considered implementing a  
Hoshen-Kopelman algorithm for determining 3D connectivity of particles  
and the resulting 'true' surface area of each particle.

Regards,

Tom Elliot
PhD Candidate
Land Resource Science
University of Guelph



Quoting Fabrice Cordelières <[hidden email]>:

> Dear Thomas,
>
> As I am the one who "committed" this plugin, I will briefly answer your
> questioning.
> 3D object counter is grouping object pixels into particles by looking at one
> pixel's 8 neighbors in 2D and 26 neighbors in 3D. Doing so it will label all
> particles and return as "volume" the number of pixels/voxels forming each
> particle, and as "surface" the number of pixels/voxels lacking at least one
> of its neighbors. The way one pixel is "lacking neighbors" might vary in
> many ways (for example, one surface along xy plane or one surface along xz
> plane may not result in the same surface, as you've mentioned).  This is
> obviously not a true measure of the surface therefore I will change the
> denomination of this line within the table of results so that no one could
> be mistaken. I'm currently working on an updated version of the plugin and
> will take your comment into account.
>
> Fabrice
>
>
>
>
> Fabrice Cordelières, PhD
>  Institut Curie - Section de recherche/ CNRS UMR 146
> Plateforme d'Imagerie Cellulaire et Tissulaire
> Bâtiment 112 - Centre universitaire
> 91405 Orsay Cedex
> FRANCE
>  Tél. : [phone]
> Fax. : [phone]
>
> Consultez mes disponibilités sur
> http://www.google.com/calendar/embed?src=fabrice.cordelieres%40gmail.com
>
> -----Message d'origine-----
> De : ImageJ Interest Group [mailto:[hidden email]] De la part de Thomas
> Elliot
> Envoyé : vendredi 2 novembre 2007 13:16
> À : [hidden email]
> Objet : Object Counter 3D
>
> Greetings.
>
> In using the Object Counter 3D (or the original 3D Object Counter), we
> noted that the surface area reported is often the same value as the
> volume.  Which is an impossibility.
>
> To examine this, I created a 5x5x5 voxel image with the central voxel
> (at 3,3,3) being a single value of 255 and the remaining 124 voxels
> set to 0.  The results from the plugin operation were:
> Volume = 1
> Surface Area = 1
>
> In comparison, I inverted the very same stack, ran the plugin again
> and received:
> Volume = 123
> Surface Area = 56.
>
> Now, you would expect that for the inverse the Volume would be 124,
> and the Surface Area = 156 (25 surfaces per side of the cube x 6 sides
> + 6 sides of the internal 'particle' at the center), or at the very
> least it could identify that there were 104 voxels acting as direct
> 'surface' volume elements [(9 voxels per side x 6 sides) + (44 voxels
> as external edges of image cube) + 6 internal) with the remaining
> surface area (of the 156) being accounted for by counting multiple
> faces of singular voxels.
>
> What we do have is 56 surface area, which I am assuming is derived
> from the 25 voxels at Z+ (Slice 1) and 25 voxels at Z- (Slice 5), with
> the 6 internal voxels.
>
> There is no universal 'scaling factor' that can be used on both
> scenarios (i.e. if the first scenario of the singular voxel is to
> attain the actual surface area, it would have to be multiplied by 6,
> which when applied to the second scenario results in an unreasonable
> surface area for the structure) and apparently medial and axial edges
> of the image are not accounted for in the plugin.
>
> I am having doubts as to the validity of this plugin and would like
> someone to verify that data acquired and published (fortunately I have
> not made that plunge yet) using this plugin is not erroneous.
>
> Regards,
>
> Tom Elliot
>

[Fabrice Cordelières]

Tom,
I have not considered yet such an algorithm but as I'm modifying/upgrading
the plugin, I would be happy if you could send me off-list some references
about it: in case it is not highly complicated to implement, I could give it
a try. In the meantime, I'll do a google search on that.
Thanks for your comments,

Fabrice

On Fri, 2 Nov 2007 11:10:57 -0400, Thomas Elliot wrote

> Fabrice,
>
> Thank you for the clarification.  It is the case in material
> sciences  that the surface area to volume ratio of objects,
>  particularly  conductive objects, is of primary relevance.  As it
> turns out, the  Object Counter 3D plugin on first glance was exactly
> what was needed  for further analysis of 3D objects in a matrix.
>  Our mistaken missive  of the 'surface area' values did, however,
>  restrict the applicability  and as a result we have gone forward
> with an alternative method.
>
> Particularly, I was wondering if you had considered implementing a  
> Hoshen-Kopelman algorithm for determining 3D connectivity of
> particles  and the resulting 'true' surface area of each particle.
>
> Regards,
>
> Tom Elliot
> PhD Candidate
> Land Resource Science
> University of Guelph
>
> Quoting Fabrice Cordelières <[hidden email]>:
>
> > Dear Thomas,
> >
> > As I am the one who "committed" this plugin, I will briefly answer your
> > questioning.
> > 3D object counter is grouping object pixels into particles by looking at

one
> > pixel's 8 neighbors in 2D and 26 neighbors in 3D. Doing so it will label
all
> > particles and return as "volume" the number of pixels/voxels forming each
> > particle, and as "surface" the number of pixels/voxels lacking at least
one
> > of its neighbors. The way one pixel is "lacking neighbors" might vary in
> > many ways (for example, one surface along xy plane or one surface along
xz
> > plane may not result in the same surface, as you've mentioned).  This is
> > obviously not a true measure of the surface therefore I will change the
> > denomination of this line within the table of results so that no one
could
> > be mistaken. I'm currently working on an updated version of the plugin
and

> > will take your comment into account.
> >
> > Fabrice
> >
> >
> >
> >
> > Fabrice Cordelières, PhD
> >  Institut Curie - Section de recherche/ CNRS UMR 146
> > Plateforme d'Imagerie Cellulaire et Tissulaire
> > Bâtiment 112 - Centre universitaire
> > 91405 Orsay Cedex
> > FRANCE
> >  Tél. : [phone]
> > Fax. : [phone]
> >
> > Consultez mes disponibilités sur
> > http://www.google.com/calendar/embed?src=fabrice.cordelieres%40gmail.com
> >
> > -----Message d'origine-----
> > De : ImageJ Interest Group [mailto:[hidden email]] De la part de

Thomas

> > Elliot
> > Envoyé : vendredi 2 novembre 2007 13:16
> > À : [hidden email]
> > Objet : Object Counter 3D
> >
> > Greetings.
> >
> > In using the Object Counter 3D (or the original 3D Object Counter), we
> > noted that the surface area reported is often the same value as the
> > volume.  Which is an impossibility.
> >
> > To examine this, I created a 5x5x5 voxel image with the central voxel
> > (at 3,3,3) being a single value of 255 and the remaining 124 voxels
> > set to 0.  The results from the plugin operation were:
> > Volume = 1
> > Surface Area = 1
> >
> > In comparison, I inverted the very same stack, ran the plugin again
> > and received:
> > Volume = 123
> > Surface Area = 56.
> >
> > Now, you would expect that for the inverse the Volume would be 124,
> > and the Surface Area = 156 (25 surfaces per side of the cube x 6 sides
> > + 6 sides of the internal 'particle' at the center), or at the very
> > least it could identify that there were 104 voxels acting as direct
> > 'surface' volume elements [(9 voxels per side x 6 sides) + (44 voxels
> > as external edges of image cube) + 6 internal) with the remaining
> > surface area (of the 156) being accounted for by counting multiple
> > faces of singular voxels.
> >
> > What we do have is 56 surface area, which I am assuming is derived
> > from the 25 voxels at Z+ (Slice 1) and 25 voxels at Z- (Slice 5), with
> > the 6 internal voxels.
> >
> > There is no universal 'scaling factor' that can be used on both
> > scenarios (i.e. if the first scenario of the singular voxel is to
> > attain the actual surface area, it would have to be multiplied by 6,
> > which when applied to the second scenario results in an unreasonable
> > surface area for the structure) and apparently medial and axial edges
> > of the image are not accounted for in the plugin.
> >
> > I am having doubts as to the validity of this plugin and would like
> > someone to verify that data acquired and published (fortunately I have
> > not made that plunge yet) using this plugin is not erroneous.
> >
> > Regards,
> >
> > Tom Elliot
> >

--
Fabrice Cordelières, PhD

Institut Curie - Section de recherche/ CNRS UMR 146
Plateforme d'Imagerie Cellulaire et Tissulaire
Bâtiment 112 - Centre universitaire
91405 Orsay Cedex
FRANCE

Tél. : [phone]
Fax. : [phone]

Consultez mes disponibilités sur http://www.google.com/calendar/embed?
src=fabrice.cordelieres%40gmail.com