Legacy ImageMagick Discussions Archive

Use https://github.com/ImageMagick/ImageMagick/discussions instead.
https://imagemagick.com/discourse-server/

FFT inconsistancy

https://imagemagick.com/discourse-server/viewtopic.php?t=19705

Page 1 of 1

FFT inconsistancy

Posted: 2011-10-25T22:13:29-07:00
by anthony
I am seeing a inconsistancy in FFT output.

Code: Select all

convert -size 4x4 xc:red -fft  txt:
# ImageMagick pixel enumeration: 4,4,65535,rgb
0,0: (    0,    0,    0)  #000000000000  black
1,0: (    0,    0,    0)  #000000000000  black
2,0: (    0,    0,    0)  #000000000000  black
3,0: (    0,    0,    0)  #000000000000  black
0,1: (    0,    0,    0)  #000000000000  black
1,1: (    0,    0,    0)  #000000000000  black
2,1: (    0,    0,    0)  #000000000000  black
3,1: (    0,    0,    0)  #000000000000  black
0,2: (    0,    0,    0)  #000000000000  black
1,2: (    0,    0,    0)  #000000000000  black
2,2: (65535,    0,    0)  #FFFF00000000  red
3,2: (    0,    0,    0)  #000000000000  black
0,3: (    0,    0,    0)  #000000000000  black
1,3: (    0,    0,    0)  #000000000000  black
2,3: (    0,    0,    0)  #000000000000  black
3,3: (    0,    0,    0)  #000000000000  black
# ImageMagick pixel enumeration: 4,4,65535,rgb
0,0: (32768,32768,32768)  #800080008000  rgb(50.0008%,50.0008%,50.0008%)
1,0: (32768,32768,32768)  #800080008000  rgb(50.0008%,50.0008%,50.0008%)
2,0: (32768,32768,32768)  #800080008000  rgb(50.0008%,50.0008%,50.0008%)
3,0: (32768,32768,32768)  #800080008000  rgb(50.0008%,50.0008%,50.0008%)
0,1: (32768,32768,32768)  #800080008000  rgb(50.0008%,50.0008%,50.0008%)
1,1: (32768,32768,32768)  #800080008000  rgb(50.0008%,50.0008%,50.0008%)
2,1: (32768,32768,32768)  #800080008000  rgb(50.0008%,50.0008%,50.0008%)
3,1: (32768,32768,32768)  #800080008000  rgb(50.0008%,50.0008%,50.0008%)
0,2: (32768,32768,32768)  #800080008000  rgb(50.0008%,50.0008%,50.0008%)
1,2: (32768,32768,32768)  #800080008000  rgb(50.0008%,50.0008%,50.0008%)
2,2: (32768,32768,32768)  #800080008000  rgb(50.0008%,50.0008%,50.0008%)
3,2: (32768,32768,32768)  #800080008000  rgb(50.0008%,50.0008%,50.0008%)
0,3: (32768,32768,32768)  #800080008000  rgb(50.0008%,50.0008%,50.0008%)
1,3: (32768,32768,32768)  #800080008000  rgb(50.0008%,50.0008%,50.0008%)
2,3: (32768,32768,32768)  #800080008000  rgb(50.0008%,50.0008%,50.0008%)
3,3: (43198,32768,32768)  #A8BE80008000  rgb(65.9159%,50.0008%,50.0008%)
Look at the last pixel of the phase image. I believe that should also be a pure gray (zero phase) color.

Though I doubt this would have much effect in real FFT processing seeing as the rigtht side of the image is ignored when the images are re-combined (IFT). Also that the frequency has a black (no amplitude) magnitude. But it does seem to imply that either something is wrong (a bug), or some unknown action is being preformed (knowledge).

Re: FFT inconsistancy

Posted: 2011-10-26T04:19:22-07:00
by magick
We cannot reproduce the problem you reported. We're using ImageMagick 6.7.3-2 and ImageMagick 7.0.0-0 with fftw3-3.2.2-3:

Code: Select all

-> convert -size 4x4 xc:red -fft  txt:
# ImageMagick pixel enumeration: 4,4,65535,rgb
0,0: (    0,    0,    0)  #000000000000  black
1,0: (    0,    0,    0)  #000000000000  black
2,0: (    0,    0,    0)  #000000000000  black
3,0: (    0,    0,    0)  #000000000000  black
0,1: (    0,    0,    0)  #000000000000  black
1,1: (    0,    0,    0)  #000000000000  black
2,1: (    0,    0,    0)  #000000000000  black
3,1: (    0,    0,    0)  #000000000000  black
0,2: (    0,    0,    0)  #000000000000  black
1,2: (    0,    0,    0)  #000000000000  black
2,2: (65535,    0,    0)  #FFFF00000000  red
3,2: (    0,    0,    0)  #000000000000  black
0,3: (    0,    0,    0)  #000000000000  black
1,3: (    0,    0,    0)  #000000000000  black
2,3: (    0,    0,    0)  #000000000000  black
3,3: (    0,    0,    0)  #000000000000  black
# ImageMagick pixel enumeration: 4,4,65535,rgb
0,0: (32768,32768,32768)  #800080008000  rgb(50.0008%,50.0008%,50.0008%)
1,0: (32768,32768,32768)  #800080008000  rgb(50.0008%,50.0008%,50.0008%)
2,0: (32768,32768,32768)  #800080008000  rgb(50.0008%,50.0008%,50.0008%)
3,0: (32768,32768,32768)  #800080008000  rgb(50.0008%,50.0008%,50.0008%)
0,1: (32768,32768,32768)  #800080008000  rgb(50.0008%,50.0008%,50.0008%)
1,1: (32768,32768,32768)  #800080008000  rgb(50.0008%,50.0008%,50.0008%)
2,1: (32768,32768,32768)  #800080008000  rgb(50.0008%,50.0008%,50.0008%)
3,1: (32768,32768,32768)  #800080008000  rgb(50.0008%,50.0008%,50.0008%)
0,2: (32768,32768,32768)  #800080008000  rgb(50.0008%,50.0008%,50.0008%)
1,2: (32768,32768,32768)  #800080008000  rgb(50.0008%,50.0008%,50.0008%)
2,2: (32768,32768,32768)  #800080008000  rgb(50.0008%,50.0008%,50.0008%)
3,2: (32768,32768,32768)  #800080008000  rgb(50.0008%,50.0008%,50.0008%)
0,3: (32768,32768,32768)  #800080008000  rgb(50.0008%,50.0008%,50.0008%)
1,3: (32768,32768,32768)  #800080008000  rgb(50.0008%,50.0008%,50.0008%)
2,3: (32768,32768,32768)  #800080008000  rgb(50.0008%,50.0008%,50.0008%)
3,3: (32768,32768,32768)  #800080008000  rgb(50.0008%,50.0008%,50.0008%)

Re: FFT inconsistancy

Posted: 2011-10-26T09:57:11-07:00
by fmw42
I cannot reproduce it either. I get the same results as Magick.

Code: Select all

convert -size 4x4 xc:red -fft  txt:
# ImageMagick pixel enumeration: 4,4,65535,rgb
0,0: (    0,    0,    0)  #000000000000  black
1,0: (    0,    0,    0)  #000000000000  black
2,0: (    0,    0,    0)  #000000000000  black
3,0: (    0,    0,    0)  #000000000000  black
0,1: (    0,    0,    0)  #000000000000  black
1,1: (    0,    0,    0)  #000000000000  black
2,1: (    0,    0,    0)  #000000000000  black
3,1: (    0,    0,    0)  #000000000000  black
0,2: (    0,    0,    0)  #000000000000  black
1,2: (    0,    0,    0)  #000000000000  black
2,2: (65535,    0,    0)  #FFFF00000000  red
3,2: (    0,    0,    0)  #000000000000  black
0,3: (    0,    0,    0)  #000000000000  black
1,3: (    0,    0,    0)  #000000000000  black
2,3: (    0,    0,    0)  #000000000000  black
3,3: (    0,    0,    0)  #000000000000  black
# ImageMagick pixel enumeration: 4,4,65535,rgb
0,0: (32768,32768,32768)  #800080008000  rgb(50.0008%,50.0008%,50.0008%)
1,0: (32768,32768,32768)  #800080008000  rgb(50.0008%,50.0008%,50.0008%)
2,0: (32768,32768,32768)  #800080008000  rgb(50.0008%,50.0008%,50.0008%)
3,0: (32768,32768,32768)  #800080008000  rgb(50.0008%,50.0008%,50.0008%)
0,1: (32768,32768,32768)  #800080008000  rgb(50.0008%,50.0008%,50.0008%)
1,1: (32768,32768,32768)  #800080008000  rgb(50.0008%,50.0008%,50.0008%)
2,1: (32768,32768,32768)  #800080008000  rgb(50.0008%,50.0008%,50.0008%)
3,1: (32768,32768,32768)  #800080008000  rgb(50.0008%,50.0008%,50.0008%)
0,2: (32768,32768,32768)  #800080008000  rgb(50.0008%,50.0008%,50.0008%)
1,2: (32768,32768,32768)  #800080008000  rgb(50.0008%,50.0008%,50.0008%)
2,2: (32768,32768,32768)  #800080008000  rgb(50.0008%,50.0008%,50.0008%)
3,2: (32768,32768,32768)  #800080008000  rgb(50.0008%,50.0008%,50.0008%)
0,3: (32768,32768,32768)  #800080008000  rgb(50.0008%,50.0008%,50.0008%)
1,3: (32768,32768,32768)  #800080008000  rgb(50.0008%,50.0008%,50.0008%)
2,3: (32768,32768,32768)  #800080008000  rgb(50.0008%,50.0008%,50.0008%)
3,3: (32768,32768,32768)  #800080008000  rgb(50.0008%,50.0008%,50.0008%)
However, when using FFTW from MacPorts with IM manually installed in /usr/local/lib, I still get errors in the phase image of image square31.png. This does not happen if both FFTW and IM are in /usr/local/lib

square31.png
Image

Phase from FFTW v3.3 (and previously v3.2.2) in /opt/local/lib (MacPorts) -- NOT CORRECT RESULT
Image

Phase from FFTW v3.2.2 in /usr/local/lib (No MacPorts) -- CORRECT RESULT
Image

This bug still persists in IM 6.7.3.2 Q16 Mac OSX Tiger.

However, the last time I reported this, Magick could not reproduce it.

Anthony, which result do you get?

Fred

Re: FFT inconsistancy

Posted: 2011-10-26T18:19:03-07:00
by anthony
The original problem vanished! but then on the third try reproduced the same fault with the final pixel!
Seems to happen about 50% of the time!

However setting the MAGICK_THREAD_LIMIT environment variable and I can no longer reproduce the final phase pixel fault.

Code: Select all

MAGICK_THREAD_LIMIT=1 convert -size 4x4 xc:red -fft  txt:
Note for non-red images the bug does not deem to happen!

Code: Select all

convert -size 4x4 xc: -fft txt: | tail -1
always returns perfect gray!

Using 'lime' (pure green) instead of red produces random effects in the green value - though it appears to happen less often.
A blue, white, or black image does not have this problem!


Fred... I get the latter (correct) version using...

Code: Select all

convert square31.png -fft -delete 0 show:
convert -version
Version: ImageMagick 6.7.2-10 2011-10-21 Q16 http://www.imagemagick.org
Copyright: Copyright (C) 1999-2011 ImageMagick Studio LLC
Features: OpenMP

and the linux RPM packages...
fftw-3.2.2-4.fc13 A Fast Fourier Transform library
fftw-devel-3.2.2-4.fc13 Headers, libraries and docs for the FFTW library

So I am not using the FFTW v3.3 package.

Re: FFT inconsistancy

Posted: 2011-10-26T19:43:55-07:00
by fmw42
The square31.png phase problem happens with me whether I use FFTW 3.3 or 3.2.2 so long as I have IM in /usr/local/bin and FFTW from MacPorts in /opt/local/bin. When both are in /usr/local/bin, I get the correct result.

Re: FFT inconsistancy

Posted: 2011-10-26T20:12:50-07:00
by anthony
I can tell you that you should ignore the black parts on the right, they are just negated copys of what is on the left.

have you tryed turning off thread. My problem disappears when threading is set to 1

Re: FFT inconsistancy

Posted: 2011-10-26T20:59:00-07:00
by fmw42
anthony wrote:I can tell you that you should ignore the black parts on the right, they are just negated copys of what is on the left.

have you tryed turning off thread. My problem disappears when threading is set to 1

No change, but I did not expect it to make a different as I have only 1 processor and OpenMP is disabled already.


Ignoring the black on the right is not a solution as the white on the left is wrong also.

Re: FFT inconsistancy

Posted: 2011-10-26T22:03:30-07:00
by anthony
I just pointed it out, as by ignoring the right half the results look like image was regularly correct, then going wrong.
It is a typical sign of a OpenMP fault.

But if you have it disabled than that could not be the problem.

Re: FFT inconsistancy

Posted: 2011-10-27T03:27:10-07:00
by magick
We're investigating the possibility of a multi-thread problem (or a bug in libgomp).

Re: FFT inconsistancy

Posted: 2011-12-02T16:24:30-07:00
by fmw42
My issue with processing image square31.png into mag and phase (phase is the problem image) seems to have disappeared (at least for now) when I switched computers from Mac OSX Tiger PPC to Mac OSX Snow Leopard INTEL.
All times are UTC-07:00
Page 1 of 1

Powered by phpBB® Forum Software © phpBB Limited