いくつかの点が与えられ たとき、それらの点を通る滑らかな曲線を求めること。画像の拡大・縮小処理の際にも用いられる。との事です（*1）3とか4とかはその「いくつかの点（タップと言うようで す）」 の数。
-zoom -sws 9 scale=640:480:::4
scale[=w:h[:interlaced[:chr_drop[:param[:param2[:presize[:noup]]]]]]]
MPEG-PS file format detected.縦はn-tapになりました。横はなんだかよくわかりません。
VIDEO: MPEG2 720x480 (aspect 2) 29.970 fps 8001.2 kbps (1000.1 kbyte/s)
Opening video filter: [scale w=320 h=240 param2=4]
==========================================================================
中略
SwScaler: Lanczos scaler, from 0x32315659 (21VY) to 0x32595559 (2YUY) using AltiVec
SwScaler: using C scaler for horizontal scaling
SwScaler: using n-tap C scaler for vertical scaling (BGR)
SwScaler: 720x480 -> 320x240
MPEG-PS file format detected.paramとparam2はどちらか片方で良いようです。
VIDEO: MPEG2 720x480 (aspect 2) 29.970 fps 8001.2 kbps (1000.1 kbyte/s)
Opening video filter: [scale w=320 h=240 param=4 param2=4]
==========================================================================
中略
SwScaler: Lanczos scaler, from 0x32315659 (21VY) to 0x32595559 (2YUY) using AltiVec
SwScaler: using C scaler for horizontal scaling
SwScaler: using n-tap C scaler for vertical scaling (BGR)
SwScaler: 720x480 -> 320x240
VO: [macosx] 320x240 => 320x240 Packed YUY2 [zoom]
MPEG-PS file format detected.いやいや1-tapじゃダメだろう、効いてるのかオマエ？再生、エンコードとも、いろいろ値を変えて試しましたが、エンコードは全部1-tapでした。
VIDEO: MPEG2 720x480 (aspect 2) 29.970 fps 8001.2 kbps (1000.1 kbyte/s)
Opening video filter: [scale w=640 h=480 param=4]
==========================================================================
中略
SwScaler: Lanczos scaler, from 0x32315659 (21VY) to 0x32315659 (21VY) using AltiVec
SwScaler: using C scaler for horizontal scaling
SwScaler: using 1-tap C "scaler" for vertical scaling (YV12 like)
SwScaler: 720x480 -> 640x480
TMPGEnc講座 Ver.22 - 2ch,google キャッシュまた、きっちん - 拡大縮小アルゴリズム(バイキュービックとLanczos) - 2006/02/02 の例を見ると、アニメ（自然界では有り得ないはっきりした塗り分け）は、2で充分なように も思えます。むやみにタップ数（Filter Length）を増やせば良いというものでもなさそうです。
- 810 ：名 無しさん＠編集中 ：2006/03/19(日) 17:35:04 ID:1IA0QulE
- DivX6にLanczos4ってあるけどXP3.0のLanczos3との違い判る人います?
- 812 ：名 無しさん＠編集中 ：2006/03/19(日) 18:19:24 ID:YvlfNtGV
- >>810
参照するピクセル数がLanczos3よりLanczos4の方が多い。
その分時間は確実に多くかかるし、画質も必ずしもLanczos4の方が良いとは限らない。
Lanczos8とかLanczos16とかだと、えらくノイジーになるし。
まるも製作所 - 2001/07月の日記
７ 月６日（金） 縮小アルゴリズム（６）— デシメーション
低域通過フィルタを使ったことのある人ならば体験的に理解してるはずですが、解像感を高めようとタップ数を増やせばリンギングノ イズが発生し、リンギン グノイズを減らそうとタップ数を減らせばエイリアスノイズが発生し、エイリアスノイズを減らそうと縮小サイズよりも小さい阻止周波数を指定すれば解像感が 失われるといった具合に、バランスの良い設定値を見つけることが困難です。
しかし、Lanczos フィルタ（正確には Lanczos 窓関数を使用した FIR 低域通過フィルタ）は解像感・リンギング・エイリアスのバランスが高いレベルで取れているためその心配がなく、画像処理には最適であると言われています。
７月９日（月） 縮小アルゴリズム（９）— おまけ（補間の場合）Lanczos フィルタは補間（拡大）にも使用することができます。補間の場合、参照画素数は拡大後の解像度によらず原画像の解像度によってのみ決定されます。
Lanczos フィルタは基本的に低域通過フィルタなのですが、その遮断周波数は基準にとる幅によって決定されます。具体的には、基準の幅のナイキスト周波数が遮断周波 数になります。
原画像の１画素の幅を基準にとると、遮断周波数は原画像解像度のナイキスト周波数に等しくなるので、オリジナルに含まれる（計算誤 差によって削除・追加される歪みを除いた）全情報をそのまま通すフィルタになり、補間に使用することができるようになります。
最終更新 2005/07/12 -- TheSSIM Index for Image Quality Assessment試訳：
TheStructural SIMilarity (SSIM)index is a novel method for measuring the similarity between twoimages. TheSSIM index can be viewed as a quality measure of one of the imagesbeing compared, providedthe other image isregarded as of perfectquality. It is an improved version of the universalimage quality index proposed before. A brief description ofthemethod canbe found here.More details are given in the following paper:
--no-psnr Disable PSNR computationMEncoder -x264encoptsではなにもしなくてもログに出る（PSNRは明示的に指定しないと出ない）。
--no-ssim Disable SSIM computation
アニメ素材なら、ソースの解像度が720x480のときSSIMにして99～98%が狙える。主観でいえばオリジナルとの差が見分けられない。と表現している。
| 種 | タイトル | I枚数 | I比率 | Avg QP (P) | PSNR (Grobal) | SSIM |
|---|---|---|---|---|---|---|
| - | 平均 | 526 | 0.89% | 19.97 | 45.74 | 0.9903196 |
| A | 無敵看板娘_FW_07 | 463 | 0.99% | 19.77 | 45.36 | 0.9901443 |
| A | 無敵看板娘_FW_08 | 439 | 0.98% | 20.36 | 45.26 | 0.9892927 |
| A | 無敵看板娘_FW_09 | 464 | 1.03% | 19.15 | 46.26 | 0.9909509 |
| A | 無敵看板娘_FW_10 | 455 | 1.02% | 20.04 | 45.36 | 0.9899225 |
| R | BSアニメ夜話_23_鋼の錬金術師 | 783 | 0.79% | 20.48 | 45.97 | 0.9903982 |
| R | BSアニメ夜話番外編「アニメの時間よ永遠に」 | 553 | 0.51% | 20.02 | 46.24 | 0.9912088 |
| 種 | タイトル | I枚数 | I比率 | Avg QP (P) | PSNR (Grobal) | SSIM |
|---|---|---|---|---|---|---|
| - | 平均 | 386 | 0.87% | 14.21 | 49.47 | 0.9936473 |
| A | コヨーテラグタイムショー_FW_07 | 432 | 0.98% | 15.14 | 48.71 | 0.9924971 |
| A | コヨーテラグタイムショー_FW_08 | 347 | 0.79% | 14.33 | 49.13 | 0.9929892 |
| A | コヨーテラグタイムショー_FW_09 | 380 | 0.86% | 14.32 | 49.37 | 0.9933534 |
| A | コヨーテラグタイムショー_FW_10 | 403 | 0.91% | 15.10 | 48.96 | 0.9926276 |
| A | コヨーテラグタイムショー_FW_11 | 427 | 0.97% | 14.12 | 49.75 | 0.9934556 |
| A | ゼロの使い魔_FW_07 | 383 | 0.90% | 15.62 | 48.28 | 0.9926050 |
| A | ゼロの使い魔_FW_09 | 367 | 0.85% | 14.63 | 48.86 | 0.9932632 |
| A | ゼロの使い魔_FW_10 | 384 | 0.89% | 14.65 | 49.08 | 0.9936109 |
| A | 僕等がいた_FW_07 | 416 | 0.89% | 13.01 | 50.40 | 0.9952227 |
| A | 僕等がいた_FW_09 | 343 | 0.73% | 12.11 | 51.29 | 0.9954948 |
| A | 僕等がいた_FW_10 | 362 | 0.77% | 13.24 | 50.31 | 0.9950015 |
x264 [info]: SSIM Mean Y:0.9880310
x264 [info]: PSNR Mean Y:44.499 U:48.195 V:49.478 Avg:45.514 Global:45.450 kb/s:1024.56
OBMCについて
具体的な実装の細部までは分かりませんが、概念的にはだいたいこういうことだそうです。
DivX、XviDなどの動画で、ビットレートが足らないときなど、もともとそんなものはないのに、マス目状の線が出てしまうのは、 よく見かけると思いま す。ブロック単位に分割してから各ブロックを処理しているので、ブロックの中身をきめ細かにしてとなりのブロックと滑らかにつながるようにできるだけの情 報量がないと、ブロックの境界の線が目立ってしまうわけです。
MPEG-1ではブロックのサイズが固定（のっぺりしていておおざっぱに切ればいいところも同じに切るし、複雑なところで繊細に処理 してほしいところでも 細かく切ってくれない）なのですが、新しいコーデックでは、ブロックサイズを都合に合わせて動的に変えたり、長方形にしたり…と、 これはx264 （AVC）のユーザなら、設定の検索オプションのところで、いっぱい種類があるのをよくご存知と思います。
しかし、可変ブロックであっても、ブロック境界があることには変わりないので、効率は上がったとはいえ、原理的にブロックノイズが回 避できているわけでは 全然ないわけです。
AVCやWMVやRV10では、それを緩和するために、インループ・フィルターをかけています。特にRV10ではインループが明示的 に設定できるので、気 が付いた方も多いと思いますが、自分がエンコードした結果を自分で（エンコード中に）デコードしてみて、ブロックノイズの原因になる誤差が蓄積していない か確認し、必要に応じて補正をかけるわけです。 AviUtlなどのノイズフィルターなどは、コーデックに行く前にかけるプレフィルターですし、 ffdshowなどの後処理はコーデックから出てきたデコード結果を調整するものですが、インループは前でも後でもなくコーデック自体の中でかけている フィルターです。
しかし、このデブロッキングというのは、案外、実写とは相性が悪いです。ブロックノイズが出ない代わり、繊細なテクスチャー、人の肌 のきめなどがツルンと してしまいます。ただ、たいていのアニメでは、もともとツルンとしているので、この（本来は欠点の）性質がかえってランダムノイズを消して、良い感じに なってくれます。実際、ソースのノイズがデブロッキングの副作用（副作用の副作用？）で勝手に消えてくれることさえあります。とはいえ、自分で発生させた ブロック境界を消すための補正情報にレートを回すのは、巧妙ですが、本質的には無駄です。自分でノイズを作っておいて、それの消し方をコーディングするわ けですので。最初からブロック境界がなければそういう二度手間にならず、自分で汚したものを直すのに必要な情報量を、本質的なテクスチャーに回すことがで きます。
で、SNOWが実装したOBMCですが、 OBMCは、本当はh263にも規格上はあったそうなのですが、実際には使われなかったようです。 GMC同様h264では規格から外されてしまいました。
名前のとおり、オーバーラップしたブロックの動き補償です。碁盤の目のようにきっちり切るのでなく、各ブロックが少しずつ（上下左右 斜めの8方向とも）重 なって定義されています。言い換えれば、古典的な切り方での境界付近のピクセルは、実は両側のブロックに属しているわけです。一般に、各ピクセルは4ブ ロック（実装によっては3ブロック）に同時に属し、それらの加重平均をとることで、区切りの線が目立たず「とろんと」滑らかになります。段差ができる原因 が最初から回避されているわけです。段差を補正するインループ回路も確かに巧妙で効果的ですが、最初から段差ができないようなブロックを重ね合わせた取り 方、というのは本質的に素晴らしい発想でしょう。ただ、一つのマクロの動きを何重にもコーディングして、デコードのときにも重ね合わせて平均をとるので、 計算量（CPU負荷）の問題はありますが、まあ、少し未来にはハードが発達して何とかなるのではないでしょうか。
「波」の重なりで図形を表すウェーブレットも、そうした従来型のアーティファクトを克服するのに貢献するはずです。まあ、これも計算 量が大変そうです が…。
開発者の方から説明してもらったことを生半可な理解で受け売りしているのでちょっと（かなり）間違ってるかもしれませんが、あの SNOWの「とろん」とし た雰囲気と異様な美しさは、だいたいそんなような感じ…らしいです。そして、その計算がたいへんというのは、計算量が多くてもリニ アの計算なので、 GPUでハード的に実装するのは原理的には簡単らしいです。そうすればCPU負荷も問題にならないはずです。