Talk:Discrete cosine transform

Tip: Anchors are case-sensitive in most browsers.

This article links to one or more target anchors that no longer exist.

[[Apple community#AppleInsider|AppleInsider]] The anchor (#AppleInsider) has been deleted by other users before.

Please help fix the broken anchors. You can remove this template after fixing the problems. | Reporting errors

History behind the term

Which mathematician (or group of mathematicians) coined this term? What year was it? Was it used before the year 1900? The main page of this article could be improved by giving a brief history behind the term, and what alternative terms were used before this term stuck. 216.99.201.228 (talk) 06:50, 19 September 2010 (UTC)[reply]

The suggestion that David Hilbert or his predecessors did not know how to do a discrete cosine transform by hand is ludicrous. Anyone with an elementary calculus background can do it, and does do it, at the college level. The fast algorithm, on the other hand, to mimick the programming of the FFT for computers, is the later invention. 129.93.161.205 (talk) 20:13, 8 October 2024 (UTC)[reply]

Change in notation

I have started converting the notation in this article to match the changes that have been made to Discrete Fourier transform . The four changes are:

1. n becomes N: Change all instances of the symbol n to the new symbol N to represent the length of the sequences in both the time and frequency domains.

2. k becomes n: Change all instances of the symbol k to the new symbol n to represent the index variable for the time domain sequence.

3. j becomes k: Change all instances of the symbol j to the new symbol k to represent the index variable for the frequency domain sequence.

4. f becomes X: Change all instances of the symbol f to the new symobl X to represent the transformation of the data sequence in the frequency domain.

For more information, see Talk:Discrete Fourier transform.

-- Metacomet 16:09, 6 January 2006 (UTC)[reply]

I just tried typing in the formula for the DCT 2 and 3 into my compiler to see what would happen. It wasn't inverting properly. It looks like it should be $-\frac{1}{2} x_0$ instead of positive. Adding in the negative sign made it work for me.

Nope, you must have mistyped them, or have a bug in your program. (To see that your proposed minus sign isn't correct, consider the simple case of a transform of all 1's.) —Steven G. Johnson 22:15, 1 September 2006 (UTC)[reply]

less algebra, and more explanation please

This article is pretty poor IMHO. How about explaining what it is without resorting to algebra, and also explaining its applications... --Rebroad 10:21, 19 November 2006 (UTC)[reply]

Sorry, if you don't even know algebra you have no hope of understanding a DCT. Don't blame the article for your own limitations. —Steven G. Johnson 20:18, 19 November 2006 (UTC)[reply]

Actually I do not entirely agree. I am not a physicist yet I understand what a nuclear weapon is (without understanding its mechanics) and Dr. Hawking has managed to simplify General Relatively for the masses without resorting to advanced mathematics.

It would be nice if some qualified person would provide a better lay summary of DCT to explain what it does without needing to understand necessarily how it specifically does it. For example: DCT is used in lossy image and audio compression by converting bitmaps into frequency.... and so on.

This is not Mathpedia, it is an encyclopedia which is by definition supposed to contain content for the lay person, not serve as an academic textbook. I liken this to a dictionary that skips the definition to go right to usage and philology. Tolstoy143 - "Quos vult perdere dementat" (talk) 21:38, 7 March 2008 (UTC)[reply]

DCT for non-uniform distributed data points

Is it possible to compute a DCT if the data points are non-uniformly distributed? i.e. if I only know the function $x(t)$ values at t=0.0, 0.1, 0.4, 0.5, 0.55, 1.0 or so? I don't want to interpolate to artificial data points to get uniform distributed data points. --89.49.215.47 20:09, 26 November 2006 (UTC) (de:Benutzer:RokerHRO)[reply]

Excellent question. First, the answer is yes, you can perform a DCT on data that is non-uniformly distributed. Basically, replace

n/N

with the actual grid point. But the more important question is, can we do this in a fast transform? There was groundbreaking research in the 1990s that said "yes" (for the case of the non-equispaced Fourier Transform), and hence probably "yes" for the cosine case.

For information on the non-equispaced FFT, google "NFFT". There are now several fast algorithms. Lavaka (talk) 00:10, 25 January 2008 (UTC)[reply]

Shifted variants of DCT

What is impact on resulting DCT if instead of calculating

X_{k}=\sum _{n=0}^{N-1}x_{n}\cos \left[{\frac {\pi }{N}}nk\right]

we calculate $X_{k}=\sum _{n=0}^{N-1}x_{n}\cos \left[{\frac {\pi }{N}}(n+{\frac {1}{N}})k\right]$ ?
Am I calculating DCT I + ${\frac {1}{N}}$ ?
Is it possible to emphasize importance of DCT I-VIII variants over other shifted DCT?
—The preceding unsigned comment was added by Arkadi kagan (talk • contribs) 13:17, 30 January 2007 (UTC).[reply]

Shifting by 1/N does not result in a DCT according to any of the standard definitions, and is not sensible because only shifts by integers or half-integers preserve the sampling points under mirror flips. —Steven G. Johnson 14:19, 30 January 2007 (UTC)[reply]

I had to do some homework to get your point:)

e^{j2\pi {\frac {mn}{N}}}

is orthogonal set of functions as well as

e^{j2\pi {\frac {(m+{\frac {1}{2}})n}{N}}}

, but not

e^{j2\pi {\frac {(m+{\frac {1}{N}})n}{N}}}

and not

e^{j2\pi {\frac {(m+{\frac {1}{4}})n}{N}}}

Thanks. Arkadi.

Having an orthogonal basis is not really the critical issue; there are lots of non-orthogonal bases out there that are very important. The reason that a DCT is a useful basis is that it corresponds to a DFT + even symmetry. This even symmetry is broken by the "grid" of sampling points if you don't place your origin at either a sample or halfway between two samples. —Steven G. Johnson 00:46, 1 February 2007 (UTC)[reply]

Sorry. I didn`t get you.

As far as I know orthogonality is the sole property that gives us Inverce DCT. If you know something not based on orthogonality, please point me on.

Relation to DFT gives us to calculate some properties easily. But once it is calculated, it have own uses. For example, signal processing usually works with real numbers.

This even symmetry is broken by the "grid" of sampling points if you don't place your origin at either a sample or halfway between two samples.

Even symetry is one property of DCT. But if some other transform have or have not even symetry what is the influence on DCT discussion? Notice that I am refering to your own definition:

Formally, the discrete cosine transform is a linear, invertible function F : R^N -> R^N (where R denotes the set of real numbers), or equivalently an N × N square matrix.

Thanks. Arkadi.

A square matrix can be invertible without being orthogonal; the inverse may just be more complicated to compute. And there are infinitely many invertible real matrices, so the fact that it is real is hardly the defining property either. The things that make the DCT valuable to signal processing and partial differential equations and Chebyshev approximation and numerous other applications (its energy compaction property, its diagonalization of convolutions with certain boundary conditions, its properties under differentiation, its relationship to a Fourier cosine series) all stem directly from its relationship to a DFT of even symmetry.

(Indeed, for the normalization choices shown in the article, the DCTs are not orthogonal, although they are related to orthogonal matrices via multiplication by diagonal matrices.)

—Steven G. Johnson 16:58, 1 February 2007 (UTC)[reply]

If so, may be I don`t know what is exactly Discrete Cosine Transform.

A square matrix can be invertible without being orthogonal; the inverse may just be more complicated to compute.

In case you have something simple like 2 * I you can know its inverse easily - it`s

{\frac {1}{2}}

* I. Is it Discrete Cosine Transform?

Thanks. Arkadi.

No. "Discrete cosine transforms" are specific invertible linear transformations corresponding to DFTs of real-even data. They are not just any one of the infinitely many other possible invertible real matrices, nor are they any one of the infinitely many possible real orthogonal matrices. I don't understand how you could have read what I wrote above to conclude that 2I is a DCT. —Steven G. Johnson 20:57, 3 February 2007 (UTC)[reply]

I will not try to prove that 2I is a DCT :)
I want to locate precise boundary: what transform can be called DCT and what transform can`t. What I am seeking for is a precise definition of DCT. When I have such a definition, I can (or can`t) see all the mentioned above properties - either obvious or complex. Arkadi.

The article already has a long discussion of how the 8 types of DCT arise from a DFT of real-symmetric data. —Steven G. Johnson 17:27, 4 February 2007 (UTC)[reply]

I think I have recognized the source of my personal ignorance in all this topic. I see that none of DCT I-VIII do not have orthogonal basis function:
$cos\left({\frac {2\pi }{N}}nk\right)$ is indeed orthogonal basis.
However, $cos\left({\frac {\pi }{N}}nk\right)$ is not.
Despite this, I do see some superior properties of basis $cos\left({\frac {\pi }{N}}nk\right)$ . For example, spectrum calculated by DCT I (boundary effect is neglectable here) gives cleaner picture than the same spectrum, calculated by "orthogonal basis" DCT.

Please, help me to understand calculation of Inverse DCT given non-orthogonal basis like $cos\left({\frac {\pi }{N}}nk\right)$ .
Thanks. Arkadi.

You're incorrect to state that they do not have an orthogonal basis. All of the DCTs I-VIII, appropriately normalized, are orthogonal matrices (i.e. form an orthogonal basis). (The relationship between DCT and DFT is analogous to the relationship between the cosine series and the Fourier series. The factor of 2 in the cosine argument is due to the fact that you can cut the integration interval in half by the even symmetry.) There are many fine textbooks on discrete cosine transforms (e.g. the Rao and Yip book) that you can read to help clear up any misunderstandings—Wikipedia talk pages are not someplace where you can expect to get extensive tutoring. —Steven G. Johnson 19:09, 6 February 2007 (UTC)[reply]

After reading this article from a beginners point of view, and despite I have used and implemented various DCT variants, that were used in proiduction priduct form image and audio processing (since 1984!), I must admit that this article is a real nightmare, that just mixes opinions about what are considered the current strategies, and what should be first a simple but solid definition.

This article fails in all areas, is extremely badly structured. It should first present the simple DCT, present how it is computed, what it gives by an example, and then present how it can be inverted. Then the properties should be studied, and later the link to the more general theory of Discret Fourier transforms may be added, as well as variants of the algorithm.

I have never heard the terminology of "even" and "odd" ends used everywhere here without any definition ; I never needed that terminologogy to study DCT algorithms since 20 years, and I bet this comes from an abestract taken from an advanced paper.

Most people won't need that terminology.

And I am completely opposed to your opinion here: Wikipedia should be the place for tutorial. Sending people to other resources first is really not the role of Wikipedia, which is to introduce any subject with the simplest approach, and then add some development in other more detailed articles, and then send them to other external advanced resources.

This articles fails everywhere, it is not made for Wikipedians, it's just a badly written abstract of some external paper!

If I had some better English skills (this is not my native language, although I can understand it without difficulty), I would delete it and restart it completely from scratch, with a much better structure, and much less assumption about readers knowledge ! It is unnecessarily complicated, despite a DCT can be very simple to understand. Thanks, when I learned it, there was still no Internet, no Wikipedia. But academi resources were much better written and much more accessible than this very poor article. 86.221.100.174 21:57, 16 February 2007 (UTC)[reply]

Perhaps, I can not agree about orthogonality of base function $cos\left({\frac {\pi }{N}}nk\right)$ .
We can check this for case N = 2 (or N = 4 if you want).
However, inverse transform can be easily computed given this trick:
In case $x_{n}=x_{2N-n}$

\sum _{n=0}^{2N-1}\left[x_{n}cos\left({\frac {nk}{2N}}2\pi \right)\right]=2\sum _{n=0}^{N-1}\left[x_{n}cos\left({\frac {nk}{N}}\pi \right)\right]

.

I suppose, similar conversions are possible for the rest of boundary assumptions.

You have the incorrect limits on the second sum (which should go from 0 to N, for an even extension), and there is no factor of 2 on the n=0 and n=N cases. However, the general idea is in the right direction: all 8 types of DCT can be converted to larger DFTs of real-even data with appropriate symmetries (you can put a sine term into the first sum to get a DFT, because the odd sine terms will sum to zero for even data). ...and because the DFT is unitary (with appropriate normalization), all of the DCT types are orthogonal (with appropriate scaling). Again, however, it seems like you need more extensive tutoring than you can reasonably expect on a Talk page (or from an encyclopedia article). —Steven G. Johnson 17:22, 11 February 2007 (UTC)[reply]

Formal definition

Under the formal definition, it is not stated what k represents. Or have I missed something? --Sam Pablo Kuper 23:41, 4 April 2007 (UTC)[reply]

Fixed. —Steven G. Johnson 20:15, 5 April 2007 (UTC)[reply]

Would be nice if someone added an example

Would be nice if someone added an example of how the DCT saves memory, by showing an 8x8 color block and going thru the math. Thanks, Daniel.Cardenas 18:38, 5 April 2007 (UTC)[reply]

See JPEG. —The preceding unsigned comment was added by Stevenj (talk • contribs) 20:12, 5 April 2007 (UTC).[reply]

n=1?

Great page, really helped me out. The summation given in the formula for DCT-III starts at n=1, should this be n=0?

No, the n=0 term is handled by a separate term since its normalization is different. —Steven G. Johnson 17:44, 11 April 2007 (UTC)[reply]

Misleading example

The example of the DFT and DCT of the image of the dandelion clock is highly misleading, because the original image was a JPEG-compressed image which will have thrown away information from the high-frequency DCT coefficients - so of course the DCT will have very little energy there! I think a new example should be created based on a genuine, non-lossy-compressed original. Rhebus 11:35, 23 May 2007 (UTC)[reply]

it is not exactly correct: JPEG compression removes higher frequencies in each 8x8 block, while the picture shows the transform of the whole image; then JPEG causes the blocking artifact that introduces sharp changes in intensity on the edge of blocks, thus introducing other higher frequency. In any case, I was thinking about re-making the picture using Image:Lichtenstein img processing test.png, since I have used the same picture for other examples (see the description of the picture). You might join the discussion about standard test images on the Electronics wikiproject Alessio Damato 14:25, 23 May 2007 (UTC)[reply]

just to be sure I made a test: I have seen the DCT and FFT of a lossless image and of the same image heavily JPEG compressed (10% quality). I have noticed that the compressed picture had a wider spectrum than the original (I think because of the blocking effect). You can try to do it as well with any picture: you can find the Matlab code in the description page of the picture. Alessio Damato 14:33, 23 May 2007 (UTC)[reply]

Ah yes, of course you're right that JPEG only locally removes higher frequencies. However I still think that the example does not show what it claims to show, and I'd definitely like to see another. Rhebus 16:21, 24 May 2007 (UTC)[reply]

any suggestion?! what's wrong with that, then? :-) Alessio Damato 20:55, 24 May 2007 (UTC)[reply]

Well it's my understanding that the image is trying to illustrate that because the DCT is good at compressing the image energy into one small corner of the transform-space, it is useful for image compression. But, in order to show this, you need to demonstrate that DCT does this on an uncompressed image. Otherwise all you demonstrate is that DCT is effective at compressing the energy in images which have already been JPEG-encoded. Rhebus 14:53, 29 May 2007 (UTC)[reply]

I also note that the Liechtenstein test image is also JPEG-based. I accept that it isn't a terrible test image, and you have taken steps to mitigate JPEG artifacts, but surely the best test image deals with real, unprocessed data? Rhebus 14:58, 29 May 2007 (UTC)[reply]

well, in general I agree that real, unprocessed data have the highest quality, but I'm not sure we really need it for our purpose. I mean: a test image has to have some features (sharp edges, flat surfaces, details), like Liechtenstein, moreover it should have power in any frequency, and I think Liechtenstein has. If you hadn't known the picture was generated from a JPEG, would you have been able to realize it was originally stored as a JPEG?

I could go out for a walk and take a picture with my camera, storing it with TIFF to avoid any artifact, but I don't think it would be a featured picture... do you think we should try to take a picture by ourself to be used as test?

(I think this discussion should move to the wikiproject about electronics, since it's a topic about a more general subject than DCT) Alessio Damato 21:46, 29 May 2007 (UTC)[reply]

Orthogonal

This page seems to mention changing scale factors to make the transform orthogonal. I am fairly sure the transform is orthogonal without the scaling factors, and that the scaling is done to make the transform Orthonormal. —Preceding unsigned comment added by 208.215.227.190 (talk) 18:48, 7 September 2007 (UTC)[reply]

Whilst the transform is orthogonal with any scale factor, the matrix is only orthogonal (by the definition given at Orthogonal matrix) if each of its columns is of unit magnitude. Oli Filth 19:17, 7 September 2007 (UTC)[reply]

figure doesn't match text

unless I'm missing something, the figure that lists DCT I, II, III, and IV doesn't match with the text. The text describes the DCT-II as "...where the even-indexed elements are zero. That is, it is half of the DFT of the 4N inputs y_n, where y_{2n}=0 ... ". This matches DCT-III in the figure. Which is correct? BTW, I like the figure a lot, very intuitive. Lavaka (talk) 03:14, 18 November 2007 (UTC)[reply]

The part that says "y_{2n}=0" refers to the input that would have to be provided to do an equivalent DFT, whereas the diagram shows the way that the DCT's input is effectively interpreted. Also, note that y_{2n}=0 means "every even element is zero", rather than "the element past the end of the sequence is zero", which is what can be see in the diagram of DCT-III's input (I am assuming that this was your interpretation). My best guess is that the zeros are added in order to allow the mid-point to fall at an integer index. This is required because the boundaries are fractional (n=-1/2 and n=N-1/2). Note that the diagram for DCT-III clearly shows that the boundaries are not fractional - they are the first value of the sequence (n=0), and the value past the end of the sequence (n=N) which is set to zero. --82.18.14.143 (talk) 12:50, 3 June 2008 (UTC)[reply]

SA-DCT

SA-DCT: Shape adaptive DCT. A new section inside DCT or a new article about SA-DCT should be created. Diving hawk (talk)

Default DCT Page

DCT should go to Discrete Cosine Transform and then mention up top DCT can also refer to DCT File Format. —Preceding unsigned comment added by 203.129.33.32 (talk • contribs) 00:21, 15 April 2008

There are approximately 15 entries on the DCT disambiguation page. There's no reason to suggest that this article is the most prominent or relevant. Oli Filth^(talk) 23:26, 14 April 2008 (UTC)[reply]

Actually, this seems like a confusion over the disambig pages, of which there are two. OP is looking at the page for "Dct", which has only this article and the DCT File Format. Responder is referring to the page for "DCT", which does in fact have quite a few more entries. Cdecoro (talk) 05:27, 27 January 2009 (UTC)[reply]

Serious Problem in Example

While the example makes a powerful case for the DCT over the DFT, after looking into it in detail I'm afraid that it is irreparably incorrect due to an odd ambiguity in the difference between Matlab's dct and dft functions. Specifically, the dct function is implemented in such a way that is partially normalized, scaling its result by 1/sqrt(2*n). This happens in line 44 of dct.m (Matlab R2008b), and corresponds to what the article terms as the unitary modification. In contrast, the fft function is not implemented in this manner, and instead matches the unnormalized naive DFT. In any case, rather than try to pick apart Matlab's code, it would be better to look at an alternate implementation. I have recreated the example both with FFTW and with a direct implementation of the naive form (I can provide the code on request). Both are equivalent to each other, and appear to match the DFT example shown, but the DCT example shown in the figure is very different, and looks significantly closer to the DFT result. That is to say, the clear advantage of DCT as shown in the example - which was, in fact, what generated me to try to recreate it in the first place - is not at all evident.

In retrospect, there is no reason to assume that the DCT should show the such an improvement: as the FFTW website points out repeatedly, the DCT is equal to a real-even DFT of twice the length. As this article points out, the difference is specifically in the assumptions placed on the behavior outside the sample window (periodic vs. even extension). While this is heuristically useful in 8x8 image blocks, in which case the true extension is likely to resemble an even-mirrored function rather than a periodic one, in this whole-image example a periodic extension would appear to work just as well (all the borders have similar frequencies and colors). Now, I'd like to stress that I don't want to appear as denegrating Mr. Damato's hard work and good intentions. But unless I am wrong (and I am open to that possibility, though after having considered and investigated this for a while I believe it to be an unlikely one) it will be necessary to promptly remove the example. Best, Cdecoro (talk) 02:54, 29 January 2009 (UTC)[reply]

If the image is continuous within the image, then a real-even extension will also be continuous, whereas a periodic extension will not in general be continuous at the boundaries, leading in general to better "energy" compaction for the DCT. If the image itself is discontinuous, however, one doesn't expect to see much of a difference; part of the problem with this example may be that it has so many sharp edges from the blades of grass. (For the same reason, JPEG compression is well known to have the hardest time with sharp lines and edges.) To see a really dramatic difference, it would be good to use a fairly smooth (soft-focus?) image, with very different brightness at the boundaries (e.g. sky above and ground below) as you point out. (The nice thing about 8×8 blocks is that, even if the overall image has many sharp edges, normally there will be many smooth sub-blocks within the image.)

I agree that a clearer example would be better, in any case—actually, it might be good to have an example where the DCT is better along with an example where it is about the same (e.g. an image with sharp edges), just to dispel any notion that the DCT is magically always better. —Steven G. Johnson (talk) 17:46, 29 January 2009 (UTC)[reply]

You make a very good point about the issues that this image's properties would have on the DCT. But I want to stress that the problem I am mentioning here is not a subjective issue with the presentation of the figure, but specifically that the two subfigures are not showing the same thing, because the DCT image is scaled down by a significant amount. This is therefore not an "apples-to-apples" comparison. Since it is objectively incorrect, it needs to be removed. I would replace it with an image with equal scale factor, but the DFT actually appears to be better than the DCT. Cdecoro (talk) 21:14, 31 January 2009 (UTC)[reply]

I should also point out that I believe the division by max(C) in the Matlab code may further exacerbate the problem, as well as the fact that the image is cropped to the lower-left corner, which obscures the fact that the DFT has negative frequencies. But these are minor compared to the larger problem. Can someone please confirm or refute my statement of the problem? (again, I would be happy to be shown wrong, if that is truly the case) If there is no objection, I should erase it. I'd especially like to hear from the original author, btw, if he has the time. Cdecoro (talk) 21:14, 31 January 2009 (UTC)[reply]

N != N !!!

All the formulas confusingly use N to refer to both the length of the input and output vectors, but these are typically different. And so what, for example, does it mean to have " PI / N " in the formula??? Which N??? This is VERY confusing -- why not use n/N and k/K which is a much more standard kind of notation and is not confusing.

For DCTs, the input and output vectors are always the same length; otherwise the transform would not be invertible. There is only one N. —Steven G. Johnson (talk) 04:43, 23 June 2009 (UTC)[reply]

805 kbyte animated gif

Er. Do you realize that this article now has a ~1mbyte animated gif inline? Thats seriously not-nice to people with limited bandwidth. --96.241.226.166 (talk) 22:52, 3 April 2011 (UTC)[reply]

I would suggest adding a redirect to http://wiki.riteme.site/wiki/Dual-clutch_transmission because that uses the abbreviation DCT. — Preceding unsigned comment added by 108.4.30.149 (talk) 02:26, 17 May 2012 (UTC)[reply]

THANK YOU!

Whoever originally wrote and all those who helped improve the informal overview section, you know your stuff and you have a knack for explaining it well! Thank you very much. — Preceding unsigned comment added by 2602:304:47EB:F9F9:21B:77FF:FEAD:46DE (talk) 15:50, 31 August 2012 (UTC)[reply]

I'm not sure if this is the correct place to give feedback, but I'd just like to second this sentiment. The "Informal Overview" section of this article is excellent. It made me wish more Wikipedia articles on mathematical topics had a similar section.Adamlegumetaylor (talk) 16:28, 26 August 2016 (UTC)[reply]

Just wanted to echo the sentiment above - a lot of authors/editors of the Wikipedia maths and sciences articles could do everyone a service by taking a close look at that section as a model for how it should be done. Norlesh (talk) 18:18, 27 September 2019 (UTC)[reply]

My formula

Cosine transform means : if we have signal on [0..T) and we add in interval [T..2T) mirror of this signal (I test, it is the same results if we mirror at zero, interval[-T..T) for -T the same as X0), next we apply _Fourier_transform_ we obtain:
1) spectrum with zero phases (zero imaginary part on FFT), only amplitude elements.
2) if cosine function starting at zero, ending at T - cosine transform get us only one element, rank two times highest than Fourier. Moreover, if we have only cosines different ranks starting at 0, ending at T (no phases), we obtain in cosine transform this maplitudes in even spectrum elements, zero in odd. If no phases, cosine transform not litters on other frequencies. If we have discrete transform, fo example 8 ssmples : x0..x7, x8 must be equal x0, and x9..x15 equal x7..x1. If I compute with plain Fourier this double samples I get 1) and 2)
But formulas DCR I..DCT IV satisfy only 1), not 2)
I derive formula:

X_{k}=\delta (k)x_{0}+\sum _{n=1}^{N-1}x_{n}cos({\frac {\pi nk}{N}})

where $\delta (k)$ is equal 1 for even k, 0 for odd k To normalize with input amplitudes $X_{k}$ should be divided by N for k=0 and by N/2 for k>0. Borneq (talk) 20:56, 15 November 2013 (UTC)[reply]

See WP:OR: Wikipedia is not the right forum to promote changes in the DCT definitions. — Steven G. Johnson (talk) 21:23, 15 November 2013 (UTC)[reply]

Really, definition

x_{0}=x_{N}

is not a discrete cosine transform definition. Borneq (talk) 20:45, 16 November 2013 (UTC)[reply]

DCT V-VIII

"since the corresponding DFT is of length 2(N−1) (for DCT-I) or 4N (for DCT-II/III) or 8N (for DCT-VIII)." I think it should refer to DCT-IV instead of DCT-VIII, from the context. Anyway, I could not verify these lengths. --GuenterRote (talk) 10:08, 29 January 2014 (UTC)[reply]

You're right, it should have been DCT-IV.

The equivalencies can be found in many sources. The equivalence for the DCT-I is commented on e.g. Numerical Recipes or in P. Duhamel, “Implementation of ‘split-radix’ FFT algorithms for complex, real, and real-symmetric data,” IEEE Trans. Acoust., Speech, Signal Process., vol. ASSP-34, no. 2, pp. 285–295, 1986. The equivalence for the DCT II was commented on in e.g. M. Vetterli and H. J. Nussbaumer, “Simple FFT and DCT algorithms with reduced number of operations,” Signal Processing, vol. 6, no. 4, pp. 267–278, 1984; see also refs 1 and 6-10 of this paper (also on arxiv). The equivalence for the DCT-IV is less commonly described, but can be found e.g. in this paper (also on arxiv) and refs 1-2 therein. — Steven G. Johnson (talk) 16:06, 30 January 2014 (UTC)[reply]

DCT-III is NOT an inverse of DCT-II

When I perform a DCT-II (aka "the DCT") and then perform its supposed inverse DCT-III (aka "the IDCT") I do NOT get back my original input. It's a HUGE output. If my input waveform (that is in the range of +/- 100) I then transform with a DCT-II, and then immediately transform it back with a DCT-III, I should get the exact waveform back (within rounding errors of the computer), but I don't instead I get a new waveform that is so big it goes out of the range of my waveform display (easily in 1000s or even 1000000s range)! And I made sure my implementation of DCT-II and DCT-III used the EXACT algorithms as shown on the DCT Wikipedia article here. I think something is wrong with your formulas here. Benhut1 (talk) 01:58, 17 March 2014 (UTC)[reply]

By the way, this is my implementation in VB6, which I believe is an exact implementation of the DCT-II and DCT-III as shown in this Wikipedia article:

DCT-II code:

   For k = 0 To DCTsize - 1

       DCT(k) = 0

       For n = 0 To DCTsize - 1

           DCT(k) = DCT(k) + WaveForm(n) * Cos(Pi * k / DCTsize * (n + 0.5))

       Next n

   Next k

DCT-III code:

   For k = 0 To DCTsize - 1

       IDCT(k) = DCT(0) / 2

       For n = 1 To DCTsize - 1

           IDCT(k) = IDCT(k) + DCT(n) * Cos(Pi * n / DCTsize * (k + 0.5))

       Next n

   Next k

Benhut1 (talk) 04:55, 17 March 2014 (UTC)[reply]

Ok I just figured out my problem. I had needed to multiply the output of the DCT-III by 2/DCTsize in order to make it the true inverse of the DCT-II.

Below is my new code for implementing a true IDCT:

   For k = 0 To DCTsize - 1

       IDCT(k) = DCT(0) / 2

       For n = 1 To DCTsize - 1

           IDCT(k) = IDCT(k) + DCT(n) * Cos(Pi * n / DCTsize * (k + 0.5))

       Next n

       IDCT(k) = IDCT(k) * 2 / DCTsize

   Next k

Benhut1 (talk) 05:12, 17 March 2014 (UTC)[reply]

Bug in the pseudocode?

In the line

   IDCT(k) = DCT(0) / 2

Array DCT seems to be not defined inside the function, perhaps the line should be

    IDCT(k) = FreqDomainData(0)  — Preceding unsigned comment added by 84.249.170.164 (talk) 07:48, 17 April 2014 (UTC)[reply]

Ok. I fixed that code now. By the way, your suggested fix was wrong. The proper fix is

    IDCT(k) = FreqDomainData(0) / 2

Benhut1 (talk) 04:22, 21 April 2014 (UTC)[reply]

Fails to explain when DFT is better than DCT?

The DCT is more useful than the DFT only for non-complex. This is mentioned in the 2nd paragraph. The DFT is efficient than the 2D DCT if the 2nd D is assigned to the complex line; i.e. let the 2D x,y data be x+i*y in the DFT and use eq 3 on the DFT page. The inclusion of the sin() in the DFT prevents the cos^2() in the 2D DCT which is computationally more efficient and the math equation appearance is simpler which allows a better fundamental understanding. I assume the FFT applied to the DFT comes out the same as using FFT applied to 2D DCT. The DFT allows a direct view of the effect of the FT phasors as in the youtube video of a 2D homer simpson line drawing reproduced from the phasors of the DFT. Ywaz (talk) 12:37, 12 March 2016 (UTC)[reply]

Assessment comment

The comment(s) below were originally left at Talk:Discrete cosine transform/Comments, and are posted here for posterity. Following several discussions in past years, these subpages are now deprecated. The comments may be irrelevant or outdated; if so, please feel free to remove this section.

Possibly Mid-priority, cf. Discrete Fourier transform. Geometry guy 16:08, 10 June 2007 (UTC)[reply]

Last edited at 16:08, 10 June 2007 (UTC). Substituted at 02:00, 5 May 2016 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified one external link on Discrete cosine transform. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

Added archive https://web.archive.org/web/20150711105353/http://wisnet.seecs.nust.edu.pk/publications/tech_reports/DCT_TR802.pdf to http://wisnet.seecs.nust.edu.pk/publications/tech_reports/DCT_TR802.pdf

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 21:42, 13 December 2016 (UTC)[reply]

Exaggerations in the article.

I believe there are several erroneous and exaggerated claims in the article. The claim that "Wavelet coding, the use of wavelet transforms in image compression, began after the development of DCT coding.[35] The introduction of the DCT led to the development of wavelet coding, a variant of DCT coding that uses wavelets instead of DCT's block-based algorithm.[35]" is referenced by Hoffman. The problem is Hoffman does not say anything like this, that is that DCT led to wavelet. Moreover I suspect that is a typo or poorly worded sentence. On next page Hoffman says that "Fractal coding provides yet another alternative to DCT -based transform coding". If you read the whole section in this book, it is pretty obviously that wavelets are alternative to DCT and not based on them. Similarly all sources that I've read like this [1], present wavelet as distinct from DCT. I am going to remove this claim, unless someone is going to provide reliable source that explain in details, how DCT led to wavelet compression.

Next the claim that "DCT data compression has been fundamental to the Digital Revolution.[8][41][42] ". First source [2] mentioned Digital revolution at the beginning but does not connect it to DCT. The second [[3]] is a brief summary of relatively obscure article that says "While data compression has made significant contribution to the digital revolution in computer science and telecommunications..." It is simply not reliable source for such grandeur claim. And it does not mention DCT directly. Finally third source says nothing about Digital revolution.So again I am going to delete this claim.

And finally the claim that "The wide adoption of DCT compression standards led to the emergence and proliferation of digital media technologies, such as digital images, digital photos,[43][44] digital video,[21][42] streaming media,[45] digital television, streaming television, video-on-demand (VOD),[8]" is also exaggerated. Most of these sources simply say that those technology use dct, but not that dct "led" to their emeregence. For instance this article, referenced for digital photos [4] is about JPEG and only mention briefly DCT among other algorithms, while second source [5] does not even mention DCT at all. JPEG article on wikipedia also need to be towned down.

This sources [6]], [7] referenced for digital video again simply mention usage of DCT. The source for digital Cinema [[8]], in fact mentions MDCT and not DCT. I am going to tone down those claims. DMKR2005 (talk) 00:45, 15 October 2021 (UTC)[reply]

@DMKR2005: thanks for your review here. We had some POV pushing on this topic a while ago and not all of it was backed out. ~Kvng (talk) 00:19, 18 October 2021 (UTC)[reply]

How is DCT-III calculated in terms of the DFT?

In the DCT-II section it says that it can be calculated in terms of a DFT like this:

This transform is exactly equivalent (up to an overall scale factor of 2) to a DFT of $4N$ real inputs of even symmetry where the even-indexed elements are zero. That is, it is half of the DFT of the $4N$ inputs $y_{n},$ where $y_{2n}=0,$ $y_{2n+1}=x_{n}$ for $0\leq n<N,$ $y_{2N}=0,$ and $y_{4N-n}=y_{n}$ for $0<n<2N.$

However the section on the DCT-III shows no such DFT equivalent. Can someone here please fill in the information regarding calculating the DCT-III using a DFT?

Benhut1 (talk) 22:11, 12 June 2022 (UTC)[reply]

Explanation of how DCT is better than DFT

Hey, I came here because I'm confused about the relation between DCT and DFT. It seems that they are closely related, but they are not quite the same (although for real signals they seem to be really closely related). DFT is conceptually simple. DCT is more complex, it suffices to look at the definition and also the fact that there are 8 slightly different variants. I have read in many places that DCT performs better in data compression, but I have never seen any quantification of this performance. Are there are some rigorous results showing that DCT performs better or is this always subject to our perception?

Also, the part in the informal overview that talks about reducing discontinuities I find a bit misleading. We are dealing with a digital (discretised) signal here, right? So talking about discontinuities seems a bit out of place. Jedreky (talk) 06:12, 3 June 2024 (UTC)[reply]