Inverse radix4 FFT - fft

I have a radix4 FFT that works in forward direction. How different is the inverse fft from froward? I think the only difference is twiddle factors. My code is a modified version of
Source. Can some one enlighten me on this. Thanks.
My output
50 688
-26 -6
-10 -16
6.0 -26
Expected output
50 688
6 -26
-10 -16
-26 -6

Google search "how to compute inverse FFT". Top result:
http://www.adamsiembida.com/node/23
The equation:
IFFT(X) = 1/N * conj(FFT(conj(X)))
conj() means "complex conjugate", which basically just means multiplying all the complex values by -1.
http://en.wikipedia.org/wiki/Complex_conjugate

Related

Group codes 210 220 230 not in DXF file

I have a simple question, I'm saving a DXF file as R12, but I can't find the group codes 210 220 and 230 for arcs. This is a piece of the DXF file:
0
ARC
5
44
8
0
6
CONTINUOUS
62
7
10
0.0
20
0.0
30
0.0
40
180.0
50
0.0
51
180.0
0
ARC
5
Do I need to save this dxf file as an other version? I need this information for specifying the rotation of the arc... (CW or CCW). Thanks for the help!
The help documentation provided by AutoDesk indicate that the 210 / 220 / 230 values are for the extrusion and are optional.
The help documentation also states:
Arcs are drawn in a counterclockwise direction by default. Hold down the Ctrl key as you drag to draw in a clockwise direction.
The rotation of the arc is attributes 50 and 51 (expressed in radians). Unless, you are referring to the 3D rotation (relative to another view). In which case those attributes are required. But if you are in the World Coordinate System (WCS) when you create your arcs the extrusions are not required.

Is this value on the top right of the matrix called Hadamard Coefficient?

Here I have a matrix.
a=[5 10;5 10]
I have applied Fourier transformation using fft2 command on it in matlab
b=fft2(a)
After this command result will be
b=
30 -10 ;
0 0
I know at the top left 30 is the DC component which is the average intensity. But I'm not sure about -10 value. Is this Hadamard coefficient ?
Thank You

Negative numbers in binary (8-bit)

I'm supposed to convert the following negative numbers to 8-bit binary using both (i) ones complement, and (ii) twos complement:
-76
-203
-18
-177
I know how to do -76 and -18...
• -76
In binary (positive): 01001100
i) 10110011
ii) 10110100
• -18
In binary (positive): 00010010
i) 11101101
ii) 11101110
But I don't know how to approach the other two since the range for 8 bits is -128 and 127... Heeelppp
Thanks in advance

LZW Decompress: Why is first dictionary code encountered in TIFF strip 261 instead of 257, or am I misreading it?

I have a trivial RGB file saved as TIFF in Photoshop, 1000 or so pixels wide. The first row consists of 3 pixels all of which are hex 4B red, B0 green, 78 blue, and the rest of the row white.
The strip is LZW-encoded and the initial bytes of the strip are:
80 12 D6 07 80 04 16 0C B4 27 A1 E0 D0 B8 64 36 ... (actually only the first 7 or so bytes are significant to my question.)
In 9-bit segments this is:
100000000 001001011 010110000 001111000 000000000 100000101 100000110 ...
(0x100) (0x4B) (0xB0) (0x78) (0x00) (0x105) (0x106)
From what I understand 256 (0x100) is a reset code, but why is the first extended code after that 261 (0x105) instead of 257? I would expect whatever dictionary entry this points to to be the 4B/B0 pair for the second pixel (which it may well be), but how would the decompression algorithm know to place 4B/B0 at 261 instead of 257? Can someone explain what I'm missing here? Might there be something elsewhere in the .tif file that would indicate this? Thanks very much.
~
Let's see
256 (100h) is Clear
257 (101h) is EOF
in your case, then
4Bh B0h is 258 (102h)
B0h 78h is 259 (103h)
78h 00h is 260 (104h)
00h 00h is 261 (105h)
Looks good to me. LZW can actually encode one character ahead of what's been added to the table.

Adding two Negative Numbers using 2's Complement

I was wondering if someone could double check my work for me real quick. If I'm given two negative numbers: -33 and -31. If I add them together what will be the result using 2's complement.
NOTE: A word length of 6-bits MUST being used for the operation.
MY ANSWER
So after doing this I computed -31 to be 100001 in 2's. I also computed -33 to be 011111 in 2's complement. When adding them together I got 1000000, however this number is 7 digits so I chopped off the higher order bit since I'm bound to a word length of 6-bits. This yields the number 000000. Which contains a sign bit of 0, meaning it would be even. However since the sum of 2 negative's cannot be even it's obviously an overflow. So I take the 2's of 000000 which is simply 000000.
So the answer should be: 0 since a buffer overflow occurred. Does this seem right to you guys? THANKS. :)
First of all: -33 + (-31) cannot be 0.
-33 is not representable in 6bit 2's complement. 01 1111b is +31 in decimal, so the addition results in 0.
So the correct answer is something like that: There is no result because -33 is an invalid number in 6bit representation.
in 7 bit 2's complement -33 = 101 1111b
110 0001
+101 1111
=
1100 0000
which is equal to -64.