方針変更 から２週間が過ぎたらしい。時が経つのは速いもので、あれこれと遊んでいるうちにあっという間に日時が過ぎてしまう。
言い訳その一「２週間でできるかなというのは、あくまでもコードを書き初めてからの時間で、それ以前の情報収集の時間は含まない」
言い訳その二「２週間でできるかなというのは、あくまでも努力目標であって、完成日時を保証したものではない」
う〜ん、言い訳って醜い。
まあ、それはそれとして、ちょいと真面目に取り掛からないとまずい。遅くとも年内にはリリースできるようにしたいから……。
ホントは他にもやりたいことがあったのだけど、時間がないので断念。だれか他の人がやってくれないかな〜。
やってみたかったことの内容というのは、拡大縮小関連のアルゴリズム集めて、解説と実際の処理式と画質評価について一通り書いたページを作成しようとか言うもの。
「縮小と折り返し歪み」・「ローパスフィルタによる帯域制限」・「平均操作法が縮小には一番」とかをメインに書いてみたかったのだけど……。MPEG が一段落ついても良いページが見つからないときに取っておくことにしよ。
Windows 環境で 4G 以上のファイルをサポートした GUI アプリを開発する方法としては、幾つか選択肢があるわけだ。とりあえず、思い付くままにリストアップしてみると……。
まだ、これ以外にもいろいろとあるだろうけども、とりあえず現在思い付くのはこれだけ。
まず、一番最初の Win32API だけを使って書くのは……確か、岩元さんの VideoMaid はその方法で書かれてたはずだから、多分不可能じゃないのだろう。
次に、MFC 使うのが……いわゆる普通の解決方法かな。ただ、これに関しては、色々と苦労することになるのが目に見えてる。
で、GTL 使うのは……これが一番安上がりで楽な気もするのだけど、GPL に感染するのが嫌（ソースの公開は好きな人がやれば良いことで、強制するものじゃないという主義）なので考え中。
最後の BCB5 を買うという選択肢もちょっと心が動かない。とりあえず BCB3 のコードが沢山あって、これがまた、BCB5 だとうまく行かないらしいんで。
……と、いうわけで、悩んでる所なんだけど、何となく MFC 使う方針に傾いてる。まあ、食わず嫌いは良くないだろうというのと、どうせならちゃんと苦労してからけちをつけようかと思って。
あまりにもど〜しようも無かったら、仕方がないので GTL に逃げるかも。まあこの辺はど〜なるか良く判らない。
事のおこりは 12/4 にさかのぼる。今まで愛用していた TMPGEnc が MPEG LA とのライセンス契約を結んだ影響で 12/4 リリースの β12b から、MPEG-2 のサポートを打ち切ったのだ。
また、その後調べてみると、MPEG LA 加盟の６社＋１大学が Compaq を特許の無断使用で訴えている という情報も発見できた。
で、月・火・水と、泥縄で特許法 を読んだり、特許庁 で検索したり、google で検索したり、コンピュータニュース系のページをうろついたりしていたわけだ。（くすん、コード書いてる暇ありゃしない）
まず、一番重要な情報。特許法 第１１章 罰則 より
第百九十六条 特許権又は専用実施権を侵害した者は、五年以下の懲役又は五百万円以下の罰金に処する。
当然これは刑事罰のみで、普通はこれに民事での損害賠償請求（逸失利益やら不当に得た利益やら）が加わる。善良な一般市民としては非常に恐いところね。
次に、MPEG LA からライセンスを取得するにはいくらかかるか。
For MPEG-2 decoding products in hardware or software (such as those found in set-top boxes, DVD players and computers equipped with MPEG-2 decode units), the royalty is US $4.00 for each decode unit
とゆうわけで、デコードユニット（ソフト・ハード問わず）がインストールされてるコンピュータ一台につき、US ドルで 4.00 だそうです。フリーのオープンソースプログラムでどーやって払えっつーの。
しかもだ、この MPEG LA の管理してる特許だけが MPEG-2 関連特許の全てじゃない（MPEG LA 自体が MPEG2 関連特許の 80% しか管理を委託されてないと認めてる）んだな〜。例えば、NHK や IBM とか Fraunhofer とか MIT とかも MPEG-2 関連特許持ってるのだけど、MPEG LA には加盟してない。
ので、たとえばの話で MPEG LA とライセンス契約むすんでるもんね〜と安心してたとしても、いきなり無関係な所から訴えられる可能性まであったりする。NHK や MIT に関しては安心しててもいいのかもしれんけど、IBM や Fraunhofer が MPEG LA と無関係に特許持ってるのは恐すぎ。やってられん。
以下明日に続く。
さて、昨日の続き。Compaq が MPEG-2 特許の無断使用で訴えられているわけなのだけれども……、なんで Compaq なんだろう？
Compaq というのはただの PC 屋さんで適当に Software DVD Player をバンドルして PC を売ってるだけじゃなかったかな〜と、疑問に感じてその辺を調べてみた。
えーと、US 本社では今のところそのモデルは消えてる（係争中だからかな）みたいだけど、日本では、CyberLink の PowerDVD をバンドルして販売してる。多分 US でも同じものをバンドルしてたのだと推測できる。
とすると、なんで CyberLink でなく、Compaq が訴えられたのだろう？
そもそも CyberLink って、MPEG LA とライセンス結んでないわけ？ （ライセンス結んでいれば、特許は消尽してるはずだから、Compaq が訴えられる理由は無い）
そういえば 長瀬ダイレクト が販売してる CinePlayer は手続き経費のみで 300 円という話だけど、どーやって MPEG LA とのライセンス料を払ってるのだろう？
……等々疑問点が噴出。悩みは深まるばかり。
まず、CyberLink が MPEG LA とライセンス契約を結んでるかどうかは簡単に調べられる。具体的には MPEG LA から、LICENSING -> LICENSEES と進めばライセンスを結んでる企業の一覧が見える。とりあえず、CyberLink も WinDVD 作ってる InterVideo も CinePlayer 作ってる Ravisent も見つからなかった。
で、この状態で、CyberLink ではなく、InterVideo でもなく、Compaq が何故訴えられたかということを考えてみると……、次の仮説が立つ。
これが正しいかどうかは不明。ただ、もしも正しければ、m2v.vfp の公開を継続していても大丈夫らしいと、とりあえず一安心はできる。
さらに、ライセンス契約の文章を再確認してみると、デコーダユニット（ソフトウェア・ハードウェア問わず）がインストールされている PC 一台につき、US $4.00 ということらしいから、ソフトウェア自体についてはあまり考えてないのじゃないかという説の補強材料を得ることができる。
以下余談
MPEG LA は、IEEE 1394 バスについて、1394 LA という特許管理団体を立ち上げてるのだけど、Compaq って、IEEE 1394 の基礎特許持ってるんだよね。当然 1394 LA にも加盟してる。
何で MPEG LA 加盟の特許保有者から訴えられる羽目になったんだろ？ 大人の世界って難しい。
今日も今日とて MPEG-2 特許の話。読んでる方はもう飽きてきてるかもしれないけど、まだ続く予定。
さて、昨日の推測が正しければ、当面 MPEG LA 方面から訴訟を起こされる心配は無いわけ（推測が間違ってる場合はいきなり訴訟に巻き込まれる恐れはある。ので、推測に穴をみつけた場合はメールください）なのだけれども、MPEG LA が管理してる特許が MPEG-2 特許のすべてではない。
別企業から訴えられた場合、知らなかったんです〜では済まない。ISO/IEC 13818 の付録として、どこが特許を持ってるかとか表になってたりするので、規格を読まずに作成したのでない限り逃げる余地はない。どんなとこが特許持ってるかというと、現状の m2v.vfp が対応してる VIDEO と SYSTEM だと次の表のようになる。
| Company | V | S |
| AT&T | X | X |
| BBC Research Department | X | X |
| Bellcore | X | |
| Belgium Science Policy Office | X | |
| BOSCH | X | X |
| Columbia University in the City of New York | X | |
| CSELT | X | |
| David Sarnoff Research Center | X | X |
| Deutsche Thomson-Brandt GmbH | X | X |
| France Telecom CNET | X | |
| Fraunhofer Gesellschaft | X | |
| Fujitsu | X | X |
| GC Technology Corporation | X | X |
| General Instruments | X | |
| Goldstar | X | X |
| Hitachi, Ltd. | X | |
| International Business Machines Corporation | X | X |
| KDD | X | |
| Massachusetts Institute of Technology | X | X |
| Matsushita Electric Industrial Co., Ltd. | X | X |
| National Transcommunications Limited | X | |
| NEC Corporation | X | |
| Nippon Hoso Kyokai | X | |
| Nippon Telegraph and Telephone | X | |
| Nokia Research Center | X | |
| Norwegian Telecom Research | X | |
| Philips Consumer Electronics | X | X |
| OKI | X | |
| Qualcomm Incorporated | X | |
| Royal PTT Nederland N.V., PTT Research (NL) | X | X |
| Samsung Electronics | X | X |
| Scientific Atlanta | X | X |
| Siemens AG | X | |
| Sharp Corporation | X | X |
| Thomson Consumer Electronics | X | |
| Toshiba Corporation | X | |
| TV/Com | X | X |
| Victor Company of Japan Limited | X | X |
上の表は、ISO/IEC 13818-2 Annex F からそのまんまコピーしたもの。このうち背景色が灰色になってるのが、MPEG LA 加盟団体。
さらにだ、この表は ISO に対して申告されてる特許のリストに過ぎないから、申告されてない特許があるかもしれない。実際、SONY とか SANYO とか MELCO とか、MPEG LA 加盟企業だけど、ISO/IEC 13818-2 には何も書いてない企業とかあったりする。（1995 年の時点では特許審査中だったのかな）
これらの特許のうちどれが日本国内で有効か、また、m2v.vfp がその特許と抵触するかということを、特許庁 特許電子図書館 で検索しようかとしたのだけど……断念。
企業の法務部特許調査課の方々は毎日こんなことしてるのかと思うと尊敬してしまう。私には耐えられん。それとももっと効果的な検索方法があるのだろうか……
えーとだ、検索条件として判ってるのは団体名だけで、現状では特許番号とか分類とかは一切不明。良い探し方知ってる方いたらメールください。
さて、特許を一個ずつ検証していくのはちょっと無理ということで、基本である特許法に戻ってみることにした。そもそもソフトの公開が特許権侵害にあたらないなら個々の特許についていちいち調べる必要は無いんだよね。
まず、罰則は 過去 に引用したけど、この罰則が適用される侵害行為というのは一体なんなのだろ〜。というわけで、特許法 第４章 特許権 第２節 権利侵害 より
第101条
次に掲げる行為は、当該特許権又は専用実施権を侵害するものとみなす。
- 特許が物の発明についてされている場合において、業として、その物の生産にのみ使用する物を生産し、譲渡し、貸し渡し、若しくは輸入し、又はその譲渡若しくは貸渡しの申出をする行為
- 特許が方法の発明についてされている場合において、業として、その発明の実施にのみ使用する物を生産し、譲渡し、貸し渡し、若しくは輸入し、又はその譲渡若しくは貸渡しの申出をする行為
基本的にソフトウェア特許の場合「物の発明」ではなく「方法の発明」なので、2 の場合の条文が問題となる。
まず「業として」という部分だけど、これは「個人的な範囲を超えて」という意味。だから、個人が開発してる非営利のフリーソフトなら良いのじゃないかという主張は通らない。
他に逃げ道として存在するのは「その発明の実施にのみ使用する物」として、ソフトウェアが該当するかという問題。ここについては解釈が分かれてて、まだ判例は出ていない。
たとえば、マイクロソフトはとある裁判（東京地裁 平成 11 年 (ワ) 1346）で次のように主張していたりする。
被告製品のワード97は、文書処理のためのソフトウェア・プロダクトすなわち「プログラムを記録したコンピュータ読取り可能な記録媒体」である。一般に、発明に係る方法を、コンピュータ上で実現するためのプログラムは、コンピュータにインストールされる前のそれを記録した記録媒体自体では、方法の発明を使用することにはならない。したがって、このような記録媒体自体の生産、譲渡等を行っても、方法の特許発明を実施することにはならない。
この裁判は「そもそも特許（版下デザイン装置）と MS Word 97 が組み込まれたパソコン（汎用文章処理装置）は別のものだし、特許権で争うようなことじゃないでしょ。原告が法廷費用全額負担ね、請求は却下」という判決になってしまって、被告（マイクロソフト）の上主張に対する裁判所の判断が示されなかったのが残念。
まあ、マイクロソフトが保有してるソフトウェア特許（保有してるのかは不明）に関しては、ソフトウェアの頒布に際して無視していいらしいと判ったのが収穫といえば収穫。
午後はこの解釈（ソフトウェアは物じゃない）に賭けるつもりみたいだけど、真似をするのはちと怖い。
なお、特許権関連の判例は 知的財産権裁判例の検索 で検索可能です。なんか良いものが見つかったら教えてください。
ああ、最近めっきり発想が後ろ向き。さて「ソフトウェアは物じゃない」説だけで勝負に出るのは怖いので、もう少し特許法を調べてみると次の条文が見つかる。
第69条
特許権の効力は、試験又は研究のためにする特許発明の実施には、及ばない。
つまり、研究目的だったら特許を実施しても侵害にはあたらないというわけ。lame プロジェクトでは Frounhofer の MP3 特許を回避するためにこれと似た主張をしている。
m2v.vfp はソース公開してるし、配布に際しては対価を得ていないので、この方針真似しても良いのだけど……何かが違う気がする。
そもそも m2v.vfp って研究と呼べるのかが疑問。lame のように高品質を目指してる訳ではない（デコーダなので、規格どおりに手抜きをせずに作るのが一番高画質だったりする）し、MSSG の MPEG2DEC からの進歩と言えるのは VFAPI に対応してランダムアクセスが可能になっただけ。スケーラビリティに非対応になったり、再生時 3:2 プルダウンで手抜きしてたりかえって低機能になってるところもある。
ランダムアクセスの実現についても、誰でも思いつけるような方法しか使っていない。実際、ただの物理学科の学部生が夏休み中に片手間で作れてしまう程度のものでしかない。これを研究だなんて思い上がりも甚だしいと感じるよね。
m2v.vfp の今後について結論を出すのはもう少し先にする予定。続きは明日。
さてさて、調べれば調べるほどフリーソフトウェアを安全に頒布するのは不可能に思えてくる。
特許の場合、著作権とは違って、たとえ特許を知らずに作ったものでも特許権侵害が成立してしまうから 安全 に頒布しようと思ったら、きっちり特許を調べておかなければならない。
でも、今までにどんな特許が出てるか完全に調べるのは零細フリーソフト作者にはまず無理だし、特許に抵触してると判明したときも、ライセンス料を要求されても払えないのでライセンスを結ぶわけにもいかない。
あ〜〜、元々は、自分でコード考えてそれが設計どおりに動いてくれるのが楽しかっただけなんだよね〜。
そりゃ、公開すれば他の人に使ってもらえて、評価してもらえるかもと思ったけど、それだけでなんでこんな後ろめたい思いしなきゃいけないのだろ。
そ〜だよ、個人で作成して個人で使ってりゃ特許の問題は発生しないんだから、WEB での配布は止めて自分一人で使ってりゃいいんじゃん。
全く素晴らしい。どこからも訴えられる心配は無いし、誰にも迷惑をかけない。うん、フリーソフトなんてなくなってしまうべきだと言うのが特許法の精神だったのか。ようやく気が付いた。
一応特許法には次のように書いてあるんだけどな〜。
第１条
この法律は、発明の保護及び利用を図ることにより、発明を奨励し、もつて産業の発達に寄与することを目的とする。
まあ、フリーソフトの存在は、産業の発展には寄与しないという事なんでしょう。きっと。
前回のはただの寝言で、今後プログラムの公開を一切取り止めるとかそういうつもりは無い。まあ、MPEG2 のページを消してなかったので判ったと思うけど。
このシリーズではちと憎悪を書き散らし過ぎたかと反省。自分が作ってたプログラムが、公開できなくなりそうだからといって、全フリーソフトに話を広げて巻き添えにしようというのは志が低いよね。
というわけで、m2v.vfp を更新。自分では使いそうもない機能を２つ追加して、利用条件を変更。多分この利用条件なら大丈夫だと思うのだけど……。
んと、だ。11 日 に書いたことだけど、「試験・研究目的」の場合には、特許を使用しても侵害には当らないとしてる。問題は m2v.vfp を「試験・研究目的」と言うことができるかなんだけど……。
最高裁の「平成１０年（受）第１５３号 医薬品販売差止請求事件」（判決文, ぱてんとさいと へのリンク）とかもあるし、ああいう利用条件にしてれば、ただの実装でも大丈夫なんじゃないかと思う。多分。（参考文献）
m2v.vfp は 0.4.0 から、アスペクト比を読んでリサイズする機能を取り付けたのだけど、現在のバージョンでは大きな手抜きをしてる。ソースサイズからリサイズをしていて、表示サイズからのリサイズではないのだ。
MPEG2 には、シーケンスヘッダにシーケンスディスプレイエクステンションというものがあって、表示サイズとかが指定されてる。ピクチャヘッダにはピクチャディスプレイエクステンションというのがあって、ここでは表示領域がソースの中心からどれだけずれてるかとかが指定される。
例えば、ここ には、SONY の 422 プロファイルのサンプルビットストリームがあるわけなのだけど、これは 720x480 ではなく、720x512 というソースサイズでエンコードされている。422 プロファイルはスタジオ用ということで提唱されているものだから、縦 486 を入れる必要があったのだろう。
こういうストリームを、m2v.vfp でアスペクト比を反映にしてデコードさせると、間違った結果しか得られない。各ディスプレイエクステンションを元にソースをクロッピングして、それからアスペクト比にあうようにリサイズしなければいけない。
まあ、こう書いてしまうと簡単に思えるかもしれないけど、色々と判らないことがあって、簡単には実装できそうに無かったりする。
まず最大の問題は、ピクチャディスプレイエクステンションの number_of_frame_center_offset が判ってないこと。一つのピクチャにつき最大３個まで指定できるみたいなのだけど……これはフィールド毎に指定するということなのかしら？
次に問題なのは、上で書いた SONY のサンプルだと、表示サイズが 120x120 とかになってること。いくらなんでも、720x512 を 120x120 にクロップするなんて事は無いと思うのだけど、ディスプレイエクステンションの処理方法間違ってるのかな〜。でも TMPGEnc でエンコードしたのだと、ここにはソースサイズと同じ値が入ってるんだよね。
というわけで、今のところは判らないのには触らないという方針でクロッピングをせずにリサイズだけしてるわけ。うん、この辺に厳密にこだわる場合は、アスペクト比は無視して、AviUtl か TMPGEnc 側でクロッピング＆リサイズするようにしてください。AUF から流用した３次補間リサイズつかってるのでかなり重いし。
まず結論から。一番綺麗なのは、AviUtl のデフォルトの縮小アルゴリズムです。たとえ３次補間を使おうが、線形補間を使おうが、ラグランジュ補間を使おうが、縮小の際は殆ど効果はありません。
縮小処理は、大きく分けて次の３ステップで実行されます。
まず、座標変換というのは、縮小処理本体のことです。縮小後の画像の画素が、縮小前の画像のどの位置と対応するかということを求める計算です。
例えば、704x480 から 320x240 に縮小する場合のことを考えます。この時、縮小後の画像で (99, 99) の座標にある画素は、オリジナル画像では、(217.8, 198) の位置にあることになります。
次に、ポストフィルタというのは座標変換によって求めた位置の画素のデータを求める作業のことです。座標変換で求まった原画像での位置が画素の位置と完全に一致する場合はその値が縮小後画像での画素の値となるのですが、上の例のように、217.8 と端数を含む場合があります。この時に座標周囲の画素から座標での画素データを計算するのですが、これがポストフィルタ処理です。
ポストフィルタ処理のアルゴリズムとしては、最近傍点（ニアレストネイバー）、線形補間（バイリニア）、３次補間（バイキュービック）などのアルゴリズムがあります。このポストフィルタ部分が一般にリサイズアルゴリズムと呼ばれる部分です。
３次補間（バイキュービック）アルゴリズムの例で説明します。
上の図で (217.8, 198) の周囲にある 16 個の画素と、それぞれとの距離（縦横別に）を示しましたが、３次補間とは、この 16 個の画素のデータに距離の関数の重みをかけて足し合わせ、目標の座標のデータを求めるアルゴリズムのことです。
重み W は距離 D から次の式で計算されます。この時、縦と横は別々に計算されます。
- 距離が 1 未満の場合
- W = 1 - 2 * D^2 + D^3
- 距離が 2 未満の場合
- W = 4 - 8 * D + 5 * D^2 - D^3
- それ以上の場合
- W = 0
この重みを計算する式の中に距離の３乗の項（D^3）が入っている（３次式）ため、このアルゴリズムは３次補間（バイキュービック）と呼ばれています。
例の場合では、横方向の重みが左から -0.032, 0.232, 0.928, -0.128 となり、縦方向の重みは上から順に 0, 0, 1, 0 となります。
縦と横の重みを掛け合わせた、実際の各画素に対する重みは上の図のようになります。この例では縦方向は 1/2 縮小だけなため縦方向での画素のずれがなく、実質横方向の 4 画素からの補間だけとなっています。
以上が３次補間のアルゴリズムなのですが、なにかおかしい事に気が付いた人がいるかもしれません。縦の 1/2 縮小ではずれが発生しないために一切補間が行われません。単純に一つ飛ばしに画素のデータを読んでいくだけです。これでは最近傍点法と変わりません。
また、ずれが存在する場合も基本的にその座標のデータを求めているだけなので微細な部分をぼかしません。折り返し歪み（エイリアスノイズ）が出まくってしまいます。
この問題を解決するのがプリフィルタなのですが、分量が増えてきたので続きは明日にします。
さて昨日の続きです。素のままのポストフィルタ方式では縮小時にアンチエイリアス処理が行われないというところまで書きました。
これを解決するのがプリフィルタです。折り返し歪みは、縮小後のサンプリング周波数では表現しきれない高周波成分が原画像に存在するために発生します。
ならば、縮小前の画像に低域通過（ローパス）フィルタをかけて、あらかじめ帯域制限をしておけばどうでしょう。原理的には折り返し歪みは発生しなくなるはずです。これがプリフィルタの発想です。
というわけで、３次補間リサイズのプリフィルタ用として、低域通過フィルタプラグインを作成しておきました。AUF からダウンロードしてください。
上が設定画面です。まず、これはプリフィルタ用なので、フィルタ優先順位を３次補間サイズ変更よりもあげておいてください。（インストール直後は一番最後になってると思います）
X, Y には縮小後のサイズを入れてください。ここの設定値とオリジナルの画像サイズからカットオフ周波数を決定しています。
タップは、ローパスフィルタにいくつの画素を使用するか設定するところです。基本的に、数を増やすほど高精度になります。実際に使用する画素数はセンタータップ１つと、左右に タップでの設定値×２ 個となってます。（2n+1 の対照型 FIR フィルタです）
チェックボックスでは窓関数を選べます。タップを３以下に設定してる場合は方形波窓を、それ以上の場合はブラックマン窓を使用すると良好な画質が得られるようです。
さてプリフィルタを有効にした場合、３次補間での縮小後の画像は綺麗にアンチエイリアスされたでしょうか？ されてない場合は低域通過フィルタのパラメータを変更してみてください。
縮小時の画質は、ほぼ、このプリフィルタのみで決定します。ポストフィルタとして、３次補間を使おうが、線形補間を使おうが、最近傍点を使おうが殆ど変化はありません。特に、1/2 などの単純な縮小の場合には全て最近傍点と完全に同じになってしまいます。
明日は、この面倒な処理をもう少し手抜きをする方法について書く予定です。
線形補間や３次補間といったサイズ変更アルゴリズムでは、縮小時の帯域制限を目的として、低域通過フィルタをプリフィルタに使います。
低域通過フィルタを実現する方法としては、FIR フィルタが一般的なのですが、まともなフィルタを作るためには ７〜２１タップ、場合によってはそれ以上のタップ数を使用するのが当たり前だったりします。そういったフィルタは果てしなく重いのでとてもとてもとても動画用には使えません。
しかも、FIR フィルタの設計はノウハウに近く完璧な設計方法というのはありません。オリジナルサイズか縮小サイズが変われば低域通過フィルタを作り直さなければいけないのですが、あくまでも高画質を追求する場合は、その際にタップ数や窓関数を変更するだけでなく、あえて縮小サイズとは違うサイズを指定したりすることまで必要だったりします。
こういう面倒な処理を行わずに済む、高速で、高画質な縮小アルゴリズムはないだろうかという要求への回答が AviUtl が採用している縮小アルゴリズムである、平均画素法です。
平均画素法は、原画像と縮小画像での画素が占める面積を考慮して平均し、縮小していく、縮小専用のアルゴリズムです。
例えば、水平方向を 704 から 320 に縮小する場合、一度最小公倍数である 3520 に拡大し、それから 11 画素を平均して 1 画素とすることで 320 に縮小します。
上の図は平均画素法の操作を示したものです。上の列が原画像で下の列が縮小画像に相当します。
このアルゴリズムの特徴は、浮動小数点処理を必要としないので高速という点と、操作自体がかなり良質な低域通過フィルタに相当しているという点です。
このため大抵の場合、平均画素法での縮小が一番高画質になります。もちろん、最適に設計した低域通過フィルタと３次補間による縮小の方が高画質となることもあるのですが、その場合低域通過フィルタを設定する手間があります。価値観にもよりますが、コストに見合うだけの画質の改善は得られません。
明日は、３次補間が有効な場合について書く予定です。このシリーズは次回で終わります。
まず言い訳から。３次補間サイズ変更 Ver. 0.4.1 に組み込まれているプリフィルタは手抜きと罵られてもなにも言い返せない簡易版です。重み行列をちょっと修正するだけで済むし、速度も変わらないからという理由で付けてみただけのものです。
どのように実装したかというと、３次補間の 4x4 の重み行列に３タップ（低域通過フィルタの設定では「タップ１」）の方形波窓 FIR フィルタを織り込むようにしただけです。究極の画質を追求したいと言う方はプリフィルタを使用しない設定に変更して、独立した低域通過フィルタを使うようにしてください。
さて、３次補間が有効な場合というのは、例えば 704x480 -> 640x480 に縮小するときのような、単純な整数分の一という比では 表せない 縮小の場合です。既に書いたように、単純な縮小の場合３次補間は最近傍点法と完全に同一になってしまうので、単に CPU を無駄遣いしているだけになります。
また、この 704x480 -> 640x480 に縮小するケースではプリフィルタを使用しなくてもさほど問題は発生しないはずです。これは、NTSC 信号では水平方向の解像度が甘く、640 では表現しきれないような高周波信号を入れることが元々できないからです。
最後に、このシリーズを記述するのに参考にした情報源とコメントを書いて、まとめにします。
なお、このシリーズの先頭は 縮小アルゴリズム（１） です。
2001, 7/4 追記。縮小処理で一番画質が良くなるのは Lanczos3 と呼ばれるデシメーションフィルタを使用した場合のようです。2001, 7/4 の戯言 から、その辺の解説をしています。
ここ数日、戯言の文体を固定してたので非常に疲れた。やっぱり意識しなきゃできないような無理はするもんじゃないな〜としみじみ実感。
今日は P4 とか、SSE2 とかについて書こうかと思ったのだけど、立て続けにそんな重いネタを扱うのは嫌なので取りやめ。どう考えても１回で片付きそうにないし。
一応低域通過フィルタの SIMD 化は気が向いたときにやる予定。やっぱ水平方向は３並列にするしかないのかな〜〜。
えと、そういうことばかり考えてると気が滅入ってくるのでお気楽に作れる AviUtl プラグインを一つ作成。
「フィールド入れ替え」つ〜のがそれ。何の役にも立たないかもと思いつつ、簡単だったのでついふらふらと。
一応、為念。このプラグインの SIMD 化による高速化の予定はありません。
if (tmetal.and.ncon.eq.0)
& call fatalerror('init1','tmetal & ncon=0',0)
if (tmetal.and.nx/ncon.gt.50) call fatalerror('init1',
& 'Isn''t it better to give more conduction states for tmetal?',0)
私が書いたコードではない。全世界で、それなりに使われてるらしい FHI98MD という第一原理分子動力学シミュレーションのソースの一部。
一見なんの問題もなさそうなコード。実際大抵の環境では問題のないコード。あ、言語は FORTRAN です。
でも、スパコンも作ってる某国内大手メーカ製の Intel x86 用コンパイラでコンパイルしたバイナリは……。特定の条件の時、二つ目の if 文の実行で 0 除算エラーを発生させて止まっちゃうの。
あ〜〜、もったいぶるのは止め。結論。何で 偽 .AND. 式 なのに式が実行されるのか、だれか判る人がいたら教えてくれ。
FORTRAN 95 では、そこまで規定されてないのか（C の常識は FORTRAN の非常識）とか考えたけど、でも、/O オプション指定して、最適化をかけても式が実行されて 0 除算エラー発生させるのには非常に納得行かない。
あとも一つ。etime() は普通に動くくせに、cpu_time() が -1.0 しか返さないのはどーゆう訳だか教えてくれい。私にはただの手抜きにしか思えないのだけど、どーなんでしょう。やっぱり手抜きなのかな？
これが自分の金で買ったコンパイラだったら企業名だして馬鹿にしてあげるとこなのだけど、研究室が買ったものなので我慢してる。（書いたも同然だけど）
さっぱりコーディングが進まない。x86 アセンブラなんて大嫌いだ〜。
今やっている作業は低域通過フィルタの SIMD 化。どれくらい進んでるかというと、全体の 1/6 程度。
現状では水平方向と垂直方向の FIR フィルタを別々に掛けてて、それぞれ端の部分と中央の部分を別々に処理することにしたから、アセンブラコードを書かなきゃいけないのは大体６ブロック。
で、土曜から書き始めて、昨日までの二日間で形になったのは水平方向 FIR フィルタの左端部分のみ。まあ、日曜は遊んでてちっとしかコード書いてないのだけど。
SIMD 版 LPF の公開はも少し先になります。あと、SIMD 版では 31 タップまでの FIR フィルタしか作れないようにするつもりですけど、問題ないですよね。
低域通過フィルタでタップを 15 ぐらいに設定してしまうと、どの窓関数を指定しててもリンギングが発生して画質が悪くなるし、処理も重くなるし良いこと無いですから。
やっと FIR フィルタの MMX 化が完了。タップ５ぐらいなら使い物になる速度になってくれたかな。ついでにルジさんから頂いたコードもマージしてかなり使いやすくなったところで一段落。
もうしばらくは何もしたくないな〜。年内はもう自堕落に遊んで暮らしたい。
でもやらなきゃいけないこともあるんだよね〜。卒研もそろそろ卒論書きはじめなきゃいけないころだし、年内には簡易版でいいからリリースしたい例のもの（一応まだ諦めたわけではない）もあるし……。
う〜ん。
大学に依存しないメール環境の構築がようやく終了。実は 12/11 の段階で自宅でも常時接続環境に移行できてたのだけど、ついつい面倒でメール関連の設定はしてなかった。
今までどうしていたかというと、TeraTerm SSH で学校に繋いで mew で読んでいた。年の瀬も迫ったことだし、いい加減やっとかなきゃまずいと言うわけで、xyzzy に KaMail を導入。
え〜と、メールの受信と送信が普通にできたから、NetNews の設定は面倒だし止めとこ。読みたくなったときに設定することにして……。
ML の登録変更して、友人にアドレス変更の通知を出せばメール関連は終了。
後は、WEB スペースをどうするかだな〜。こっちは \1000/10M という別料金設定だったので申し込んでないのだけど、フリーのスペース探さなきゃ。
大学と同環境とか言い出すと、SSH が使えて SSI の include が使えて Perl/CGI が無制限かつバナーなしという事になるのだけど、そんな夢のような場所は流石にないだろう。
いずれはレンタルサーバとかホスティングサービスに走る事にして、とりあえず何処かで妥協することにしよ。
MPEG2 カット編集（簡易版）のコードを書き始めた。多分年内には完成しないだろうけれども、歩き出さないことには決して目的に到達することはできないから。
Ulead VideoStudio とか買えば〜とか、WinCinema シリーズの WinProducer 待てば〜とか、MegaVi DV 次のバージョンで MPEG2 対応するらしいね〜とか、何も自分で作らなくても良いかなと思ったのだけど……。
VideoStudio はちょっと試すには高いし、苦労話は聞こえるけどあまり良い話は聞こえてこない。あと、いつ出るのか判らないソフトを口を開けて待つぐらいなら自分で作ってしまおうと考えなおした。
マルチプレクサの完成の目処がたってないのを除けば、一応技術的な問題はクリアできてる。年内は無理だろうけれども、歩みを止めることさえなければ何時かたどり着けるはず。
ぅあぁぁぁ pixelpoly.auf が作りたい。欲しいではなく作りたいというのがポイント。
どういうプラグインかは説明するまでもなくファイル名だけで判るよね。そう Adobe AfterEffect のアレ。（私は AE は持ってません。あんなん高くて買えない）
実用性皆無で冗談にしか使えないプラグインになるけど、そこが素晴らしい。実に逃避活動にふさわしい妄想。
えーと、まず乱数を使用して画面をポリゴンに分割して……、後は時間軸でポリゴン毎に回転・移動させて変形してやればいいのかな。う〜ん、かなり歯ごたえありそう。
今のところただの妄想だけど、いつか絶対やってみたい。
えーと、昨日から書きはじめたコードは一応少しずつだけど進んでる。
進捗状況？ CreateWindow/ShowWindow/WndProc で窓が作れるようになった。まだまだ初歩の初歩。なんか MFC 使わずに Win32API と C だけで書くことになったみたい。