Digital Image Processing, Phase offset

[Joshuarr]

Homework Statement

I'm working on a Matlab problem for a digital image processing class. The problem is to take an image, then take its 2D-FFT and offset the phase component by pi. Then to take the IFFT of the new DFT using the unmodified magnitude and modified phase.

What I got was a matrix of all zeros! -- A black image.

I'm not sure if this is the correct result, so I'm here. I notice that when I slowly change the phase offset towards +Pi it fades out.

This is a specific problem, but what I really want to know is: In general, how does a phase offset of pi radians to the DFT phase component affect the original image?

Homework Equations

The Attempt at a Solution

superman is an image we were given for this assignment

Matlab Code:
superman = imread('superman.png')
supermanDFT = fft2(superman);
supPhase = wrapTo2Pi(angle(supermanDFT) +pi);
supMag = abs(supermanDFT);
newSupermanDFT = supMag.*exp(1i*supPhase);
newSuperman = ifft2(newSupermanDFT);
newSuperman = real(newSuperman);
imshow(uint8(newSuperman))

I checked the code by using no phase offset --basically decomposing the image into phase and magnitude reconstructing the DFT with newSupermanDFT = supMag.*exp(1i*supPhase); and taking the inverse and looking at the image. I got the original image as expected. This doesn't guarantee the code is correct, but I have no reason to think its wrong. I'm not really sure what the result should be. :(

Thanks for any help.

 

[Joshuarr]

A MATLAB problem

So, after playing with it some more, I've realized that the result of the ifft2 are negative. And after typecasting them to uint8, they all go to zero. I thought that Matlab would interpret them as the binary 2s complement representation and then give the corresponding uint8. Guess I expected too much!

Still not sure how to make it do what I want, but I'll probably figure it out soon!

 

[collinsmark]

So, after playing with it some more, I've realized that the result of the ifft2 are negative.

Good! I haven't verified your code, but if you are describing what I think you're describing, it seems to be working.

If you're curious as to why pixel values are becoming negative, remember that the Discrete Fourier Transform (DFT) and the Inverse DFT (IDFT) are linear operators.

If operator $\mathcal{O}$ and its inverse $\mathcal{O}^{-1}$ are linear, and we define $X = \mathcal{O}\{x\}$ and $x = \mathcal{O}^{-1}\{X\}$,

then if we multiply the input by a constant $A$ the output is the same as it othwise would be, except also multiplied by $A$. In other words, $\mathcal{O}\{Ax\} = AX$ and $\mathcal{O}^{-1}\{AX\} = Ax$. This is a property of linear operators: You can pull constants out from the input, similar to pulling a constant out from under the integral (and that's only because integrals are linear operators too!)

Keep in mind that $A$ can be any complex constant. It doesn't have to be a real number (although it could be).

To shift the phase of a complex number by $\theta$, one multiplies that number by $e^{i \theta}$.

Given everything that I've described above, what is $\mathcal{F}^{-1} \{e^{i \pi} X \}$?

What is $e^{i \pi }$?

And after typecasting them to uint8, they all go to zero. I thought that Matlab would interpret them as the binary 2s complement representation and then give the corresponding uint8. Guess I expected too much!

Still not sure how to make it do what I want, but I'll probably figure it out soon!

Does the assignment specify how you are to interpret greyscale pixels with negative values? If the original pixel values are greyscale with 8-bit resolution, then each pixel has a range from 0 to 255. Negative numbers are outside this range. You need to figure out how they should be interpreted.

One idea is to simply display the absolute value of each pixel value. You should be able to add an additional line of code simply enough to do this. [And remove the "newSuperman = real(newSuperman);" line].

Are you supposed to keep the exact same bit positions for this? By that I mean, -1 (decimal) = 0b11111111 (8-bit, 2's complement), 0b11111111 (8-bit, unsigned) = 255 (decimal). For this, if the number is less than 0, add 256 to it before typecasting it to uint8.

Or are you supposed to interpret it some other way? If you don't know, you might wish to ask your instructor before proceeding.

 

[Joshuarr]

$$\mathcal{F}^{-1} \{e^{i \pi} X \}=e^{i \pi}\mathcal{F}^{-1}\{X\} = -\mathcal{F}^{-1}\{X\}$$

That explains the negative. I wasn't sure about the representation we were supposed to use, but I'm going to assume that he doesn't want to look at a black block. lol.

This is what I wrote for my "Analysis" section of the homework:

Analysis: The phase offset of 180 degrees seems to have inverted (flipped the bits) of the image. This makes sense since changing the phase by 180 degrees introduces a negative sign for sinusoids. e.g. sin(x+180 deg) = -sin(x). Thus, the highest values become the lowest values and vice-versa.

In my code:
newSuperman = ifft2(newSupermanDFT);
newSuperman = real(newSuperman);
newSuperman = uint8(abs(newSuperman));
newSuperman = bitcmp(newSuperman)+1;

I take the real part of the result of the ifft2 because it's not supposed to have any imaginary components (since it's an image). If any parts of the image are imaginary, we can attribute it to rounding error.

newSuperman is a matrix of type double complex. So I took the abs value, as you suggested, and then turned it into a matrix of uint8. The I took the 2s complement of the absolute values to get the negative representation (but Matlab still interprets it as uint8) -- which is what I wanted all along.

It's not strictly the inverse, since the 2s complement of a binary number is the complement of the bits + 1. I assume adding 1 to the binary number changes the values very little though.

I'm not sure that this is all correct, but it all seems to make more sense.

Thanks for your help!

 

[collinsmark]

I think in this case, what is correct and not correct is up to your instructor. It comes down to how your instructor wants you to represent pixel values outside the normal range of 8-bit greyscale pixel values (0 to 255). Should you map them? Truncate them? It's up to your instructor.

By the way, for what it's worth, Matlab's imshow() function is pretty flexible on how this is handled. There are many possible ways to approach it. The "correct" way is up to your instructor.

http://www.mathworks.com/help/images/ref/imshow.html

 

[Joshuarr]

You're right. He says I should use the full-scale contrast stretch (FSCS) (which I developed in a previous problem) It's a linear mapping that takes the minimum value to 0 and the maximum value of the image to 255 (the maximum gray-level value in the range). The image was inverted again. So it seems to work! in fact, it should be identical to what I did, since this is basically multiplication by -1, which I did by taking the 2s complement.

Thanks for your help again. I appreciate it.

Josh

 

[Joshuarr]

Well, it's not identical. It is off by 1. haha. Almost. ;)

 

[collinsmark]

You're right. He says I should use the full-scale contrast stretch (FSCS) (which I developed in a previous problem) It's a linear mapping that takes the minimum value to 0 and the maximum value of the image to 255 (the maximum gray-level value in the range).

If it's any help, it sounds like the correct interpretation is such that the final image is not the same as the original, non-phase-shifted image. (Hint: when dealing with negative values, think of the noun "Negative," -- like in photography.)

Given your description of your FSCS purpose, then -255 should get mapped to 0, and 0 should get mapped to 255.

(The minimum value in the pre-mapped, phase-shifted image can be as low as -255. And you mentioned that the minimum value gets mapped to 0. Similarly, 0 should be the maximum value in the pre-mapped, phase-shifted image.)

It doesn't sound to me like you should be taking the 2's complement.

[Edit: At least that's my guess anyway. As I mentioned, the "correct" way is up to your instructor, regardless of my guesses.]