On the topic of discrete cosine transform, one obvious question might be "why cosine instead of sine". The most important consideration is that at k=0, the cosine part evaluates to 1, so F[0] (the 0 Hz DCT component) can capture the DC bias / constant offset of the input signal. In contrast, with sine, F[0] is always zero.
It is perhaps also worth noting that there is an in-between solution between DFT and DCT: discrete Hartley transform (DHT). Like DCT, it produces real-only outputs. Like DFT, it uses 2π*k-spaced bins, with information about certain signal phases ending up in the bins above the Nyquist frequency, instead of the "partial-turn" ones. The added perk of DHT is that unlike DCT, it doesn't require hacks for orthogonality. The formula is:
That said, the DHT encoding is less convenient for signal processing than DFT while saving little if any CPU time; and for compression, it's slower than DCT. Because of this, it hasn't really found a mainstream use. It's essentially a nerdy curiosity that gets brought up as a "superior" alternative in some online threads.
The limited resolution in the frequency domain seems like a nuisance, but it’s inherent. Frequency is about movement, and motion takes time. You need to observe slow movement for longer to detect and measure it than fast movement. (Consider measuring the speed of a snail.) Movements with precise timing (the ticking of a clock) need quick, higher-frequency components.
In some cases, you can do better if you make assumptions about the shape of the movement. You don’t need to wait for a full revolution of a clock hand to measure how fast it’s going, if you assume constant velocity. But this doesn’t work for unpredictable movements.
On the topic of discrete cosine transform, one obvious question might be "why cosine instead of sine". The most important consideration is that at k=0, the cosine part evaluates to 1, so F[0] (the 0 Hz DCT component) can capture the DC bias / constant offset of the input signal. In contrast, with sine, F[0] is always zero.
It is perhaps also worth noting that there is an in-between solution between DFT and DCT: discrete Hartley transform (DHT). Like DCT, it produces real-only outputs. Like DFT, it uses 2π*k-spaced bins, with information about certain signal phases ending up in the bins above the Nyquist frequency, instead of the "partial-turn" ones. The added perk of DHT is that unlike DCT, it doesn't require hacks for orthogonality. The formula is:
Forward DHT: F[k] = sum (n = 0 ... N-1, s[n] * cas(2π*k*n/N) )
Inverse DHT: s[n] = 1/N * sum (k = 0 ... N-1, F[k] * cas(2π*n*k/N) )
...where cas(t) = cos(t) + sin(t).
That said, the DHT encoding is less convenient for signal processing than DFT while saving little if any CPU time; and for compression, it's slower than DCT. Because of this, it hasn't really found a mainstream use. It's essentially a nerdy curiosity that gets brought up as a "superior" alternative in some online threads.
The limited resolution in the frequency domain seems like a nuisance, but it’s inherent. Frequency is about movement, and motion takes time. You need to observe slow movement for longer to detect and measure it than fast movement. (Consider measuring the speed of a snail.) Movements with precise timing (the ticking of a clock) need quick, higher-frequency components.
In some cases, you can do better if you make assumptions about the shape of the movement. You don’t need to wait for a full revolution of a clock hand to measure how fast it’s going, if you assume constant velocity. But this doesn’t work for unpredictable movements.
Great post. 3Blue1Brown has a video with some great animations of this same concept:
https://youtu.be/spUNpyF58BY