diameter automatic calculation

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

diameter automatic calculation

Marco Ballestri
I'm interesting to determinate the diameters of nanoparticles
obtained by SEM, do you know how is possible make it
automatically or is it possible to use a macro for this?
thanks a lot for your attention,  Marco Ballestri

--

********************************************************************************************************************

    Marco Ballestri              http://www.isof.cnr.it/

    Istituto ISOF/CNR            mailto:[hidden email]

    Via Gobetti 101              Room 513, 3rd Floor

    I-40129 Bologna             Phone: ++39 051 639 8261

    ITALY                        Fax:  ++39 051 639 8349

 
Reply | Threaded
Open this post in threaded view
|

"Unclean code" in FFT class

Joachim Wesner
Hi there,

I´m planning to write a ImageJ plugin for fringe processing (of
interferometric data etc.) based on the so-called "spatial carrier phase
measurement" method. As I´m pretty new to ImageJ and because the algorithm
in one step requires a fully complex inverse FFT, I have been looking
carefully at the existing FFT and FHT code (I will need to split that
complex FFT in two appropritate FHTs).

However, I am wondering about some strange issues in the FFT class:

As I understand, this class is meant to be both a Plugin to be used for the
current image(s) ("manually", or from a macro), but also exports some
public methods for more general usage.

I´m wondering why does doForewardTransform (and also the private
doInverseTransform) require an FHT object AND an image processor object ip?
Everything about the current image should already be available through he
FHT object, or no?

Even more, the argument ip seems not to be referenced at all in the code
for both methods, but instead, IMHO incorrectly, a reference to a private
Imageplus imp is used. This works as long as the class is only used as a
plugin, but if you call the public method from another place, the old (if
it even already exists?!) imp from the last "manual" call of the plugin
will be referenced. Am I missing something here?


BTW, ImageJ does not yet seem to have any plugin for (2-dimensional) phase
unwrapping - OR? I could not find one, so I will add that too.


Sincerely

Joachim Wesner


______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________
Reply | Threaded
Open this post in threaded view
|

Re: "Unclean code" in FFT class

Robert Dougherty
Jochim,

One way to deal with FHTs in ImageJ plugins is illustrated in FHT 3D.  My
solution was to hack some source code from ImageJ.  Not very OO, but
effective.  It does seem like it might be useful if FHT.rc2DFHT and
FHT.dfht3 were available as public static methods.

Bob

Robert P. Dougherty, Ph.D.
President, OptiNav, Inc.
Phone (425) 467-1118
Fax (425) 467-1119
www.optinav.com

 

> -----Original Message-----
> From: ImageJ Interest Group [mailto:[hidden email]] On Behalf Of
> Joachim Wesner
> Sent: Thursday, March 16, 2006 8:59 AM
> To: [hidden email]
> Subject: "Unclean code" in FFT class
>
> Hi there,
>
> I´m planning to write a ImageJ plugin for fringe processing (of
> interferometric data etc.) based on the so-called "spatial carrier phase
> measurement" method. As I´m pretty new to ImageJ and because the algorithm
> in one step requires a fully complex inverse FFT, I have been looking
> carefully at the existing FFT and FHT code (I will need to split that
> complex FFT in two appropritate FHTs).
>
> However, I am wondering about some strange issues in the FFT class:
>
> As I understand, this class is meant to be both a Plugin to be used for
> the
> current image(s) ("manually", or from a macro), but also exports some
> public methods for more general usage.
>
> I´m wondering why does doForewardTransform (and also the private
> doInverseTransform) require an FHT object AND an image processor object
> ip?
> Everything about the current image should already be available through he
> FHT object, or no?
>
> Even more, the argument ip seems not to be referenced at all in the code
> for both methods, but instead, IMHO incorrectly, a reference to a private
> Imageplus imp is used. This works as long as the class is only used as a
> plugin, but if you call the public method from another place, the old (if
> it even already exists?!) imp from the last "manual" call of the plugin
> will be referenced. Am I missing something here?
>
>
> BTW, ImageJ does not yet seem to have any plugin for (2-dimensional) phase
> unwrapping - OR? I could not find one, so I will add that too.
>
>
> Sincerely
>
> Joachim Wesner
>
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________
Reply | Threaded
Open this post in threaded view
|

Antwort: Re: "Unclean code" in FFT class

Joachim Wesner
Bob,

I think you are right.

As I'm still mostly a "procedural" programmer and not an OO one, it seems
best/fastest to me for getting to a working version of a more complex
plugin: Extract the needed FHT routines (that directly work with arrays
etc.) from the sources and base the plugin on that code, instead of
immediately dealing with image processors whose intermediate images won´t
be displayed anyhow!

Later one could cleanup the code and convert it to use straight IPs and
FHTs.

Joachim





                                                                                                                                       
                      Robert Dougherty                                                                                                
                      <[hidden email]         An:      [hidden email]                                                            
                      >                        Kopie:   (Blindkopie: Joachim Wesner/DEWET/LMSCentral/Leica)                            
                      Gesendet von:            Thema:   Re: "Unclean code" in FFT class                                                
                      ImageJ Interest                                                                                                  
                      Group                                                                                                            
                      <[hidden email]                                                                                                
                      .GOV>                                                                                                            
                                                                                                                                       
                                                                                                                                       
                      16.03.2006 19:23                                                                                                
                      Bitte antworten                                                                                                  
                      an ImageJ                                                                                                        
                      Interest Group                                                                                                  
                                                                                                                                       




Jochim,

One way to deal with FHTs in ImageJ plugins is illustrated in FHT 3D.  My
solution was to hack some source code from ImageJ.  Not very OO, but
effective.  It does seem like it might be useful if FHT.rc2DFHT and
FHT.dfht3 were available as public static methods.

Bob

Robert P. Dougherty, Ph.D.
President, OptiNav, Inc.
Phone (425) 467-1118
Fax (425) 467-1119
www.optinav.com


 ______________________________________________________________________



______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________