IPB

Welcome Guest ( Log In | Register )

Computing a DCT using an FFT, Signal analysis
Mustardman
post Dec 9 2005, 06:40
Post #1





Group: Members
Posts: 25
Joined: 15-April 04
From: Australia
Member No.: 13509



I am trying to make sense of the output of the FFT when used to calculate a type-2 DCT (DCT-II). I managed to scrape together enough documentation that infomed me that, if I wanted to perform a DCT-II using an FFT algorithm, then the data should be arranged to be real even symmetric, with every even indexed data element set to zero.

No problem there. In addition, the outputs are correct, but half the expected value (I can see the output needs scaling by 2 to compensate for the fact that every second sample of the input is zero).

However, I am tyring to figure out how the output comes to be what it is?
In particular, where the zero comes from (term 4 & term 12) [counting from 0].


Input

Real : 0 x0 0 x1 0 x2 0 x3 0 x3 0 x2 0 x1 0 x0
Imag : 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

Output

Real : ya yb yc yd 0 -yd -yc -yb -ya -yb -yc -yd 0 yd yc yb
Imag : 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

[grumble: looks good in fixed width font, but spaces are not turning out here]

In my real application, I am using a 16 point DCT, which equates to a 64 point FFT, but the above is representative.

Any hints?



PS: I know there are better ways of doing DCTs, but in my implementation, I only have access to an FFT routine.


Cheers,Owen.
Go to the top of the page
+Quote Post
 
Start new topic
Replies
Garf
post Dec 9 2005, 12:57
Post #2


Server Admin


Group: Admin
Posts: 4885
Joined: 24-September 01
Member No.: 13



Use code or codebox to get it looking right.

Do you mean you cannot do a rotation or similar before the FFT? This method looks very wasteful, there are much better ways of doing it via an FFT but they need a some pre- and postprocessing.
Go to the top of the page
+Quote Post
Mustardman
post Dec 9 2005, 21:32
Post #3





Group: Members
Posts: 25
Joined: 15-April 04
From: Australia
Member No.: 13509



QUOTE (Garf @ Dec 9 2005, 03:57 AM)
Use code or codebox to get it looking right.


Thanks Garf,

I am not so worried about appearances, more wanting to understand why it is so. I am not that familiar with the mathematics, only how to apply the end results. What I expected, and I should have put in my original post, is...

I expected...
Real : ya yb yc yd -yd -yc -yb -ya -ya -yb -yc -yd yd yc yb ya
Imag : (all zero)

That is, no zero terms in the real output.

QUOTE (Garf @ Dec 9 2005, 03:57 AM)
Do you mean you cannot do a rotation or similar before the FFT? This method looks very wasteful, there are much better ways of doing it via an FFT but they need a some pre- and postprocessing.
*


Yikes!! Not familiar with 'rotations' (but I have come across the term a lot). My application is targetted to hardware (so I can't use FP), and I am doing integer maths. I am trying to get away with 16 bits of precision (very convenient for the hardware).

I agree, the method is very wasteful, and I intend to use the radix-4 method of pre-processing to reduce the FFT size to n (rather than 4n). At the moment, I am trying out different things - but the output did give me a surprise. Non-mathematical documentation on doing a DCT using an FFT is sparse. I only found info on how the input is arranged [first post], but nothing on how the output is arranged.

I did try a 16-bit implementation of BinDCT, (internally, the precision extended to 22 bits) but the in-accuracies killed my application. I guess accuracy was the tradeoff for blistering speed!

I suppose my essential question is : is the output correct, or have I stuffed up? As mentioned, documentation was sparse, so I could be loading the FFT indicies wrong?

Thanks for the reply Garf.
Owen.
Go to the top of the page
+Quote Post

Posts in this topic


Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 19th September 2014 - 19:03