ImageMagick Now Has Fourier Transforms

[jhack]

There's an error compiling the version 6.6.7-5.

The error is in the fourier.c file on line 537 : phase=carg(fourier);

I think I solved it this way (changing line 66)
#define carg(z) (atan2(cimag(z[1]),creal(z[0]))) => #define carg(z) (atan2(cimag(z),creal(z)))

It seems to work. There is only one more problem: it doesn't seem to use hdri when using fourier. It only works when I'm doing the roundtrip (convert lena.png -fft -ift lena_roundtrip_hdri.png). With the compare program I get the same results of the test on page http://www.imagemagick.org/Usage/fourier/.
If I divide the image (either in magnitude/phase or real/imaginary) and recompose the two obtained images with ift and compare them I obtain the same results of the non-hdri version.
Does it make any sense?

Thanks
jhack

[fmw42]

There's an error compiling the version 6.6.7-5.

The error is in the fourier.c file on line 537 : phase=carg(fourier);

I think I solved it this way (changing line 66)
#define carg(z) (atan2(cimag(z[1]),creal(z[0]))) => #define carg(z) (atan2(cimag(z),creal(z)))

It seems to work. There is only one more problem: it doesn't seem to use hdri when using fourier. It only works when I'm doing the roundtrip (convert lena.png -fft -ift lena_roundtrip_hdri.png). With the compare program I get the same results of the test on page http://www.imagemagick.org/Usage/fourier/.
If I divide the image (either in magnitude/phase or real/imaginary) and recompose the two obtained images with ift and compare them I obtain the same results of the non-hdri version.
Does it make any sense?

Thanks
jhack

Please post the Qlevel in your IM release. Post your results (magnitude and phase and roundtrip and run a compare of your round trip with the original) -- a link to those pictures.



Results should look as follows:

Mag/Phase:

convert square31.png -fft square31_fft_mp.png
convert square31_fft_mp-0.png -auto-level -evaluate log 1000 square31_fft_spectrum1000.png

Phase:


Spectrum from magnitude:

[magick]

We have a patch in ImageMagick 6.6.7-6 Beta (available by sometime tomorrow) to fix the problem you reported with carg(). Thanks.

[fmw42]

We have a patch in ImageMagick 6.6.7-6 Beta (available by sometime tomorrow) to fix the problem you reported with carg(). Thanks.

Magick: Thanks for moving these reports.

But Are you able to reproduce this error using my test image above? Though I am still having trouble on my Mac OSX Tiger with MacPorts delegates, you said you had confirmed that FFT was working on your Intel Mac (with these images) when we tested under 6.6.7.3?

Do you need me to do any testing?

[magick]

But Are you able to reproduce this error using my test image above?

What error? What commands should we use? And what are we looking for to ensure they are behaving properly?

[fmw42]

What error? What commands should we use? And what are we looking for to ensure they are behaving properly?

You said you had a fix - something about carg(). I was puzzled as to what or why it was broken and if it shows up in any image fft. The code has not changed for quite a while and results (apart from my recent complaint about the phase that you cannot reproduce) seems to indicate that nothing like this should be wrong. Also the user does not identify his platform.

My commands above with the square31.png test image is a good set to start with. Make sure your results look like mine above. Then do a round trip and compare to the original

convert square31.png -fft square31_fft_mp.png
convert square31_fft_mp-0.png -auto-level -evaluate log 1000 square31_fft_spectrum1000.png

convert square31.png -fft -ift square31_rt.png
compare -metric rmse square31.png square31_rt.png null:

also

convert square31_fft_mp-0.png square31_fft_mp-1.png -ift square31_fft_mp_ift.png
compare -metric rmse square31.png square31_fft_mp_ift.png null:

compare results should be something like:

either

47.5618 (0.000725746)

or

0 (0)

depending upon Q16 non-hdri vs Q16 HDRI.


I will try to recompile my system so as not to use MacPorts so I don't get that b/w overshoot problem in the phase image and see what happens in 6.6.7.5 when I get a chance later today. But my results are a bit suspect from our recent discussion for IM 6.6.7.3 about PowerPC vs Intel and MacPorts vs no MacPorts, etc. So I was curious if you had done the above tests.

Fred

[fmw42]

IM 6.6.7.5 Q16 Mac OSX Tiger compiled with IM and all delegates in /usr/local/bin (No MacPorts)

I am now getting bad results for the phase image whether I use HDRI or not contrary to my recent results with 6.6.7.3

convert -version
Version: ImageMagick 6.6.7-5 2011-02-07 Q16 http://www.imagemagick.org
Copyright: Copyright (C) 1999-2011 ImageMagick Studio LLC
Features: HDRI

convert square31.png -fft square31_ffthdri_6675_no_macports_no_openmp.png

square31_ffthdri_6675_no_macports_no_openmp-1.png:


Likewise without HDRI

convert square31.png -fft square31_fft_6675_no_macports_no_openmp.png

square31_ffthdri_6675_no_macports_no_openmp-1.png:



I also get the same results in HDRI with PFM or MIFF format output from -fft

whereas a proper result should look like this from 6.6.7.3:

square31_fft_6673_no_macports_no_openmp-1.png:


Magick can you verify this. Thanks

Fred

[magick]

Fred, this looks like the same problem we reviewed before. We cannot reproduce it. We tried it under Mac OS X Intel, Fedora 14, and CentOS 5.5 and we get the expected results as documented in your posting.

[fmw42]

Fred, this looks like the same problem we reviewed before. We cannot reproduce it. We tried it under Mac OS X Intel, Fedora 14, and CentOS 5.5 and we get the expected results as documented in your posting.

Magick,

Thanks.

I just realized that though I changed my ./configuration file I forgot to change my .profile to avoid MacPorts. So my results above are probably still the MacPorts issue on PowerPC.

I have just installed IM 6.6.7.6 and will test again properly this time.

Sorry for the false alarm.

Fred

[fmw42]

OK, now with MacPorts properly deactivated and using IM 6.6.7.6 Q16 and all delegates from /usr/local/bin, I get the correct results for the phase from the square31.png image for both non-hdri and hdri.

sorry again for the false alarm

Fred

[jhack]

Hi people!
I missed something. I tried compiling the last two versions (6.6.7-4 and 6.6.7-5) and get the same results on winXP pro SP3.

What about MacPorts? Should I disable it? How?

Thanks
jhack

[NicolasRobidoux]

... get the same results on winXP pro SP3.

What about MacPorts? Should I disable it? How?

jhack:

MacPorts is an "easier" way to install *nix tools on Apple computers running OSX: http://www.macports.org

It can't be affecting Windows (or linux) results. (Although, of course, if you happen to be using the same IM version as MacPorts, you most likely have the same bugs.)

What was going on was that Fred's MacPort install was overriding his self-compiled installation from source (on his Mac), and consequently he was not using the IM version he thought he was. The same issue can happen with, say, Ubuntu linux: The version installed by the Ubuntu package manager (synaptic) will override the one you compile yourself unless you manually override the package manager (which is not hard:

Code: Select all

sudo make install

if you are willing to live a little dangerously---I never had a problem with this technique).

[jhack]

Ok!
So I still don't understand how to solve my problem.

I tried the lines you wrote before, and the results are....:

- convert square31.png -fft square31_fft_mp.png

square31_fft_mp-0.png


square31_fft_mp-1.png



- convert square31_fft_mp-0.png -auto-level -evaluate log 1000 square31_fft_spectrum1000.png

square31_fft_spectrum1000.png



- convert square31.png -fft -ift square31_rt.png

square31_rt.png



- convert square31_fft_mp-0.png square31_fft_mp-1.png -ift square31_fft_mp_ift.png

square31_fft_mp_ift.png



and the compare results are:

- compare -metric rmse square31.png square31_rt.png null:
0 (0)

- compare -metric rmse square31.png square31_fft_mp_ift.png null:
47.5618 (0.000725746)

My version is:
convert -version
Version: ImageMagick 6.6.7-4 2011-01-29 Q16 http://www.imagemagick.org
Copyright: Copyright (C) 1999-2011 ImageMagick Studio LLC
Features: HDRI


As you can see doing the roundtrip the hdri seems to be used. When I use the intermediate step decomposing the images and composing them back it doesn't seem to use hdri.

Do you need any other information?

Thanks!
jhack

[fmw42]

As you can see doing the roundtrip the hdri seems to be used. When I use the intermediate step decomposing the images and composing them back it doesn't seem to use hdri.

Thanks for running the tests.

Your images and compare results are right on as expected.

HDRI is used if you compiled IM as HDRI (recommend Q16). The problem is that saving the images as PNG in HDRI has some loss of information as it does not save as floating point (loses fractions and negative values). If you want to save intermediate images for magnitude/phase or real/imaginary, then use PFM format (or MIFF or TIFF). The latter two might(?) need the addition of

-define quantum:format=floating-point

that is why I usually use PFM format for any intermediate images in the FFT domain. However once you get back to the spatial domain after doing IFT, you can save back to PNG

Note PFM, MIFF, TIFF all support multiframe images. So the results will be two frames in the one output image (not two images -0 and -1)

Try

convert square31.png -fft square31_fft_mp.pfm

convert square31_fft_mp.pfm -ift square31_fft_mp_ift.png
or
convert square31_fft_mp.pfm[0] square31_fft_mp.pfm[1] -ift square31_fft_mp_ift.png

then
compare -metric rmse square31.png square31_fft_mp_ift.png null:



see http://www.fmwconcepts.com/imagemagick/ ... tml#im_fft and http://www.imagemagick.org/Usage/fourie ... ath/#intro

Out of curiosity, what platform are you doing this on? If Mac, is it INTEL or PowerPC? And if Mac, did you use MacPorts to install FFTW and/or IM?

[jhack]

Yes you're right!
With pfm works.

I work on windows xp pro sp3.

Thank you very much!
I learnt something new!

Bye
jhack