Page 1 of 1

potential bug using MIFF for FFT in IM 6.4.1-1 Q16-HDRI

Posted: 2008-05-09T17:13:29-07:00
by fmw42
Hi,

I have been testing Sean Burke's FFT and have run into a potential issue using MIFF for storage of the FFT component images (real, imaginary, magnitude and phase) when converting the real and imaginary to phase using -fx. The phase image gets created but has bad values in it. Whereas, if I use PFM for storage, it all works fine. I wanted to inform you of this regarding the MIFF format. Also there are some oddities that I wanted to present and see if you could clarify them for me.

Here is what I have done:

I started with the following image:

Image

I then did an FFT to create the real and imaginary components. Following that I converted the real and imaginary components to magnitude and phase using:

convert real.miff imaginary.miff -fx "sqrt(u*u+v*v)" magnitude.miff
convert real.miff imaginary.miff -fx "atan2(v,u)" phase.miff

Then I did an IFT using these magnitude and phase images, but the result is bad

Likewise using PFM format

convert real.pfm imaginary. pfm -fx "sqrt(u*u+v*v)" magnitude. pfm
convert real.pfm imaginary. pfm -fx "atan2(v,u)" phase. pfm

Here the result gave an image that was comparable to the original.

Note that there is NO scaling in creating the component images when using HDRI in the FFT routines.

Here are my intermediate and resulting images (after scaling to stretch to full dynamic range and converting to png for viewing). Note also the -verbose info: that I present as that is where there are some very strange things going on that I need clarification. The verbose info is coming from the MIFF or PFM images, not the PNG.

________________________________________________________
MIFF RESULTS:

real:
Image
Depth: 32/16-bit
Channel depth:
gray: 16-bit
Channel statistics:
gray:
min: -997.818 (-0.0152257)
max: 1023.98 (0.015625)
mean: 2.26895e-09 (3.46219e-14)
standard deviation: 31.5035 (0.000480712)

Min and Max seem reasonable:

imaginary:
Image
Depth: 32/16-bit
Channel depth:
gray: 16-bit
Channel statistics:
gray:
min: -46.3475 (-0.000707218)
max: 46.3475 (0.000707218)
mean: 5.3717e-12 (8.19669e-17)
standard deviation: 5.61079 (8.56152e-05)

Min and Max seem reasonable

Real/Imaginary convert to Magnitude:
Image
Depth: 16-bit
Channel depth:
gray: 16-bit
Channel statistics:
gray:
min: 0 (0)
max: 1024 (0.0156252)
mean: 5.63159 (8.59326e-05)
standard deviation: 31.5031 (0.000480706)

Min and Max seem reasonable, BUT note that the Depth is reported as 16-bit and NOT 32/16-bit as are the real and imaginary images. Why is this? Is this a bug?


Real/Imaginary convert to Phase:
Image

Depth: 16-bit
Channel depth:
gray: 16-bit
Channel statistics:
gray:
min: 0 (0)
max: 65535 (1)
mean: 21188.2 (0.323312)
standard deviation: 29190 (0.44541)


Min and Max are completely wrong. The phase should vary between -pi and +pi (NOT 0-QuantumRange). Also the same issue with the Depth reported as 16-bit and not 32/16-bit.


Resulting IFT from converted MIFF magnitude and phase:

Image

This is not even close to the original image.

_______________________________________________________
PFM RESULTS:

real:
Image
Depth: 32/16-bit
Channel depth:
gray: 16-bit
Channel statistics:
gray:
min: -997.818 (-0.0152257)
max: 1023.98 (0.015625)
mean: 2.26895e-09 (3.46219e-14)
standard deviation: 31.5035 (0.000480712)

Min and Max seem reasonable:

imaginary:
Image
Depth: 32/16-bit
Channel depth:
gray: 16-bit
Channel statistics:
gray:
min: -46.3475 (-0.000707218)
max: 46.3475 (0.000707218)
mean: 5.3717e-12 (8.19669e-17)
standard deviation: 5.61079 (8.56152e-05)

Min and Max seem reasonable

Real/Imaginary convert to Magnitude:
Image
Depth: 32/16-bit
Channel depth:
gray: 16-bit
Channel statistics:
gray:
min: 0 (0)
max: 1023.98 (0.015625)
mean: 5.63846 (8.60374e-05)
standard deviation: 31.4985 (0.000480637)

Min and Max seem reasonable, BUT note that the Depth is reasonably reported as 32/16-bit as expected.


Real/Imaginary convert to Phase:
Image
Depth: 32/16-bit
Channel depth:
gray: 16-bit
Channel statistics:
gray:
min: -205080 (-3.12932)
max: 205080 (3.12932)
mean: 1.19035 (1.81636e-05)
standard deviation: 104241 (1.59061)


Min and Max are are between -pi and +pi, BUT as fractional values (where it should be in the range of 0-1) and I would have expected them to be the raw value. Also here the Depth is properly reported as 32/16-bit


_____________________
ASSIDE: Note when doing an FFT DIRECTLY to magnitude and phase in MIFF format and looking at the verbose statistics for the PHASE (whose image does look correct), I get the following verbose statistics for the PHASE:
Depth: 32/16-bit
Channel depth:
gray: 16-bit
Channel statistics:
gray:
min: -3.12932 (-4.77504e-05)
max: 3.12932 (4.77504e-05)
mean: 1.81636e-05 (2.77158e-10)
standard deviation: 1.59061 (2.42712e-05)

Note that the values -pi to +pi are now in the raw values not the fractional values.
_____________________

Getting back to the resulting IFT from the CONVERTED PFM magnitude and phase:

Image

This is very close to the original image.

______________________________________________________
Thus:

1) Is there a bug in MIFF storage for data calculated from -fx in Q16-HDRI? (See verbose info for MIFF phase)
2) Why is the conversion from MIFF depth 32/16-bit to changed to MIFF depth 16-bit when output from -fx, but when using PFM it stays as 32/16-bit when output from -fx?
3) Why is the phase between -pi and +pi in the raw value for MIFF, but in the fractional values for PFM? (See verbose info for PFM phase vs MIFF).

Thanks for your help on this.

Here are links to the original MIFF and PFM images in case you need them to test for yourself:

http://www.fmwconcepts.com/misc_tests/F ... _real.miff
http://www.fmwconcepts.com/misc_tests/F ... t_real.pfm
http://www.fmwconcepts.com/misc_tests/F ... inary.miff
http://www.fmwconcepts.com/misc_tests/F ... ginary.pfm
http://www.fmwconcepts.com/misc_tests/F ... t_mag.miff
http://www.fmwconcepts.com/misc_tests/F ... ft_mag.pfm
http://www.fmwconcepts.com/misc_tests/F ... phase.miff
http://www.fmwconcepts.com/misc_tests/F ... _phase.pfm



Fred

P.S. Another piece of information: I just changed my script to do Normalized Cross Correlation (template matching) from using MIFF for FFT storage and computation storage to PFM and got much better results -- more accurate in finding the match point and the NCC surface was much more discriminating.

Re: potential bug using MIFF for FFT in IM 6.4.1-1 Q16-HDRI

Posted: 2008-05-09T19:05:42-07:00
by magick
We work best at an atomic level. Present one bug at a time in a way we can reproduce it. Post one or two images, a description of the problem and why you think its a bug, and a command (or commands) we need to run to reproduce it. We will either offer an explanation of the behavior or a patch if its bug. Once you are satisfied the problem is resolved we'll move onto the next one.

Re: potential bug using MIFF for FFT in IM 6.4.1-1 Q16-HDRI

Posted: 2008-05-09T21:13:42-07:00
by fmw42
Sorry this is unfortunately a complicated issue and I was just trying to give you good information as best I could to explain how and why I think there are problems.

So lets start with the first problem.

I have taken the FFT of the following image on IM 6.4.1-1 Q16-hdri on Mac OSX Tiger using Sean Burke's latest version of IMFFT:
Image

This produces two images in MIFF format:
Real component: http://www.fmwconcepts.com/misc_tests/F ... _real.miff
Imaginary component: http://www.fmwconcepts.com/misc_tests/F ... inary.miff

Each of these images above (from the verbose info) are Depth 32/16-bit.


I then computed the phase as follows:
convert square31_fft_real.miff square31_fft_imaginary.miff -fx "atan2(v,u)" square31_fft_phase.miff
http://www.fmwconcepts.com/misc_tests/F ... phase.miff


This image, when scaled linearly using the min and max values and -evaluate produces a result that is not visually correct.

I then looked at the verbose info: of the MIFF phase (not scaled) as follows:

convert square31_fft_phase.miff -verbose info:

and got the following

Depth: 16-bit
Channel depth:
gray: 16-bit
Channel statistics:
gray:
min: 0 (0)
max: 65535 (1)
mean: 21188.2 (0.323312)
standard deviation: 29190 (0.44541)

The atan2() function should vary between -pi and +pi, but from the min and max values above I am getting 0 and 65535 (QuantumRange). This does not seem correct to me. A bug?

Also the depth of the phase image generated is 16-bit, but I would have expected that it would have been the same as the two input image to -fx, namely, 32/16-bit. A bug?

If I do the same but doing the FFT to PFM format instead of MIFF, I get a reasonable phase image. But I hesitate to go into that with examples as you do not seem to want too much information. So I will leave this message here at this point. If you want more information or want the corresponding PFM images, I can provide them or you can get them from the links in the earlier message.

This is about as succinct as I can make it. Hope that helps.

Re: potential bug using MIFF for FFT in IM 6.4.1-1 Q16-HDRI

Posted: 2008-05-09T21:35:02-07:00
by magick
We can reproduce the problem and have a patch in ImageMagick 6.4.1-2 Beta. The patch will be available in about 2 hours at ftp://magick.imagemagick.org/pub/ImageMagick/beta.

Re: potential bug using MIFF for FFT in IM 6.4.1-1 Q16-HDRI

Posted: 2008-05-09T22:16:21-07:00
by fmw42
Thanks. No rush. As I will not get to it until probably tomorrow.

However, let me get to the next question, which may just be my confusion.

When I do the same thing with PFM (do FFT to real and imaginary components):

http://www.fmwconcepts.com/misc_tests/F ... t_real.pfm
http://www.fmwconcepts.com/misc_tests/F ... ginary.pfm

and produce the phase same as before:
convert square31_fft_real.pfm square31_fft_imaginary.pfm -fx "atan2(v,u)" square31_fft_phase.pfm
http://www.fmwconcepts.com/misc_tests/F ... _phase.pfm

The verbose info on PFM phase: square31_fft_phase.pfm gives:
Depth: 32/16-bit
Channel depth:
gray: 16-bit
Channel statistics:
gray:
min: -205080 (-3.12932)
max: 205080 (3.12932)
mean: 1.19035 (1.81636e-05)
standard deviation: 104241 (1.59061)

Note that the values between -pi and +pi are not the raw values (0-QuantumRange), but in the fractional values where one would expect to see (0-1). Is this correct?

If I produce the phase directly from IMFFT in either MIFF or PFM format, I get -verbose info as follows:
Depth: 32/16-bit
Channel depth:
gray: 16-bit
Channel statistics:
gray:
min: -3.12932 (-4.77504e-05)
max: 3.12932 (4.77504e-05)
mean: 1.81636e-05 (2.77158e-10)
standard deviation: 1.59061 (2.42712e-05)


Now the values -pi to +pi are in the raw values (0 to QuantumRange) not the fractional values? Is this correct?

Seems like one or the other are wrong? Or am I somehow comparing apples to oranges-- one is scaled by QuantumRange relative to the other? Seems like the computed value of atan2 from -fx is not being scaled by QuantumRange? Should or should it not be or does it depend upon whether it is HDRI environment or not?

Can you clarify this for me?

Thanks very much.

Fred

Re: potential bug using MIFF for FFT in IM 6.4.1-1 Q16-HDRI

Posted: 2008-05-10T14:37:31-07:00
by fmw42
Hi,

Here is feedback on the change you made with regard to this reported problem with MIFF storage of 32-bit float data computed by -fx.

I have downloaded IM 6.4.1.-2 beta and installed as Q16-HDRI and tested this problem. It has been partially fixed with regard to MIFF, but now PFM is not working or is being reported incorrectly by -verbose info.

I apologize for the difficulty and time this is causing, but it is key to getting the FFT routines into IM.

Here are the new test images regenerated by IM 6.4.1-2 beta

___________________________________________
MIFF:
http://www.fmwconcepts.com/misc_tests/F ... _real.miff
http://www.fmwconcepts.com/misc_tests/F ... inary.miff

First: the real and imaginary images generated in IM 6.4.1-1, yesterday, were properly reported by -verbose info as colorspace gray, depth 32/16-bit, (since the source image for the FFT was Colorspace: Gray and Depth: 8/1-bit). But these new ones above, generated by IM 6.4.1-2 beta, are being reported as colorspace RGB, depth 32/16-bit. You can verify using the images from yesterday's post. Seems to me that today's images from IM 6.4.1-2beta should still be colorspace gray! Bug? Correct me if I am wrong about the reporting of these images as rgb when I think they should be gray


Next, I used -fx to convert to phase format.
convert square31_fft_real.miff square31_fft_imaginary.miff -fx "atan2(v,u)" square31_fft_phase.miff

http://www.fmwconcepts.com/misc_tests/F ... phase.miff

convert square31_fft_phase.miff -verbose info:
Colorspace: RGB
Depth: 32/16-bit
Channel depth:
red: 16-bit
green: 16-bit
blue: 16-bit
Channel statistics:
red:
min: -205080 (-3.12932)
max: 205080 (3.12932)
mean: -0.220887 (-3.37051e-06)
standard deviation: 59914.2 (0.914231)
green:
min: -205080 (-3.12932)
max: 205080 (3.12932)
mean: 1.41124 (2.15341e-05)
standard deviation: 60317.1 (0.920381)
blue:
min: -205080 (-3.12932)
max: 205080 (3.12932)
mean: 0 (0)
standard deviation: 60318.4 (0.9204)

So here we now get the correct phase values between -pi and +pi, but the colorspace is now also RGB and should be gray.


________________________________________________
PFM:
http://www.fmwconcepts.com/misc_tests/F ... t_real.pfm
http://www.fmwconcepts.com/misc_tests/F ... ginary.pfm

Again the real and imaginary images generated in IM 6.4.1-1, yesterday, were properly reported by -verbose info as colorspace gray, depth 32/16-bit. But these above, generated by IM 6.4.1-2 beta are being reported as colorspace rgb, depth 32/16-bit.


Next, I used -fx to convert to phase format.
convert square31_fft_real.pfm square31_fft_imaginary.pfm -fx "atan2(v,u)" square31_fft_phase.pfm

http://www.fmwconcepts.com/misc_tests/F ... _phase.pfm

convert square31_fft_phase.pfm -verbose info:
Colorspace: Gray
Depth: 32/16-bit
Channel depth:
gray: 16-bit
Channel statistics:
gray:
min: -4.77504e-05 (-7.28624e-10)
max: 4.77504e-05 (7.28624e-10)
mean: -1.76687e-07 (-2.69607e-12)
standard deviation: 2.44885e-05 (3.73671e-10)

So here we now get the correct colorspace of gray, but the values are NOT between -pi an +pi. Yesterday's phase image from IM 6.4.1-1 were correctly between -pi and +pi.
Bug?

Also strangely, if I take yesterday's phase image and get its verbose info with IM 6.4.1-2, it no longer shows correct min and max between -pi and +pi as it did under 6.4.1-1, but duplicates the verbose info on today's image. Whereas, the miff phase from yesterday still shows the incorrect values ranging from 0-1. So it looks like something has changed with respect to PFM format in correcting the MIFF format. Perhaps this is just a -verbose info problem?

I hope this is succinct. If not, let me know and I will try to simplify further. Also let me know if I can provide any further information.

Thanks again for your help.

Fred

Re: potential bug using MIFF for FFT in IM 6.4.1-1 Q16-HDRI

Posted: 2008-05-10T19:46:35-07:00
by magick
We patched PFM. The update will be available in about 2 hours. We will get to the other bug you reported sometime tomorrow.

Re: potential bug using MIFF for FFT in IM 6.4.1-1 Q16-HDRI

Posted: 2008-05-11T17:39:24-07:00
by magick
Download the latest 6.4.1-2 Beta and regenerate your images. Let us know what works / fails now.

Re: potential bug using MIFF for FFT in IM 6.4.1-1 Q16-HDRI

Posted: 2008-05-12T12:12:55-07:00
by fmw42
Thanks. I downloaded the 6.4.1-2 latest beta and made a Q16-HDRI install.

In short, I think all is now well with MIFF and PFM on the example that I have been using. It is staying colorspace Gray, Depth 32/16-bit and the values appear correct, especially for the phase as in both case I now get values between -pi and +pi.

My only question has to do with when a histogram is generate and when not. In the case of the magnitude image, there is no histogram in the -verbose info, but there is for the phase image. I do not know if this is bug or not. I just would like to understand when IM generates a histogram and when it does not.


Thanks for getting this all straightened out so quickly.

Fred
_______________________________
MIFF:

I started with the same grayscale image shown before (white square in black background). Then I did an FFT to real/imaginary, then converted to mag/phase using -fx. The results were as follows:

Magnitude -verbose info:

Type: Grayscale
Endianess: Undefined
Colorspace: Gray
Depth: 32/16-bit
Channel depth:
gray: 16-bit
Channel statistics:
gray:
min: 0 (0)
max: 1023.98 (0.015625)
mean: 5.63846 (8.60374e-05)
standard deviation: 31.4985 (0.000480637)

This has reasonable values for min and max and the colorspace was Gray and Dept 32/16-bit as expected.

Note no histogram was generated. Should there have been?

Phase -verbose info:

Type: Grayscale
Endianess: Undefined
Colorspace: Gray
Depth: 32/16-bit
Channel depth:
gray: 16-bit
Channel statistics:
gray:
min: -205080 (-3.12932)
max: 205080 (3.12932)
mean: 1.19035 (1.81636e-05)
standard deviation: 104241 (1.59061)
Histogram:
15164: ( 0, 0, 0) #000000000000000000000000 black
216: ( 0, 0, 0) #000000000000000000000000 gray(-3 ....

This also ended up with correct values between -pi an +pi and was colorspace Gray and depth 32/16-bit.

But here a histogram was generated. Can you clarify for me when a histogram will or will not be generated?

_________________________________
PFM:

Same process as above.

Magnitude -verbose info:

Type: Grayscale
Endianess: Undefined
Colorspace: Gray
Depth: 32/16-bit
Channel depth:
gray: 16-bit
Channel statistics:
gray:
min: 0 (0)
max: 1023.98 (0.015625)
mean: 5.63846 (8.60374e-05)
standard deviation: 31.4985 (0.000480637)

This is exactly the same as for MIFF format. So all is well, here, too.


Phase -verbose info:

Type: Grayscale
Endianess: Undefined
Colorspace: Gray
Depth: 32/16-bit
Channel depth:
gray: 16-bit
Channel statistics:
gray:
min: -205080 (-3.12932)
max: 205080 (3.12932)
mean: 1.19035 (1.81636e-05)
standard deviation: 104241 (1.59061)
Histogram:
15164: ( 0, 0, 0) #000000000000000000000000 black
216: ( 0, 0, 0) #000000000000000000000000 rgb(-30

This also duplicates the results generated by MIFF above. So all seems correct here.

My only question is when is a histogram generated and when not. For the magnitude, there is no histogram, but for the phase there is.

Re: potential bug using MIFF for FFT in IM 6.4.1-1 Q16-HDRI

Posted: 2008-05-12T12:24:24-07:00
by magick
The histogram is generated only if the image has less than 1024 unique colors. For more than 1024 colors, use the histogram: coder which embeds the histogram as a comment in the image.