Accuracy of Feret measurements

[Sidnei Paciornik]

Dear colleagues,

Any one knows the accuracy with which Feret diameters are measured?

I suppose the minimum and maximum Feret diameters are obtained from the
projections of any object in various angles/directions. So I guess the
accuracy would depend on the angle step.

Is that correct? Is this info available somewhere?

Thank you.

Prof. Sidnei Paciornik
Grupo de Análise de Imagens e Microscopia Digital
DEMa <http://www.dema.puc-rio.br/> - Departamento de Engenharia de Materiais
PUC-Rio <http://www.puc-rio.br/>
Rua Marquês de São Vicente 225
Prédio Leme, Sala 501L
Gávea - Rio de Janeiro - RJ
22451-900 - Brasil
tel: [phone]

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Gabriel Landini]

On Sunday 09 Jun 2013 02:43:24 you wrote:
> Any one knows the accuracy with which Feret diameters are measured?
>
> I suppose the minimum and maximum Feret diameters are obtained from the
> projections of any object in various angles/directions. So I guess the
> accuracy would depend on the angle step.
>
> Is that correct? Is this info available somewhere?

http://imagej.nih.gov/ij/list.htmlhttp://imagej.nih.gov/ij/source/ij/gui/Roi.java

for (double a=0; a<=90; a+=0.5) { // rotate calipers in 0.5 degree increments

So you answer is  0.5 degrees.
The Particles8 and 4 plugins use a loop through the perimeter pixels, so the
maximum Feret does not have an accuracy issue.
Those plugins do not measure the min Feret, though, but measure breadth.

Cheers
Gabriel

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Michael Schmid]

Hi Sidnei, Gabriel,

as I read it from the code, in ImageJ the maximum Feret (and the Feret angle, which refers to the maximum width) is calculated accurately, by a double loop over the corner pixels.

Varying the angle in 0.5-degree steps is used only for the minimum Feret.
Nevertheless, it should be accurate to approx 10^-5 of the maximum Feret value.
[One could consider improving this if needed.]

By the way, it should be noted that Particles8 uses a different convention for the Feret diameter: In standard ImageJ, a single pixel has a Feret diameter of sqrt2 = 1.4142. In particles8, a single pixel has a Feret dimater of 0.
A 2x2 block of pixels has Feret diameters of 2sqrt2 and sqrt2, respectively.

Michael
________________________________________________________________
On Jun 9, 2013, at 10:43, Gabriel Landini wrote:

> On Sunday 09 Jun 2013 02:43:24 you wrote:
>> Any one knows the accuracy with which Feret diameters are measured?
>>
>> I suppose the minimum and maximum Feret diameters are obtained from the
>> projections of any object in various angles/directions. So I guess the
>> accuracy would depend on the angle step.
>>
>> Is that correct? Is this info available somewhere?
>
> http://imagej.nih.gov/ij/list.htmlhttp://imagej.nih.gov/ij/source/ij/gui/Roi.java
>
> for (double a=0; a<=90; a+=0.5) { // rotate calipers in 0.5 degree increments
>
> So you answer is  0.5 degrees.
> The Particles8 and 4 plugins use a loop through the perimeter pixels, so the
> maximum Feret does not have an accuracy issue.
> Those plugins do not measure the min Feret, though, but measure breadth.
>
> Cheers
> Gabriel
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Gabriel Landini]

On Monday 10 Jun 2013 15:03:45 Michael Schmid wrote:
> By the way, it should be noted that Particles8 uses a different convention
> for the Feret diameter: In standard ImageJ, a single pixel has a Feret
> diameter of sqrt2 = 1.4142. In particles8, a single pixel has a Feret
> dimater of 0. A 2x2 block of pixels has Feret diameters of 2sqrt2 and
> sqrt2, respectively.

Hi,
Thanks Michael for assuring that in IJ the Max Feret does not depend on the
rotation.

Just to clarify Particles8 & 4 consider the centres of the 8- or 4-connected
pixels that make the boundary as the points where to base the measurements.
As a consequence, isolated pixels are considered "points" (without a boundary
length) and have therefore no perimeter (it is 0), or Feret diameter. The Area
in those plugins (which in IJ is the number of pixels) is computed as the
"area enclosed by the connected boundary". So isolated pixels also have a 0
"area", but they are made of 1 pixel, so the plugins output both Area=0 and
Pixels=1.

Now that we are at this, note that the particle analyser, by giving a finite
perimeter to single pixels, ends up with some strange results: an isolated
pixel has a perimeter of 2.828 (i.e.sqrt(2)*2) and area=1) but it shows up
with circularity=1 which is not the value that you get when you apply the
formula for circularity (1.570...).
A pixel (if considered a point) should have no circularity, and if
(questionably) considered a "square" (what we see on screen, area=1 and
perimeter=4) circ. should be 0.7853 but is given a value of 1.

Although I understand where those differences arise from, I wonder if it might
be better to provide mechanisms for knowing which blobs can and cannot have
certain descriptors. In the Particles8/4 these are output as -1 and some, like
Feret, as 0). Maybe NaN for all would be better?

Cheers

Gabriel

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Michael Schmid]

Hi Gabriel,

yes, I agree with you that the perimeters given by ImageJ tend to be very small for small objects, considering the fact that the pixels count as full squares when calculating the area. For large objects the perimeter values are not so bad (e.g. 5% too large for a large traced circle, when compared to pi*diameter).
Circularity is defined as 4 pi *area/perimeter, so it results in values that are too large for small objects. Obviously, it is truncated to avoid values larger than 1.
As a traced selection, a square of 5*5 pixels still gets a circularity of 1, and so does a rectangle of 1*2 pixels.

On the other hand, a rectangle of 5*5 pixels having a circularity value of 1 is not really wrong: You can have a circle with a radius slightly below 6, which gives a 5x5 square when sampled at the positions of the pixels. So a 5x5 square in a traced roi may actually be the result of a circular particle imaged by discrete pixels, see the attached figure. Also a rectangle of 1*2 pixels may be a circular particle with a diameter slightly above 1 pixel and placed at the dividing line between two pixels.

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html



[There is an alternative algorithm that gives what one may consider 'nicer' values, still using the standard ImageJ convention that a single pixel has an area of 1, and accounting for the pixelated outline being an approximation to a continuous shape: One can simply take the centers of all corner pixels, connect them by straight lines, and add pi or 4 to the length of this outline].

Anyhow, we should not change the perimeter and circularity values given by ImageJ: There are many macros and established procedures that use the circularity filter of the particle analyzer, and these will behave differently.
Having an option for 'traditional' and 'more accurate' perimeters would confuse users, and macro results would depend on this option as a 'hidden parameter'.

Best regards,

Michael
________________________________________________________________
On Jun 10, 2013, at 19:36, Gabriel Landini wrote:

> On Monday 10 Jun 2013 15:03:45 Michael Schmid wrote:
>> By the way, it should be noted that Particles8 uses a different convention
>> for the Feret diameter: In standard ImageJ, a single pixel has a Feret
>> diameter of sqrt2 = 1.4142. In particles8, a single pixel has a Feret
>> dimater of 0. A 2x2 block of pixels has Feret diameters of 2sqrt2 and
>> sqrt2, respectively.
>
> Hi,
> Thanks Michael for assuring that in IJ the Max Feret does not depend on the
> rotation.
>
> Just to clarify Particles8 & 4 consider the centres of the 8- or 4-connected
> pixels that make the boundary as the points where to base the measurements.
> As a consequence, isolated pixels are considered "points" (without a boundary
> length) and have therefore no perimeter (it is 0), or Feret diameter. The Area
> in those plugins (which in IJ is the number of pixels) is computed as the
> "area enclosed by the connected boundary". So isolated pixels also have a 0
> "area", but they are made of 1 pixel, so the plugins output both Area=0 and
> Pixels=1.
>
> Now that we are at this, note that the particle analyser, by giving a finite
> perimeter to single pixels, ends up with some strange results: an isolated
> pixel has a perimeter of 2.828 (i.e.sqrt(2)*2) and area=1) but it shows up
> with circularity=1 which is not the value that you get when you apply the
> formula for circularity (1.570...).
> A pixel (if considered a point) should have no circularity, and if
> (questionably) considered a "square" (what we see on screen, area=1 and
> perimeter=4) circ. should be 0.7853 but is given a value of 1.
>
> Although I understand where those differences arise from, I wonder if it might
> be better to provide mechanisms for knowing which blobs can and cannot have
> certain descriptors. In the Particles8/4 these are output as -1 and some, like
> Feret, as 0). Maybe NaN for all would be better?
>
> Cheers
>
> Gabriel
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Sidnei Paciornik]

This discussion on accuracy is very relevant and I thank you for providing
so much detail.

I agree, of course, that the core definitions should not be changed, but it
migth be worth providing some specific options for users with specific
needs.

For that matter, I have often heard about the Crofton Perimeter, that is
supposed to be a better way of measuring the perimeter, less dependent on
pixel size versus object size. I know other programs (e.g. KS400 and
AxioVision, from Carl Zeiss) do implement this measurement.

Is there any implementation for ImageJ? May be someone could comment on
this type of measurement (which I don´t really understand...).

Regards,
Prof. Sidnei Paciornik
Grupo de Análise de Imagens e Microscopia Digital
DEMa <http://www.dema.puc-rio.br/> - Departamento de Engenharia de Materiais
PUC-Rio <http://www.puc-rio.br/>
Rua Marquês de São Vicente 225
Prédio Leme, Sala 501L
Gávea - Rio de Janeiro - RJ
22451-900 - Brasil
tel: [phone]


On Tue, Jun 11, 2013 at 10:57 AM, Michael Schmid <[hidden email]>
 wrote:

> Hi Gabriel,
>
> yes, I agree with you that the perimeters given by ImageJ tend to be very
> small for small objects, considering the fact that the pixels count as full
> squares when calculating the area. For large objects the perimeter values
> are not so bad (e.g. 5% too large for a large traced circle, when compared
> to pi*diameter).
> Circularity is defined as 4 pi *area/perimeter, so it results in values
> that are too large for small objects. Obviously, it is truncated to avoid
> values larger than 1.
> As a traced selection, a square of 5*5 pixels still gets a circularity of
> 1, and so does a rectangle of 1*2 pixels.
>
> On the other hand, a rectangle of 5*5 pixels having a circularity value of
> 1 is not really wrong: You can have a circle with a radius slightly below
> 6, which gives a 5x5 square when sampled at the positions of the pixels. So
> a 5x5 square in a traced roi may actually be the result of a circular
> particle imaged by discrete pixels, see the attached figure. Also a
> rectangle of 1*2 pixels may be a circular particle with a diameter slightly
> above 1 pixel and placed at the dividing line between two pixels.
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>
>
>
> [There is an alternative algorithm that gives what one may consider
> 'nicer' values, still using the standard ImageJ convention that a single
> pixel has an area of 1, and accounting for the pixelated outline being an
> approximation to a continuous shape: One can simply take the centers of all
> corner pixels, connect them by straight lines, and add pi or 4 to the
> length of this outline].
>
> Anyhow, we should not change the perimeter and circularity values given by
> ImageJ: There are many macros and established procedures that use the
> circularity filter of the particle analyzer, and these will behave
> differently.
> Having an option for 'traditional' and 'more accurate' perimeters would
> confuse users, and macro results would depend on this option as a 'hidden
> parameter'.
>
> Best regards,
>
> Michael
> ________________________________________________________________
> On Jun 10, 2013, at 19:36, Gabriel Landini wrote:
>
> > On Monday 10 Jun 2013 15:03:45 Michael Schmid wrote:
> >> By the way, it should be noted that Particles8 uses a different
> convention
> >> for the Feret diameter: In standard ImageJ, a single pixel has a Feret
> >> diameter of sqrt2 = 1.4142. In particles8, a single pixel has a Feret
> >> dimater of 0. A 2x2 block of pixels has Feret diameters of 2sqrt2 and
> >> sqrt2, respectively.
> >
> > Hi,
> > Thanks Michael for assuring that in IJ the Max Feret does not depend on
> the
> > rotation.
> >
> > Just to clarify Particles8 & 4 consider the centres of the 8- or
> 4-connected
> > pixels that make the boundary as the points where to base the
> measurements.
> > As a consequence, isolated pixels are considered "points" (without a
> boundary
> > length) and have therefore no perimeter (it is 0), or Feret diameter.
> The Area
> > in those plugins (which in IJ is the number of pixels) is computed as the
> > "area enclosed by the connected boundary". So isolated pixels also have
> a 0
> > "area", but they are made of 1 pixel, so the plugins output both Area=0
> and
> > Pixels=1.
> >
> > Now that we are at this, note that the particle analyser, by giving a
> finite
> > perimeter to single pixels, ends up with some strange results: an
> isolated
> > pixel has a perimeter of 2.828 (i.e.sqrt(2)*2) and area=1) but it shows
> up
> > with circularity=1 which is not the value that you get when you apply the
> > formula for circularity (1.570...).
> > A pixel (if considered a point) should have no circularity, and if
> > (questionably) considered a "square" (what we see on screen, area=1 and
> > perimeter=4) circ. should be 0.7853 but is given a value of 1.
> >
> > Although I understand where those differences arise from, I wonder if it
> might
> > be better to provide mechanisms for knowing which blobs can and cannot
> have
> > certain descriptors. In the Particles8/4 these are output as -1 and
> some, like
> > Feret, as 0). Maybe NaN for all would be better?
> >
> > Cheers
> >
> > Gabriel
> >
> > --
> > ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>
>

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Heeschen, Bill (WA)]

The discussion on Feret measurements (and measurements in general) has been extremely good - thanks to all contributors.  This is one of the toughest things I deal with when teaching others about image measurements and the use of discrete pixels on a rectangular grid to approximate continuous features on an "infinite-resolution" grid (quantum mechanics notwithstanding!)

Gabriel brought up an intriguing point about expressing a result that can't - or shouldn't - be calculated.  The problem is that a non-sense value (like an area of -1) is still a number, so a statistical analysis routine will treat it like a number unless you can get the routine to recognize and exclude non-sense values.  My solution has been to report non-sense/missing results as an empty column in tab-delimited text files (two consecutive tabs instead of tab-number-tab.) The idea is that the stats package knows how to handle a missing value!

I've also gone to returning NaN (not a number) from functions for unavailable results rather than a non-sense value because it is easier to use the isNaN(value) macro call rather than trying to remember which non-sense value I used!

So my vote for expressing incalculable or missing results is NaN.

My USD$0.02

Bill
William A. Heeschen
Analytical Sciences - Microscopy, Digital Imaging
1897 Bldg, E-84
Midland, MI  48667
mailto:[hidden email]

From Gabriel:
Now that we are at this, note that the particle analyser, by giving a finite
perimeter to single pixels, ends up with some strange results: an isolated
pixel has a perimeter of 2.828 (i.e.sqrt(2)*2) and area=1) but it shows up
with circularity=1 which is not the value that you get when you apply the
formula for circularity (1.570...).
A pixel (if considered a point) should have no circularity, and if
(questionably) considered a "square" (what we see on screen, area=1 and
perimeter=4) circ. should be 0.7853 but is given a value of 1.

Although I understand where those differences arise from, I wonder if it might
be better to provide mechanisms for knowing which blobs can and cannot have
certain descriptors. In the Particles8/4 these are output as -1 and some, like
Feret, as 0). Maybe NaN for all would be better?



--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Gabriel Landini]

On Tuesday 11 Jun 2013 18:54:09 Heeschen, Bill wrote:
>  My solution has been to report non-sense/missing
> results as an empty column in tab-delimited text files (two consecutive
> tabs instead of tab-number-tab.) The idea is that the stats package knows
> how to handle a missing value!

I must say I can't remember if we can leave an empty cell in the Results
Table... Can we?
 
> I've also gone to returning NaN (not a number) from functions for
> unavailable results rather than a non-sense value because it is easier to
> use the isNaN(value) macro call rather than trying to remember which
> non-sense value I used!

Yes that is a good point.

With regards to the points raised there are 2 issues, I think.
One is: should we compute circularity (or any other parameters) that rely on
parameters that cannot be extracted?

This is a matter of how we encode the regions. I like to think that pixels are
points, and so they do not have perimeter or area (but they are an entity/atom
in the discrete space). For this, Freeman's algorithm is good.
However IJ gives a pixel a perimeter and an area, so I kind of understand why
it provides a circ. value.
Since I use Particles8 for blob analyses, I do not require for IJ to change
its default, but how IJ encodes and measures regions is something it is useful
to be aware of.

The other issue is bit more delicate: should parameters be "corrected" for
deviating results that arise from using a discrete space? It happens that this
also depends on how the images are encoded.

In Michael's example the argument is that it is OK for a 5x5 square to have
circularity of 1 because a disc would approach that shape... but what if I am
looking at a square in a synthetic image? Should I also expect circularity of
1?
Sure it might not be possible to differentiate a square from a disc in the
discrete space at that size, but why not return the value given by the formula
that is is claimed to be used? Let's be clear, in discrete space (that is what
we are handling), you *can* have a circularity >1.

My take is this: I want to measure what I see on screen and apply the
algorithms to the discrete space. I do not think that having a circularity >1
is a problem, because that is what happens in discrete space.
Perhaps the truncation/correction of parameters to fit an ideal continuous
space should be an option and not the default.

Cheers

Gabriel

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Michael Schmid]

Hi Sidnei, Gabriel and everyone,

there is a plugin for the Crofton perimeter at
  http://www.pfl-cepia.inra.fr/index.php?page=minkFunc

It needs the 'Count Masks' output of 'Analyze Particles' as an input.
Unfortunately the zip file does not include the source code, so one can't have a look what it really does. There is some description in the accompanying article, also on that web page, but this is not a substitute for really seeing the code.


Michael
________________________________________________________________
On Jun 11, 2013, at 19:34, Sidnei Paciornik wrote:

> This discussion on accuracy is very relevant and I thank you for providing
> so much detail.
>
> I agree, of course, that the core definitions should not be changed, but it
> migth be worth providing some specific options for users with specific
> needs.
>
> For that matter, I have often heard about the Crofton Perimeter, that is
> supposed to be a better way of measuring the perimeter, less dependent on
> pixel size versus object size. I know other programs (e.g. KS400 and
> AxioVision, from Carl Zeiss) do implement this measurement.
>
> Is there any implementation for ImageJ? May be someone could comment on
> this type of measurement (which I don´t really understand...).
>
> Regards,
> Prof. Sidnei Paciornik
> Grupo de Análise de Imagens e Microscopia Digital
> DEMa <http://www.dema.puc-rio.br/> - Departamento de Engenharia de Materiais
> PUC-Rio <http://www.puc-rio.br/>
> Rua Marquês de São Vicente 225
> Prédio Leme, Sala 501L
> Gávea - Rio de Janeiro - RJ
> 22451-900 - Brasil
> tel: [phone]
>
>
> On Tue, Jun 11, 2013 at 10:57 AM, Michael Schmid <[hidden email]>
> wrote:
>
>> Hi Gabriel,
>>
>> yes, I agree with you that the perimeters given by ImageJ tend to be very
>> small for small objects, considering the fact that the pixels count as full
>> squares when calculating the area. For large objects the perimeter values
>> are not so bad (e.g. 5% too large for a large traced circle, when compared
>> to pi*diameter).
>> Circularity is defined as 4 pi *area/perimeter, so it results in values
>> that are too large for small objects. Obviously, it is truncated to avoid
>> values larger than 1.
>> As a traced selection, a square of 5*5 pixels still gets a circularity of
>> 1, and so does a rectangle of 1*2 pixels.
>>
>> On the other hand, a rectangle of 5*5 pixels having a circularity value of
>> 1 is not really wrong: You can have a circle with a radius slightly below
>> 6, which gives a 5x5 square when sampled at the positions of the pixels. So
>> a 5x5 square in a traced roi may actually be the result of a circular
>> particle imaged by discrete pixels, see the attached figure. Also a
>> rectangle of 1*2 pixels may be a circular particle with a diameter slightly
>> above 1 pixel and placed at the dividing line between two pixels.
>>
>> --
>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>>
>>
>>
>> [There is an alternative algorithm that gives what one may consider
>> 'nicer' values, still using the standard ImageJ convention that a single
>> pixel has an area of 1, and accounting for the pixelated outline being an
>> approximation to a continuous shape: One can simply take the centers of all
>> corner pixels, connect them by straight lines, and add pi or 4 to the
>> length of this outline].
>>
>> Anyhow, we should not change the perimeter and circularity values given by
>> ImageJ: There are many macros and established procedures that use the
>> circularity filter of the particle analyzer, and these will behave
>> differently.
>> Having an option for 'traditional' and 'more accurate' perimeters would
>> confuse users, and macro results would depend on this option as a 'hidden
>> parameter'.
>>
>> Best regards,
>>
>> Michael
>> ________________________________________________________________
>> On Jun 10, 2013, at 19:36, Gabriel Landini wrote:
>>
>>> On Monday 10 Jun 2013 15:03:45 Michael Schmid wrote:
>>>> By the way, it should be noted that Particles8 uses a different
>> convention
>>>> for the Feret diameter: In standard ImageJ, a single pixel has a Feret
>>>> diameter of sqrt2 = 1.4142. In particles8, a single pixel has a Feret
>>>> dimater of 0. A 2x2 block of pixels has Feret diameters of 2sqrt2 and
>>>> sqrt2, respectively.
>>>
>>> Hi,
>>> Thanks Michael for assuring that in IJ the Max Feret does not depend on
>> the
>>> rotation.
>>>
>>> Just to clarify Particles8 & 4 consider the centres of the 8- or
>> 4-connected
>>> pixels that make the boundary as the points where to base the
>> measurements.
>>> As a consequence, isolated pixels are considered "points" (without a
>> boundary
>>> length) and have therefore no perimeter (it is 0), or Feret diameter.
>> The Area
>>> in those plugins (which in IJ is the number of pixels) is computed as the
>>> "area enclosed by the connected boundary". So isolated pixels also have
>> a 0
>>> "area", but they are made of 1 pixel, so the plugins output both Area=0
>> and
>>> Pixels=1.
>>>
>>> Now that we are at this, note that the particle analyser, by giving a
>> finite
>>> perimeter to single pixels, ends up with some strange results: an
>> isolated
>>> pixel has a perimeter of 2.828 (i.e.sqrt(2)*2) and area=1) but it shows
>> up
>>> with circularity=1 which is not the value that you get when you apply the
>>> formula for circularity (1.570...).
>>> A pixel (if considered a point) should have no circularity, and if
>>> (questionably) considered a "square" (what we see on screen, area=1 and
>>> perimeter=4) circ. should be 0.7853 but is given a value of 1.
>>>
>>> Although I understand where those differences arise from, I wonder if it
>> might
>>> be better to provide mechanisms for knowing which blobs can and cannot
>> have
>>> certain descriptors. In the Particles8/4 these are output as -1 and
>> some, like
>>> Feret, as 0). Maybe NaN for all would be better?
>>>
>>> Cheers
>>>
>>> Gabriel
>>>
>>> --
>>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>>
>>
>> --
>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>>
>>
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Gabriel Landini]

On Thursday 13 Jun 2013 09:16:32 you wrote:
> there is a plugin for the Crofton perimeter at
>   http://www.pfl-cepia.inra.fr/index.php?page=minkFunc
>
> It needs the 'Count Masks' output of 'Analyze Particles' as an input.
> Unfortunately the zip file does not include the source code, so one can't
> have a look what it really does.

It counts the different transitions between the blob and the background.
The article has a reference this book where it is explained the patterns it
counts:

http://books.google.co.uk/books?id=8qMWXqkguscC&pg=PA69&lpg=PA69

and

http://books.google.co.uk/books?id=8qMWXqkguscC&pg=PA76&lpg=PA69

All these methods measure polygons. Something to keep in mind is that if the
boundaries are fractal (or very irregular) the measurements are very likely to
depend on the resolution used, and therefore not comparable across images
unless they are taken at the same magnification.

Cheers
Gabriel

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[ALEMBIC | Cesare]

Dear List,

is there a ImageJ plugin (or someone knows other -free-available software) to easily pseudo-color different structures into SEM images?

I usually do it this PhotShop, but I would leave it.

Thanks in advance for any suggestion.

All the Best,

Cesare


--

ALEMBIC Staff

_________________________________________________________________________________
ALEMBIC
Advanced Light and Electron Microscopy BioImaging Center
San Raffaele Scientific Institute
DIBIT 1  S2B4a
via Olgettina 58, 20132 - Milano - Italy
Tel [phone]/40
Fax [phone]
e-mail: [hidden email]<mailto:[hidden email]>
home page: www.hsr.it/research/alembic<http://www.hsr.it/research/alembic>



<http://www.5xmille.org/>[cid:firma261e.jpg]<http://www.5xmille.org/>

Disclaimer added by CodeTwo Exchange Rules 2007
www.codetwo.com<http://www.codetwo.com>


--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Heeschen, Bill (WA)]

Well put, as usual, Gabriel.

>I must say I can't remember if we can leave an empty cell in the Results
>Table... Can we?

Apparently we can!  I just tested it (version 1.47t) with an exising table, saved it and when I opened the file with Excel, the corresponding cell was empty. Cool!  Both of these commands accomplished the task:
                setResult("Round",1,"");
                setResult("Round",1,NaN);
I'm glad you posed the question!

I typically do the empty cell trick when I write out customized tab-delimited results files...  File.append() is a great command!

>(see Gabriel's comments below.)

This whole business of how to cross the analog/digital boundary makes one's head spin.  We haven't even touched on thresholding!  My hope is that this discussion thread keeps the issue in everyone's mind so that we report results with knowledge about the limitations of the measurements.  Finer resolution in images might help since the differences in perimeter, etc. decrease between measurement strategies, but as soon as we bring in higher resolution, someone will want to measure the smaller particles and we're back to pixel-resolution issues!

I guess it gets back to standard experimental science: make a measurement consistently and define how it was done so that it can be reproduced by others!  It is also important to report the limits of detection and limits of quantitation (which are not the same!).

Maybe the word to the wise is that if you are trying to quantify objects that are represented by very few pixels, you should stick to X/Y location and ignore the area, perimeter, etc.!

BTW, it's great to know that your routines handle pixels as points and I'm glad the option is available.  Thanks for sharing your hard work!

Best Regards,

Bill
William A. Heeschen, Ph.D.
Microscopy, Digital Imaging
The Dow Chemical Company
Midland, MI  48667
[hidden email]


Date:    Wed, 12 Jun 2013 10:27:43 +0100
From:    Gabriel Landini <[hidden email]>
Subject: Re: Accuracy of Feret measurements

On Tuesday 11 Jun 2013 18:54:09 Heeschen, Bill wrote:
>  My solution has been to report non-sense/missing
> results as an empty column in tab-delimited text files (two consecutive
> tabs instead of tab-number-tab.) The idea is that the stats package knows
> how to handle a missing value!

I must say I can't remember if we can leave an empty cell in the Results
Table... Can we?
 
> I've also gone to returning NaN (not a number) from functions for
> unavailable results rather than a non-sense value because it is easier to
> use the isNaN(value) macro call rather than trying to remember which
> non-sense value I used!

Yes that is a good point.

With regards to the points raised there are 2 issues, I think.
One is: should we compute circularity (or any other parameters) that rely on
parameters that cannot be extracted?

This is a matter of how we encode the regions. I like to think that pixels are
points, and so they do not have perimeter or area (but they are an entity/atom
in the discrete space). For this, Freeman's algorithm is good.
However IJ gives a pixel a perimeter and an area, so I kind of understand why
it provides a circ. value.
Since I use Particles8 for blob analyses, I do not require for IJ to change
its default, but how IJ encodes and measures regions is something it is useful
to be aware of.

The other issue is bit more delicate: should parameters be "corrected" for
deviating results that arise from using a discrete space? It happens that this
also depends on how the images are encoded.

In Michael's example the argument is that it is OK for a 5x5 square to have
circularity of 1 because a disc would approach that shape... but what if I am
looking at a square in a synthetic image? Should I also expect circularity of
1?
Sure it might not be possible to differentiate a square from a disc in the
discrete space at that size, but why not return the value given by the formula
that is is claimed to be used? Let's be clear, in discrete space (that is what
we are handling), you *can* have a circularity >1.

My take is this: I want to measure what I see on screen and apply the
algorithms to the discrete space. I do not think that having a circularity >1
is a problem, because that is what happens in discrete space.
Perhaps the truncation/correction of parameters to fit an ideal continuous
space should be an option and not the default.

Cheers

Gabriel


--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html