4：2：0の色差間引きと補間をあらためて実験・検証してみた。
（アイディアの予想と結果が合わず、かなり時間がかかっちまった・・・）
さて、まず以下の64ｘ64pix画像を作成してみた。
原寸では小さくて特徴がわかりにくいので4倍に拡大すると
この画像の各色は計算上の輝度値（Y）を全て同一値に揃えて、色差値（Cb・Cr）だけを変えている。
（正直、印象としては輝度も違うように見えるんだけどね。。。）
以前（8回目の時）、色差間引きを行うサブサンプリング4：2：0のJpeg画像は
使用するソフトによって再生表示が異なることを紹介した。
そこで、再生結果の異なる2種類のソフト（仮にソフトA・ソフトBと呼ぶ）のそれぞれで
上の画像を4：2：0Jpeg化＆再生表示をしてみる。
（量子化パラメータはABのソフトで仕様上若干の差があるが、概ねQ値=75位にそろえてある）
1：Jpeg化A/表示A 2：Jpeg化A/表示B
3：Jpeg化B/表示A 4：Jpeg化B/表示B
全部異なる・・・(^o^; 笑
これらが全て異なる表示なると言うことは、A・Bでは再生時の補間のみならず、
Jpeg化時の処理も異なっていると言うことを意味する。
（Jpeg化時の処理が同じなら、1と3、2と4は同じ表示になるはずだから）
一旦、テストパターン画像の特徴に戻るが、
Y値統一と言うことは輝度に関してはDC成分しかないので輝度によるJpegノイズは発生しない。
元画像で緑のベタ部分だった所に生じているノイズは色差に伴うJpegノイズである。
また、”「」”の形のパターンや点・四角形はタテヨコに1dotずつずらして配置してある。
まれに「色差情報は左上画素の値以外を間引いて、再生時には左上画素の値を流用する」
のような話もあるが
現実には（少なくともソフトA・Bでは）そうはなっていない。
仮にそのように左上画素の色差だけを利用するように自作プログラムを組むと・・・
となって、”「」”パターンは1つおきに消失してしまい、先の1～4のようにはならない。
つまり、「間引く」といっても単純に情報を捨てるのではなく、
現実のソフトは「それなりに妥当な情報反映をさせた」値を採用しているのである。
さて、”それなりに妥当な情報反映”の具体的な手法としては、
真っ先に思い付くのはやはり「平均値」だろう。
そこで、サブサンプル4画素の平均値を使ってJpeg化し、
再生表示時にはその値を4画素にそのまま流用するように自作プログラムを組むと・・・
（量子化パラメータはソフトAと同じにしている）
となった。
さて、コレを上の1～4と見比べると・・・2番のJpeg化A・表示Bとクリソツじゃあ～りませんか!!
・・・ということは、
ソフトAではJpeg化時は色差はサブサンプル4画素の平均値を使い、
再生表示時は単純流用ではなくひと手間加えており、
ソフトBでは逆に再生表示時は単純流用するが、Jpeg化時は4画素の平均値では無く、
何かひと手間加えている。
・・・ということが判る。
・・・で、あらためて1と2を見比べてみる。
一旦2の状態になった画像を1にしているソフトAのひと手間とは何か？
そりゃぁ・・・どう見たって「ぼかし」処理でしょう!?
2ｘ2dotごとに発生しているステップに伴う高周波分を減衰させるローパスフィルタリングと言ってもいいけど
平たく言えば「ぼかし」でっしょ？
そこで自作プログラムにぼかし処理を組み込んでみた
ソフトAでは全画面のCb/Crを展開した上でぼかし処理しているのに対して
自作プログラムでは16ｘ16dot範囲ごとにぼかし処理しているので16ｘ16dot範囲のエッジはぼかされていない。
この点に違いはあるものの、おおむね1と良く似たカンジになって現実ソフトの処理をシミュレートできた。
（16ｘ16dot範囲ごとの処理を全体処理に直すのは・・・・いまさらちょっとめんどくさい）
では、ソフトBの「ひと手間」は何なのか？
たぶん・・・RGBから変換したCb・Crをぼかし処理してから、
2x2dotごとに平均を取ってJpeg化の処理を進めている
・・・んじゃないかと思っているが、追究はしていない。
（Aの処理手法を使用しているソフトの方が多数で、Bの手法は非主流派なので割愛）
