longest inscribed lines?

[Michael Schmid]

Hi everyone,

maybe someone of you has a solution for the following problem:
I have images of elongated martensitic grains, e.g.:
   http://www.iap.tuwien.ac.at/~schmid/MartensiticGrains.png

I want to get some indication of the lengths of the grains to compare  
it with other images.
The Fourier transform is dominated by the grain widths, so it does  
not help.
Often, the grains are not separated but touch others, so caliper  
length (Feret's diameter) won't work either.

A possibility would be searching for the "longest inscribed lines",  
i.e., the longest straight lines that fit into the foreground of the  
image, or even better, the longest line with a limited curvature (to  
follow slightly curved grains). Does anyone know about a plugin or  
some other transform/method that could do this?

Thank you,

Michael

[Gabriel Landini]

On Friday 17 July 2009  12:56:36 Michael Schmid wrote:

> Hi everyone,
>
> maybe someone of you has a solution for the following problem:
> I have images of elongated martensitic grains, e.g.:
>    http://www.iap.tuwien.ac.at/~schmid/MartensiticGrains.png
>
> I want to get some indication of the lengths of the grains to compare  
> it with other images.
> The Fourier transform is dominated by the grain widths, so it does  
> not help.
> Often, the grains are not separated but touch others, so caliper  
> length (Feret's diameter) won't work either.
>
> A possibility would be searching for the "longest inscribed lines",  
> i.e., the longest straight lines that fit into the foreground of the  
> image, or even better, the longest line with a limited curvature (to  
> follow slightly curved grains). Does anyone know about a plugin or  
> some other transform/method that could do this?

With wiggly objects like this it is possible that the inscribed lines might
end being quite short.
I would take the skeleton of the crystals, then run the connectivity plugin
and threshold between 1 and 3. This would break the linear parts of the  
skeleton. I would use the Lines8 plugin to get their length distribution.

I hope it helps

Gabriel

[Michael Schmid]

Hi Gabriel,

thank you for spending some time on this.

I have three problems with the skeleton:

(1) Short side branches, mainly due to the uneven width of the  
grains. I could modify one of my plugins to get rid of these.
(2) Long side branches that are due to a long a grain. Not so easy to  
disconnect such a side branch because one has to check which of the  
three branches meeting in a point is the sidebranch, and which one  
runs straight through.
(3) Related to (2): sometimes two grains with different orientation  
touch at the ends, resulting one long line with a kink -  
morphologically the same as a straight line.

Any ideas for this?

Concerning the 'wigglyness' - yes, this could be a problem for a  
'longest inscribed lines' algorithm, but I think I could cope with it:

A dilation operation that does not join particles would solve it -  
maybe with your morphology collection? Otherwise simple dilation and  
resetting the skeletonized background would do it.

Michael
________________________________________________________________

On 17 Jul 2009, at 14:00, Gabriel Landini wrote:

> On Friday 17 July 2009  12:56:36 Michael Schmid wrote:
>> Hi everyone,
>>
>> maybe someone of you has a solution for the following problem:
>> I have images of elongated martensitic grains, e.g.:
>>    http://www.iap.tuwien.ac.at/~schmid/MartensiticGrains.png
>>
>> I want to get some indication of the lengths of the grains to compare
>> it with other images.
>> The Fourier transform is dominated by the grain widths, so it does
>> not help.
>> Often, the grains are not separated but touch others, so caliper
>> length (Feret's diameter) won't work either.
>>
>> A possibility would be searching for the "longest inscribed lines",
>> i.e., the longest straight lines that fit into the foreground of the
>> image, or even better, the longest line with a limited curvature (to
>> follow slightly curved grains). Does anyone know about a plugin or
>> some other transform/method that could do this?
>
> With wiggly objects like this it is possible that the inscribed  
> lines might
> end being quite short.
> I would take the skeleton of the crystals, then run the  
> connectivity plugin
> and threshold between 1 and 3. This would break the linear parts of  
> the
> skeleton. I would use the Lines8 plugin to get their length  
> distribution.
>
> I hope it helps
>
> Gabriel

[Jill Tipping]

Dear group.


I am a research physicist within the radioisotope (nuclear medicine)
department at the Christie hospital UK.

Part of my work involves calculations and processing images created by
scanning patients during their therapy with radioactive isotopes

Normally processing is performed on a commercial dedicated package using
a visual basic based language.

However for a new project we are attempting to replicate a system
developed by French colleagues at Nantes.  This involves actions beyond
the capabilities of the commercial system.

This work is to be done on ImageJ
 
Can I apologise for explaining that we have never worked in Java before-
so the French kindly provided their plugins for us (mainly developed in
house).

We have run into all sorts of problems getting some of the French
programs (most of which are the class files rather than the Java
versions) to behave.

Trouble shooting has proved rather tricky.

In essence we are trying to understand an error message (or exception)  

java.lang.ClassFormatError: Unknown constant tag 32 in class file
ManipImageDosi/TEW_CE_Stack

            at java.lang.ClassLoader.defineClass1(Native Method)

            at java.lang.ClassLoader.defineClass(Unknown Source)

            at java.lang.ClassLoader.defineClass(Unknown Source)

            at
ij.io.PluginClassLoader.loadClass(PluginClassLoader.java:246)

            at
ij.io.PluginClassLoader.loadClass(PluginClassLoader.java:209)

            at ij.IJ.runUserPlugIn(IJ.java:156)

            at ij.IJ.runPlugIn(IJ.java:124)

            at ij.Executer.runCommand(Executer.java:104)

            at ij.Executer.run(Executer.java:58)

            at java.lang.Thread.run(Unknown Source)

 
As far as we can tell the class file ManipImageDosi TEW CE stack is
there.

We have asked an inhouse IT tech to try decompiling the class file but
he was not able to.

Our question is

Can you tell if this is a trivial error that, once understood, can be
easily solved.
If you can tell immediately that we have a more complicated problem on
hand would you be willing to advise us through the steps we need to go
through, or refer us to someone who can.

As far as I can tell.  We are using Java 1.5 on a windows system.  The
ImageJ system is 1.41

We would be very grateful for any advice you could give us, and
apologise once more for being physicists who are beyond our programming
skills.

Many thanks for your attention
 
Jill


Dr Jill Tipping
North Western Medical Physics
Radioisotope Department
Christie Hospital NHS Foundation Trust
M20 4BX
Tel: [phone]


****************************************************************
This e-mail and any files transmitted with it are confidential
and solely for the use of the intended recipient. If you have
received this e-mail in error you should not disseminate,
distribute or copy it. Please notify the sender immediately and
delete this e-mail from your system.
****************************************************************

[Gabriel Landini]

Hi Michael,

On Friday 17 July 2009  14:18:46 Michael Schmid wrote:
> I have three problems with the skeleton:

Yes, it is not what you were asking, I know. :-)
 
> (1) Short side branches, mainly due to the uneven width of the  
> grains. I could modify one of my plugins to get rid of these.

You can get rid of these with the Lines8, or just ignore them after you
collect their lengths.

> (2) Long side branches that are due to a long a grain. Not so easy to  
> disconnect such a side branch because one has to check which of the  
> three branches meeting in a point is the sidebranch, and which one  
> runs straight through.

Well, yes, there is no easy way to get the hierarchy of the branching.  I have
no suggestion for this. But in the end I think that with a skeleton with 3
branches at equal angles any algorithm would end up choosing one of the
branches a secondary, arbitrarily.

> (3) Related to (2): sometimes two grains with different orientation  
> touch at the ends, resulting one long line with a kink -  
> morphologically the same as a straight line.

I see the problem here too. But how would one know whether the crystal is a
kinked one of the sum of two straight ones?

> Concerning the 'wigglyness' - yes, this could be a problem for a  
> 'longest inscribed lines' algorithm, but I think I could cope with it:

A problem I see is that there are some clusters with holes. Where does one
locate the line? So even if the longest inscribed line can be found it might
not be a good descriptor of the geometry of the crystal agglomerates if one
cannot separate them.
 
> A dilation operation that does not join particles would solve it -  
> maybe with your morphology collection? Otherwise simple dilation and  
> resetting the skeletonized background would do it.

Do you mean something like the Influence Zones? or the Dilate-no-merge (the
latter is awfully slow and inefficient).

Alternatively would some stereological approach be useful?  For example
counting intersects of one of the phases with control lines at various angles?

Cheers

Gabriel

[Michael Schmid]

On 17 Jul 2009, at 16:00, Gabriel Landini wrote:

> Alternatively would some stereological approach be useful?  For  
> example
> counting intersects of one of the phases with control lines at  
> various angles?


Hi Gabriel,

this is a good idea - my grains orientations cluster around a few  
value, so the distributions of the lengths might tell me something.


Michael

[Julian Cooper]

Dear Michael,

I am not sure whether this method will help but it seemed to reliably
isolate the grains when I tried it on your image.

1. Obtain two new images, one with horizontal edges detected and the other
vertical, from the original by Process>Filters>Convolve with kernels as
follows:
     1  2  1       1  0 -1
     0  0  0       2  0 -2
    -1 -2 -1       1  0 -1

2. Invert the images

3. Use Analyze Particles on each image with default size, and circularity
0.0-0.5 (other values may be better but this seemed OK with your image so
that individual "dots" were excluded and grains remained. The Feret's
diameter appears to work then, as far as I can tell.

As a check I added the two masks, from the vertical and horizontal edge
images, together and this appeared very similar to the skeletonized version
of the original image but with thicker lines. I am not sure what happens if
the grains are aligned  near to 45 degrees to the image boundaries, but that
didn't seem to be often the case in your image.

Kind regards,

Julian

> -----Original Message-----
> From: ImageJ Interest Group [mailto:[hidden email]] On
> Behalf Of Michael Schmid
> Sent: 17 July 2009 11:50
> To: [hidden email]
> Subject: longest inscribed lines?
>
>
> Hi everyone,
>
> maybe someone of you has a solution for the following problem:
> I have images of elongated martensitic grains, e.g.:
>    http://www.iap.tuwien.ac.at/~schmid/MartensiticGrains.png
>
> I want to get some indication of the lengths of the grains to
> compare  
> it with other images.
> The Fourier transform is dominated by the grain widths, so it does  
> not help.
> Often, the grains are not separated but touch others, so caliper  
> length (Feret's diameter) won't work either.
>
> A possibility would be searching for the "longest inscribed lines",  
> i.e., the longest straight lines that fit into the foreground of the  
> image, or even better, the longest line with a limited curvature (to  
> follow slightly curved grains). Does anyone know about a plugin or  
> some other transform/method that could do this?
>
> Thank you,
>
> Michael
>

[Frederic V. Hessman]

I received a request for an ImageJ connection with the Windows COM API  
(the native component object system) from a user of the ASCOM  
astronomy API (which connects the world of Windows-based amateur  
astronomy gadgets from telescopes and domes to cameras and focusers):  
see http://ascom-standards.org/Standards/Index.htm for the API.

Most commercial camera manufacturers and/or image-processing programs  
support the ASCOM standard but with ImageJ there would be a generic,  
open-source and free alternative.   The camera interface might be  
interesting for many non-astronomical ImageJ developers/users.

Unfortunately, I didn't see anything on the web or the ImageJ plugin  
lists and, as a non-Windows person, I have no idea what this might  
entail.    Can't be too simple for a cross-platform solution, since  
the only COM bridge I found for Linux was commericial and one-way only.

Anybody out there with experience or hints?

Rick

[Volker Baecker]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I know JACOB as a free java com bridge. See
http://sourceforge.net/projects/jacob-project/
I found it quite easy to use.

Google reveals that there is already a project concerning ASCOM
http://linux.softpedia.com/get/Science-and-Engineering/Astronomy/jAscom-20345.shtml
I don't know this one.

I'm not sure what a com bridge for linux should be. In my understanding
com is a windows technology that allows to access components running on
windows from programs that runs on the same machine. Not a system
independent technology for distributed components like corba.

Best regards,
Volker Baecker

Frederic V. Hessman wrote:

> I received a request for an ImageJ connection with the Windows COM API
> (the native component object system) from a user of the ASCOM astronomy
> API (which connects the world of Windows-based amateur astronomy gadgets
> from telescopes and domes to cameras and focusers): see
> http://ascom-standards.org/Standards/Index.htm for the API.
>
> Most commercial camera manufacturers and/or image-processing programs
> support the ASCOM standard but with ImageJ there would be a generic,
> open-source and free alternative.   The camera interface might be
> interesting for many non-astronomical ImageJ developers/users.
>
> Unfortunately, I didn't see anything on the web or the ImageJ plugin
> lists and, as a non-Windows person, I have no idea what this might
> entail.    Can't be too simple for a cross-platform solution, since the
> only COM bridge I found for Linux was commericial and one-way only.
>
> Anybody out there with experience or hints?
>
> Rick
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkrpXMQACgkQ0gXPLVKexCdwJwCfdcftJnYtyo5UtH6j2Ry7kTnz
cfIAnAy4RIxjfkzR55gnfhRtH3CrQ0AX
=KfH9
-----END PGP SIGNATURE-----

--
passerelle antivirus du campus CNRS de Montpellier
--

[dscho]

Hi,

On Thu, 29 Oct 2009, Volker Baecker wrote:

> I'm not sure what a com bridge for linux should be. In my understanding
> com is a windows technology that allows to access components running on
> windows from programs that runs on the same machine. Not a system
> independent technology for distributed components like corba.

Exactly.  That would be DCOM, but that still shares the Windows-only
limitation.

Ciao,
Johannes