>>723
おつです。
どうやら速度的にはa[y][x]か*(y_table[y] + x)が速いみたいですね。
>>732のコードも気になるので、
>>723の横幅を320から512に変更したint a[512 * 240] の配列に対して、
a[(y << 9) + x]でアクセスする場合も、追記おねがいします！

フーリエ変換は知らないけど、jpgの圧縮の原理にも関係してるみたいです。jpgデコーダー組んだこと無いので詳しくは知りませんが、
たとえば、簡単の為に（RGBそれぞれではなく）、１次元の画像データの各ピクセルの明度だけの場合で考えてみると、
たとえば a[8] = {0.45, 0.46, 3.47, 0.48, 0.49, 0.50, 0.51, 0.52};っていう８ピクセル分の明度データがあったとして、
float w = 3.14 / 8;
float f(float* A, int k){
　　　　s = 0;
　　　　for(i=0; i<8; i++) {
　　　　　　　　s += A[i] * cos( w * (i+(1/2)) * (k+(1/2)) );
　　　　}
　　　　return s
}
によって b[0] = f(a, 0); b[1] = f(a, 1); ... b[7] = f(a, 7);とした結果が
b[8] = {2.4, -0.9, 0.5, -0.4, 0.3, -0.29, 0.27, -0.26}; という値になるのですが、
この f() を通した結果は、大抵の画像で、最初ほど数字が大きくて、後ろに行くほど数字が小さいというデータになるので、
後ろの数字ほど、記録に使うビット数（桁数や精度）を少なくできるので、これを利用してデータ圧縮してるそうです。

このb[]を再び a[0] = f(b, 0); a[1] = f(b, 1); ... a[7] = f(b, 7);とすれば、元の明度データ（と似た値）が得られます。
このb[]に記録する際の、精度の落とし具合が、圧縮率と再現度に反比例して影響してるのだと思います。
jpgエンコーダー組んだこと無いのでよく知りませんが。
誰か簡単なjpgエンコーダー書いてくれるとおもしろいです。よろです。（独自フォーマットのなんちゃってjpgや、機能限定的でもいいので）