FFT-Filtering - are non-symmetric masks useful?

[Michael Schmid]

Hi FFT experts,

for filtering images in the Fourier domain, one can paint white
or black on the power spectrum shown after Process>FFT (to pass
and remove the selected areas when transforming back).

The power spectrum has inversion symmetry.
Currently, one has to paint two areas for all off-center
positions, because they appear twice in the power spectrum.
For an example, see the two black bars in the bottom left
image in
   http://rsb.info.nih.gov/ij/docs/examples/FFT/

My question to the FFT experts: Is there any useful application
of filtering only on one side of the center?

Otherwise, with a small modification to the ImageJ code I could
avoid extra work by painting on one side only, having ImageJ do
the other side.
(Sometimes I have to filter or block many spatial frequencies,
then painting them twice makes a difference).

Michael

[Joachim Wesner]

Hi Michael,

as you mention it now, this is actually an issue I wanted to address quite
a while ago. I noted there is a slight "problem" in ImageJ when I added the
complex-to-complex routines to ImageJ.

In a true Real to Complex to Real Transform used for filtering, you would
*NEED* to do symmetrical filtering for a useful result, because otherwise
when transforming back, the filtered output is no longer real but complex
itself

However, due to the underlying inherently always real-to-real Hartley
transform (and how the blocking of the power spectrum is actually handled
in the current version of IJ) is *almost* works correctly even
if you slightly violate the symmetry, the output clearly remains real (as
it can only be), but if you look closer, strange "ghost/mirror artifacts"
appear at places different from the input data. I would need to go through
my stuff for an example the next days, I already had prepared an example
case with strong assymmetry to show this effect.

I would suggest that the handling of the filtering is changed so that the
symmetry of any black/white bars is automatically enforced.

Mit freundlichen Grüßen / Best regards

Joachim Wesner
Projektleiter Optik Technologiesysteme

Ernst Leitz Strasse 17-37 | 35578 Wetzlar (Germany)
Tel.  [phone] | Fax [phone]

____________________________________________

Leica Microsystems CMS GmbH | GmbH mit Sitz in Wetzlar | Amtsgericht
Wetzlar  HRB 2432
Geschäftsführer: Dr. Martin Haase | Colin Davis | Dr. Wolf-Otto Reuter


                                                                           
             Michael Schmid                                                
             <[hidden email]                                            
             N.AC.AT>                                                   An
             Gesendet von:              [hidden email]                
             ImageJ Interest                                         Kopie
             Group                                                        
             <[hidden email].                                       Thema
             GOV>                       FFT-Filtering - are non-symmetric  
                                        masks useful?                      
                                                                           
             11.12.2007 20:42                                              
                                                                           
                                                                           
              Bitte antworten                                              
                    an                                                    
              ImageJ Interest                                              
                   Group                                                  
             <[hidden email].                                            
                   GOV>                                                    
                                                                           
                                                                           




Hi FFT experts,

for filtering images in the Fourier domain, one can paint white
or black on the power spectrum shown after Process>FFT (to pass
and remove the selected areas when transforming back).

The power spectrum has inversion symmetry.
Currently, one has to paint two areas for all off-center
positions, because they appear twice in the power spectrum.
For an example, see the two black bars in the bottom left
image in
   http://rsb.info.nih.gov/ij/docs/examples/FFT/

My question to the FFT experts: Is there any useful application
of filtering only on one side of the center?

Otherwise, with a small modification to the ImageJ code I could
avoid extra work by painting on one side only, having ImageJ do
the other side.
(Sometimes I have to filter or block many spatial frequencies,
then painting them twice makes a difference).

Michael



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

[jmutterer]

Hi Michael, Joachim
a little while ago, I wrote the following simple macro that adds the current
ROI and a center-symmetrical copy of this ROI to the ROI Manager. It might
help when selecting symmetrical areas on the FFT image.
Jerome

macro "AddSym [F1]" {
roiManager("Add");
getSelectionCoordinates(xs,ys);
makeSelection ("polygon",xs,ys);
m=getWidth()/2;
for (i=0;i<xs.length;i++) {
xs[i]=m-(xs[i]-m);
ys[i]=m-(ys[i]-m);}
makeSelection ("polygon",xs,ys);
roiManager("Add");}
/// end macro




On Dec 12, 2007 12:26 AM, Joachim Wesner <
[hidden email]> wrote:

> Hi Michael,
>
> as you mention it now, this is actually an issue I wanted to address quite
> a while ago. I noted there is a slight "problem" in ImageJ when I added
> the
> complex-to-complex routines to ImageJ.
>
> In a true Real to Complex to Real Transform used for filtering, you would
> *NEED* to do symmetrical filtering for a useful result, because otherwise
> when transforming back, the filtered output is no longer real but complex
> itself
>
> However, due to the underlying inherently always real-to-real Hartley
> transform (and how the blocking of the power spectrum is actually handled
> in the current version of IJ) is *almost* works correctly even
> if you slightly violate the symmetry, the output clearly remains real (as
> it can only be), but if you look closer, strange "ghost/mirror artifacts"
> appear at places different from the input data. I would need to go through
> my stuff for an example the next days, I already had prepared an example
> case with strong assymmetry to show this effect.
>
> I would suggest that the handling of the filtering is changed so that the
> symmetry of any black/white bars is automatically enforced.
>
> Mit freundlichen Grüßen / Best regards
>
> Joachim Wesner
> Projektleiter Optik Technologiesysteme
>
> Ernst Leitz Strasse 17-37 | 35578 Wetzlar (Germany)
> Tel.  [phone] | Fax [phone]
>
> ____________________________________________
>
> Leica Microsystems CMS GmbH | GmbH mit Sitz in Wetzlar | Amtsgericht
> Wetzlar  HRB 2432
> Geschäftsführer: Dr. Martin Haase | Colin Davis | Dr. Wolf-Otto Reuter
>
>
>
>             Michael Schmid
>             <[hidden email]
>             N.AC.AT>                                                   An
>             Gesendet von:              [hidden email]
>             ImageJ Interest                                         Kopie
>             Group
>             <[hidden email].                                       Thema
>             GOV>                       FFT-Filtering - are non-symmetric
>                                        masks useful?
>
>             11.12.2007 20:42
>
>
>              Bitte antworten
>                    an
>              ImageJ Interest
>                   Group
>             <[hidden email].
>                   GOV>
>
>
>
>
>
>
> Hi FFT experts,
>
> for filtering images in the Fourier domain, one can paint white
> or black on the power spectrum shown after Process>FFT (to pass
> and remove the selected areas when transforming back).
>
> The power spectrum has inversion symmetry.
> Currently, one has to paint two areas for all off-center
> positions, because they appear twice in the power spectrum.
> For an example, see the two black bars in the bottom left
> image in
>   http://rsb.info.nih.gov/ij/docs/examples/FFT/
>
> My question to the FFT experts: Is there any useful application
> of filtering only on one side of the center?
>
> Otherwise, with a small modification to the ImageJ code I could
> avoid extra work by painting on one side only, having ImageJ do
> the other side.
> (Sometimes I have to filter or block many spatial frequencies,
> then painting them twice makes a difference).
>
> Michael
>
>
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________
>

[Albert Cardona]

Joachim, Michael,

Just a note:

As far as I know, ImageJ's "FFT", which is an FHT as Joachim says,
does not properly replace FFT at all. When trying to rely on it for Cepstrum
and other uses related to registration we realized how much off it is
from a proper FFT: a lot.

We use FFT from jfftw.jar wrapper for native fftw libraries, and in
their absence,
the FFT classes from edu_mines_jtk.jar . Using these, results are as
analitically
expected.

There are a few example of its uses in the mpi.fruitfly package of TrakEM2,
implemented by Stephan Preibisch.

The git repos:
    http://repo.or.cz/w/trakem2.git

The archived source classes:
    http://www.ini.uzh.ch/~acardona/piper.php?file=jars/TrakEM2-src.zip

Albert

--
Albert Cardona
http://www.mcdb.ucla.edu/Research/Hartenstein/acardona

[Michael Schmid]

Hi Albert,

maybe you are right that the problem is the FHT (Hartley
transform), but I think that one should be able to get the FFT
coefficients from an FHT.
Anyhow, it seems to me that this does not work as expected.

For example, the power spectrum of a sum of two sine or
cosine functions with different amplitudes looks like the
square of a power spectrum to me. Twice the amplitude gives
16 times the intensity in the power spectrum, not 4 times as I
would expect.
(I used the "raw" power spectrum, not the log-scaled one)

Below is the macro that I use for testing - it creates a sum of
one-dimensional sin and cos functions.

Further, in the "Complex FFT", a sin(x) function does not give
an imaginary result as I would have expected.
Strange enough, when trying a simple sinusoidal function with
different phaseshifts, I always get a real result (apart from
numeric noise in the imaginary channel).

One more point, but this could be resolved more easily:
With FFT Math>Correlate, when correlating an image with itself
and doing no inverse transformation I would expect to get the
unscaled power spectrum, not the log-scaled one.

Below is the macro that I use for testing - it creates a
one-dimensional sin and cos function.

Maybe Joachim Wesner, the FFT/FHT expert in the group, can say
more about this, whether it is a limitation inherent to the
FHT or some more mundane problem?


Michael
________________________________________________________________
// T E S T   M A C R O
newImage("test", "32-bit Black", 256, 256, 1);
pi = 3.1415926536;
f1 = 1*2*pi/256;
f2 = 2*2*pi/256;

for (x=0; x<255; x++) {
   //v = sin(f1*x + pi/8);
   v = sin(f1*x)+0.5*cos(f2*x);
   setPixel(x, 0, v);
}
makeRectangle(0, 0, 256, 1);
run("Copy");
for (y=1; y<256; y++) {
   makeRectangle(0, y, 256, 1);
  run("Paste");
}
run("Select None");

run("FFT Options...", "fft raw fast complex");
run("FD Math...", "image1=test operation=Correlate image2=test  
result=PowerSpectrum");


________________________________________________________________

On 12 Dec 2007, at 23:00, Albert Cardona wrote:

> Joachim, Michael,
>
> Just a note:
>
> As far as I know, ImageJ's "FFT", which is an FHT as Joachim says,
> does not properly replace FFT at all. When trying to rely on it for  
> Cepstrum
> and other uses related to registration we realized how much off it is
> from a proper FFT: a lot.
>
> We use FFT from jfftw.jar wrapper for native fftw libraries, and in  
> their absence,
> the FFT classes from edu_mines_jtk.jar . Using these, results are  
> as analitically
> expected.
>
> There are a few example of its uses in the mpi.fruitfly package of  
> TrakEM2,
> implemented by Stephan Preibisch.
>
> The git repos:
>    http://repo.or.cz/w/trakem2.git
>
> The archived source classes:
>    http://www.ini.uzh.ch/~acardona/piper.php?file=jars/TrakEM2-src.zip
>
> Albert
>
> --
> Albert Cardona
> http://www.mcdb.ucla.edu/Research/Hartenstein/acardona

[Joachim Wesner]

Hi Michael, Hi others,

as I´m unfortunatelly busy with preparing a company presentation till next
monday I cannot look further into this
issue instantelly (even if I would like to), but plan to attack it next
week

Actually, FHT vs. FFT is only another way of rearranging the complex result
of a real to complex FFT
and somehow redefining what "negative" frequencies mean. The complex FFT
extension I did basically does
2 FHTs and unscrambles the result so that it should be equivalent to a real
complex FFT. I.e. in most cases
the difference  *should* be only in the relative order of 1e-6 (rounding
errors) or so. (IIRC the "trick" is to calculate
the sum and difference of negative and positive "FHT frequencies" to get
what would be the FFT real and imag part.)

However I have to admit that I personally regularly only use a plugin of
mine that has these extensions as a private copy
and does not rely on the IJ built in version (even if I did thorough(?)
testing before Wayne added the code), so I can
in the moment not say what the recent status of the bult in version is. Yet
I´m quite confident that the above mentioned
"unscrambling" principle works as should be and does indeed give results in
agreement with a true FFT within about 1e-6
as it should be, used it a lot.

I will play around with your macros and others to test. More soon!

"Sorry for any inconvenience" ;-))

Mit freundlichen Grüßen / Best regards

Joachim Wesner
Projektleiter Optik Technologiesysteme

Ernst Leitz Strasse 17-37 | 35578 Wetzlar (Germany)
Tel.  [phone] | Fax [phone]

____________________________________________

Leica Microsystems CMS GmbH | GmbH mit Sitz in Wetzlar | Amtsgericht
Wetzlar  HRB 2432
Geschäftsführer: Dr. Martin Haase | Colin Davis | Dr. Wolf-Otto Reuter


                                                                           
             Michael Schmid                                                
             <[hidden email]                                            
             N.AC.AT>                                                   An
             Gesendet von:              [hidden email]                
             ImageJ Interest                                         Kopie
             Group                                                        
             <[hidden email].                                       Thema
             GOV>                       Re: Antwort: FFT-Filtering - are  
                                        non-symmetric masks useful?        
                                                                           
             13.12.2007 14:20                                              
                                                                           
                                                                           
              Bitte antworten                                              
                    an                                                    
              ImageJ Interest                                              
                   Group                                                  
             <[hidden email].                                            
                   GOV>                                                    
                                                                           
                                                                           




Hi Albert,

maybe you are right that the problem is the FHT (Hartley
transform), but I think that one should be able to get the FFT
coefficients from an FHT.
Anyhow, it seems to me that this does not work as expected.

For example, the power spectrum of a sum of two sine or
cosine functions with different amplitudes looks like the
square of a power spectrum to me. Twice the amplitude gives
16 times the intensity in the power spectrum, not 4 times as I
would expect.
(I used the "raw" power spectrum, not the log-scaled one)

Below is the macro that I use for testing - it creates a sum of
one-dimensional sin and cos functions.

Further, in the "Complex FFT", a sin(x) function does not give
an imaginary result as I would have expected.
Strange enough, when trying a simple sinusoidal function with
different phaseshifts, I always get a real result (apart from
numeric noise in the imaginary channel).

One more point, but this could be resolved more easily:
With FFT Math>Correlate, when correlating an image with itself
and doing no inverse transformation I would expect to get the
unscaled power spectrum, not the log-scaled one.

Below is the macro that I use for testing - it creates a
one-dimensional sin and cos function.

Maybe Joachim Wesner, the FFT/FHT expert in the group, can say
more about this, whether it is a limitation inherent to the
FHT or some more mundane problem?


Michael
________________________________________________________________
// T E S T   M A C R O
newImage("test", "32-bit Black", 256, 256, 1);
pi = 3.1415926536;
f1 = 1*2*pi/256;
f2 = 2*2*pi/256;

for (x=0; x<255; x++) {
   //v = sin(f1*x + pi/8);
   v = sin(f1*x)+0.5*cos(f2*x);
   setPixel(x, 0, v);
}
makeRectangle(0, 0, 256, 1);
run("Copy");
for (y=1; y<256; y++) {
   makeRectangle(0, y, 256, 1);
  run("Paste");
}
run("Select None");

run("FFT Options...", "fft raw fast complex");
run("FD Math...", "image1=test operation=Correlate image2=test
result=PowerSpectrum");


________________________________________________________________

On 12 Dec 2007, at 23:00, Albert Cardona wrote:

> Joachim, Michael,
>
> Just a note:
>
> As far as I know, ImageJ's "FFT", which is an FHT as Joachim says,
> does not properly replace FFT at all. When trying to rely on it for
> Cepstrum
> and other uses related to registration we realized how much off it is
> from a proper FFT: a lot.
>
> We use FFT from jfftw.jar wrapper for native fftw libraries, and in
> their absence,
> the FFT classes from edu_mines_jtk.jar . Using these, results are
> as analitically
> expected.
>
> There are a few example of its uses in the mpi.fruitfly package of
> TrakEM2,
> implemented by Stephan Preibisch.
>
> The git repos:
>    http://repo.or.cz/w/trakem2.git
>
> The archived source classes:
>    http://www.ini.uzh.ch/~acardona/piper.php?file=jars/TrakEM2-src.zip
>
> Albert
>
> --
> Albert Cardona
> http://www.mcdb.ucla.edu/Research/Hartenstein/acardona

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

[Robert Dougherty]

Michael, Albert,  and Joachim,

Maybe something in the link below will help.  As I recall, the .doc  
and the .ppt both present the conversions.  When the FHT was invented  
there was a lot of discussion about its pros and cons vs. the FFT,  
but I think the current understanding is that there is no important  
difference.
http://imagejdocu.tudor.lu/Members/ajahnen/ 
conference_proceedings_2006/Robert%20Dougherty

Bob

On Dec 13, 2007, at 9:53 AM, Joachim Wesner wrote:

> Hi Michael, Hi others,
>
> as I´m unfortunatelly busy with preparing a company presentation  
> till next
> monday I cannot look further into this
> issue instantelly (even if I would like to), but plan to attack it  
> next
> week
>
> Actually, FHT vs. FFT is only another way of rearranging the  
> complex result
> of a real to complex FFT
> and somehow redefining what "negative" frequencies mean. The  
> complex FFT
> extension I did basically does
> 2 FHTs and unscrambles the result so that it should be equivalent  
> to a real
> complex FFT. I.e. in most cases
> the difference  *should* be only in the relative order of 1e-6  
> (rounding
> errors) or so. (IIRC the "trick" is to calculate
> the sum and difference of negative and positive "FHT frequencies"  
> to get
> what would be the FFT real and imag part.)
>
> However I have to admit that I personally regularly only use a  
> plugin of
> mine that has these extensions as a private copy
> and does not rely on the IJ built in version (even if I did thorough
> (?)
> testing before Wayne added the code), so I can
> in the moment not say what the recent status of the bult in version  
> is. Yet
> I´m quite confident that the above mentioned
> "unscrambling" principle works as should be and does indeed give  
> results in
> agreement with a true FFT within about 1e-6
> as it should be, used it a lot.
>
> I will play around with your macros and others to test. More soon!
>
> "Sorry for any inconvenience" ;-))
>
> Mit freundlichen Grüßen / Best regards
>
> Joachim Wesner
> Projektleiter Optik Technologiesysteme
>
> Ernst Leitz Strasse 17-37 | 35578 Wetzlar (Germany)
> Tel.  [phone] | Fax [phone]
>
> ____________________________________________
>
> Leica Microsystems CMS GmbH | GmbH mit Sitz in Wetzlar | Amtsgericht
> Wetzlar  HRB 2432
> Geschäftsführer: Dr. Martin Haase | Colin Davis | Dr. Wolf-Otto Reuter
>
>
>
>              Michael Schmid
>              <[hidden email]
>              
> N.AC.AT>                                                   An
>              Gesendet von:              [hidden email]
>              ImageJ  
> Interest                                         Kopie
>              Group
>              
> <[hidden email].                                       Thema
>              GOV>                       Re: Antwort: FFT-Filtering  
> - are
>                                         non-symmetric masks useful?
>
>              13.12.2007 14:20
>
>
>               Bitte antworten
>                     an
>               ImageJ Interest
>                    Group
>              <[hidden email].
>                    GOV>
>
>
>
>
>
>
> Hi Albert,
>
> maybe you are right that the problem is the FHT (Hartley
> transform), but I think that one should be able to get the FFT
> coefficients from an FHT.
> Anyhow, it seems to me that this does not work as expected.
>
> For example, the power spectrum of a sum of two sine or
> cosine functions with different amplitudes looks like the
> square of a power spectrum to me. Twice the amplitude gives
> 16 times the intensity in the power spectrum, not 4 times as I
> would expect.
> (I used the "raw" power spectrum, not the log-scaled one)
>
> Below is the macro that I use for testing - it creates a sum of
> one-dimensional sin and cos functions.
>
> Further, in the "Complex FFT", a sin(x) function does not give
> an imaginary result as I would have expected.
> Strange enough, when trying a simple sinusoidal function with
> different phaseshifts, I always get a real result (apart from
> numeric noise in the imaginary channel).
>
> One more point, but this could be resolved more easily:
> With FFT Math>Correlate, when correlating an image with itself
> and doing no inverse transformation I would expect to get the
> unscaled power spectrum, not the log-scaled one.
>
> Below is the macro that I use for testing - it creates a
> one-dimensional sin and cos function.
>
> Maybe Joachim Wesner, the FFT/FHT expert in the group, can say
> more about this, whether it is a limitation inherent to the
> FHT or some more mundane problem?
>
>
> Michael
> ________________________________________________________________
> // T E S T   M A C R O
> newImage("test", "32-bit Black", 256, 256, 1);
> pi = 3.1415926536;
> f1 = 1*2*pi/256;
> f2 = 2*2*pi/256;
>
> for (x=0; x<255; x++) {
>    //v = sin(f1*x + pi/8);
>    v = sin(f1*x)+0.5*cos(f2*x);
>    setPixel(x, 0, v);
> }
> makeRectangle(0, 0, 256, 1);
> run("Copy");
> for (y=1; y<256; y++) {
>    makeRectangle(0, y, 256, 1);
>   run("Paste");
> }
> run("Select None");
>
> run("FFT Options...", "fft raw fast complex");
> run("FD Math...", "image1=test operation=Correlate image2=test
> result=PowerSpectrum");
>
>
> ________________________________________________________________
>
> On 12 Dec 2007, at 23:00, Albert Cardona wrote:
>
>> Joachim, Michael,
>>
>> Just a note:
>>
>> As far as I know, ImageJ's "FFT", which is an FHT as Joachim says,
>> does not properly replace FFT at all. When trying to rely on it for
>> Cepstrum
>> and other uses related to registration we realized how much off it is
>> from a proper FFT: a lot.
>>
>> We use FFT from jfftw.jar wrapper for native fftw libraries, and in
>> their absence,
>> the FFT classes from edu_mines_jtk.jar . Using these, results are
>> as analitically
>> expected.
>>
>> There are a few example of its uses in the mpi.fruitfly package of
>> TrakEM2,
>> implemented by Stephan Preibisch.
>>
>> The git repos:
>>    http://repo.or.cz/w/trakem2.git
>>
>> The archived source classes:
>>    http://www.ini.uzh.ch/~acardona/piper.php?file=jars/TrakEM2- 
>> src.zip
>>
>> Albert
>>
>> --
>> Albert Cardona
>> http://www.mcdb.ucla.edu/Research/Hartenstein/acardona
>
>
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________
>

Robert Dougherty, Ph.D.
President, OptiNav, Inc.
10900 NE 8th St, Suite 900
Bellevue, WA 98004
Tel. [phone]
FAX [phone]
www.optinav.com
[hidden email]

[Michael Schmid]

Hi,

for all who want to have a closer look at the values of the
FHT, Complex FFT, or Raw Power Spectrum -
an improved version of the Pixel Inspector is online:

   http://imagejdocu.tudor.lu/imagej-documentation-wiki/plugins/ 
pixel_inspector

It can also display the high pixel values typical for these
image types.

Michael
________________________________________________________________

On 14 Dec 2007, at 00:25, Robert Dougherty wrote:

> Michael, Albert,  and Joachim,
>
> Maybe something in the link below will help.  As I recall, the .doc  
> and the .ppt both present the conversions.  When the FHT was  
> invented there was a lot of discussion about its pros and cons vs.  
> the FFT, but I think the current understanding is that there is no  
> important difference.
> http://imagejdocu.tudor.lu/Members/ajahnen/ 
> conference_proceedings_2006/Robert%20Dougherty
>
> Bob
>
> On Dec 13, 2007, at 9:53 AM, Joachim Wesner wrote:
>
>> Hi Michael, Hi others,
>>
>> as I´m unfortunatelly busy with preparing a company presentation  
>> till next
>> monday I cannot look further into this
>> issue instantelly (even if I would like to), but plan to attack it  
>> next
>> week
>>
>> Actually, FHT vs. FFT is only another way of rearranging the  
>> complex result
>> of a real to complex FFT
>> and somehow redefining what "negative" frequencies mean. The  
>> complex FFT
>> extension I did basically does
>> 2 FHTs and unscrambles the result so that it should be equivalent  
>> to a real
>> complex FFT. I.e. in most cases
>> the difference  *should* be only in the relative order of 1e-6  
>> (rounding
>> errors) or so. (IIRC the "trick" is to calculate
>> the sum and difference of negative and positive "FHT frequencies"  
>> to get
>> what would be the FFT real and imag part.)
>>
>> However I have to admit that I personally regularly only use a  
>> plugin of
>> mine that has these extensions as a private copy
>> and does not rely on the IJ built in version (even if I did  
>> thorough(?)
>> testing before Wayne added the code), so I can
>> in the moment not say what the recent status of the bult in  
>> version is. Yet
>> I´m quite confident that the above mentioned
>> "unscrambling" principle works as should be and does indeed give  
>> results in
>> agreement with a true FFT within about 1e-6
>> as it should be, used it a lot.
>>
>> I will play around with your macros and others to test. More soon!
>>
>> "Sorry for any inconvenience" ;-))
>>
>> Mit freundlichen Grüßen / Best regards
>>
>> Joachim Wesner
>> Projektleiter Optik Technologiesysteme
>>
>> Ernst Leitz Strasse 17-37 | 35578 Wetzlar (Germany)
>> Tel.  [phone] | Fax [phone]
>>
>> ____________________________________________
>>
>> Leica Microsystems CMS GmbH | GmbH mit Sitz in Wetzlar | Amtsgericht
>> Wetzlar  HRB 2432
>> Geschäftsführer: Dr. Martin Haase | Colin Davis | Dr. Wolf-Otto  
>> Reuter
>>
>>
>>
>>              Michael Schmid
>>              <[hidden email]
>>              
>> N.AC.AT>                                                   An
>>              Gesendet von:              [hidden email]
>>              ImageJ  
>> Interest                                         Kopie
>>              Group
>>              
>> <[hidden email].                                       Thema
>>              GOV>                       Re: Antwort: FFT-Filtering  
>> - are
>>                                         non-symmetric masks useful?
>>
>>              13.12.2007 14:20
>>
>>
>>               Bitte antworten
>>                     an
>>               ImageJ Interest
>>                    Group
>>              <[hidden email].
>>                    GOV>
>>
>>
>>
>>
>>
>>
>> Hi Albert,
>>
>> maybe you are right that the problem is the FHT (Hartley
>> transform), but I think that one should be able to get the FFT
>> coefficients from an FHT.
>> Anyhow, it seems to me that this does not work as expected.
>>
>> For example, the power spectrum of a sum of two sine or
>> cosine functions with different amplitudes looks like the
>> square of a power spectrum to me. Twice the amplitude gives
>> 16 times the intensity in the power spectrum, not 4 times as I
>> would expect.
>> (I used the "raw" power spectrum, not the log-scaled one)
>>
>> Below is the macro that I use for testing - it creates a sum of
>> one-dimensional sin and cos functions.
>>
>> Further, in the "Complex FFT", a sin(x) function does not give
>> an imaginary result as I would have expected.
>> Strange enough, when trying a simple sinusoidal function with
>> different phaseshifts, I always get a real result (apart from
>> numeric noise in the imaginary channel).
>>
>> One more point, but this could be resolved more easily:
>> With FFT Math>Correlate, when correlating an image with itself
>> and doing no inverse transformation I would expect to get the
>> unscaled power spectrum, not the log-scaled one.
>>
>> Below is the macro that I use for testing - it creates a
>> one-dimensional sin and cos function.
>>
>> Maybe Joachim Wesner, the FFT/FHT expert in the group, can say
>> more about this, whether it is a limitation inherent to the
>> FHT or some more mundane problem?
>>
>>
>> Michael
>> ________________________________________________________________
>> // T E S T   M A C R O
>> newImage("test", "32-bit Black", 256, 256, 1);
>> pi = 3.1415926536;
>> f1 = 1*2*pi/256;
>> f2 = 2*2*pi/256;
>>
>> for (x=0; x<255; x++) {
>>    //v = sin(f1*x + pi/8);
>>    v = sin(f1*x)+0.5*cos(f2*x);
>>    setPixel(x, 0, v);
>> }
>> makeRectangle(0, 0, 256, 1);
>> run("Copy");
>> for (y=1; y<256; y++) {
>>    makeRectangle(0, y, 256, 1);
>>   run("Paste");
>> }
>> run("Select None");
>>
>> run("FFT Options...", "fft raw fast complex");
>> run("FD Math...", "image1=test operation=Correlate image2=test
>> result=PowerSpectrum");
>>
>>
>> ________________________________________________________________
>>
>> On 12 Dec 2007, at 23:00, Albert Cardona wrote:
>>
>>> Joachim, Michael,
>>>
>>> Just a note:
>>>
>>> As far as I know, ImageJ's "FFT", which is an FHT as Joachim says,
>>> does not properly replace FFT at all. When trying to rely on it for
>>> Cepstrum
>>> and other uses related to registration we realized how much off  
>>> it is
>>> from a proper FFT: a lot.
>>>
>>> We use FFT from jfftw.jar wrapper for native fftw libraries, and in
>>> their absence,
>>> the FFT classes from edu_mines_jtk.jar . Using these, results are
>>> as analitically
>>> expected.
>>>
>>> There are a few example of its uses in the mpi.fruitfly package of
>>> TrakEM2,
>>> implemented by Stephan Preibisch.
>>>
>>> The git repos:
>>>    http://repo.or.cz/w/trakem2.git
>>>
>>> The archived source classes:
>>>    http://www.ini.uzh.ch/~acardona/piper.php?file=jars/TrakEM2- 
>>> src.zip
>>>
>>> Albert
>>>
>>> --
>>> Albert Cardona
>>> http://www.mcdb.ucla.edu/Research/Hartenstein/acardona
>>
>>
>>
>> _____________________________________________________________________
>> _
>> This email has been scanned by the MessageLabs Email Security System.
>> For more information please visit http://www.messagelabs.com/email
>> _____________________________________________________________________
>> _
>>
>
> Robert Dougherty, Ph.D.
> President, OptiNav, Inc.
> 10900 NE 8th St, Suite 900
> Bellevue, WA 98004
> Tel. [phone]
> FAX [phone]
> www.optinav.com
> [hidden email]