Re:H.264 is Magic (2016)
by thrdbndndn on Thursday March 17, 2022 @09:48AM
(#30711113)
With only a slight compression, the image would go shit or totally unrecognizable.
A quick album (there are captions):
> 4:2:0 chroma subsample the fft
This is hilarious but I don't think it makes any sense.
Re:H.264 is Magic (2016)
by thrdbndndn on Thursday March 17, 2022 @08:03PM
(#30717224)
yeah, just wanted to try a 'typical' one.
I also tried 70% 444, still unrecognizable.
Thanks, this is exactly what I wanted to see.
impressive how quickly you coded that up.
You can try with Imagemagick (https://legacy.imagemagick.org/Usage/fourier/#im_fft) :
for quality in 50 75 90 95 99 ; do
# FFT
convert source.png -fft +depth +adjoin source_fft_%d.png
# compress FFT magnitude and phase
convert source_fft_0.png -quality $quality source_fft_magnitude.jpg
convert source_fft_1.png -quality $quality source_fft_phase.jpg
# IFFT
convert source_fft_magnitude.jpg source_fft_phase.jpg -ift out.$quality.png
doneThanks, this is great. I found it works a lot better if you leave the magnitude alone and only mess with the phase.
The image is still recognisable even at quite harsh compression of the phase file, but almost totally unrecognisable at even minor compression of the magnitude file.
This wouldn't work well because in the frequency domain representation, different "pixels" have very different importance for the overall appearance of the image: The pixels at the center of the frequency domain representation represent low frequencies, so compressing them will drastically alter the appearance of the image. On the other hand, the corners/edges of the frequency domain representation represent high frequencies, i.e. image details that can be removed without causing the image to change much. That's the crucial benefit of the Fourier transform for compression: it decomposes the image into important bits (low frequencies) and relatively less portant bits (high frequencies). Applying compression that doesn't take that structure into account won't work well.
Re:H.264 is Magic (2016)
by diedyesterday on Friday March 18, 2022 @09:57PM
(#30730153)
Minor note.
If the original data is a time-signal like in electrical engineering (amplitude vs. time function), then the "frequency domain pixels" (its transform) are different frequencies (points in frequency domain: how many repetitions in a second, etc.) and the time-signal's transform function becomes an amplitude vs. frequency graph.
But if the original data is an image (matrix or grid of pixels in space), then the "frequency domain pixels" are different wave-numbers (aka spatial frequencies: how many repetitions in a meter, etc.) and the Fourier transform (of the pixel grid) is a amplitude vs. wave-number function.
I'm into the glitch art scene and this makes me wonder what happens if you crop/erase patterns of the frequency domain representation and put it back together...
Your idea is analogous to what’s done in MRI image reconstruction. “Images” are actually obtained in the frequency domain, but there are various undersampling strategies to accelerate the frequency domain data acquisition. These are then reconstructed into actual images with the inverse FFT.
the frequency domain of the frequency domain is just a flipped version of the original image, so that would not work. the idea of frequency-domain based compression is that natural images have little high-frequency information.
For example, encode the frequency domain representation as a low quality JPEG, and then undo the steps to turn it back into the "original". How do the JPEG artifacts on the frequency domain manifest in the resulting image?