Guido M. Schuster, Aggelos Konstantinos Katsaggelos "Rate Distortion Based Video Compression" このタイトルを読んだだけで「うげー」という感想が出てきてしまう。値段も値段だし、ちょっと買う気がしない。
読んでみたい気もするけど、和訳が出ることは……多分永遠にありえないんだろうな〜。タイトルから内容を推測するに、ビデオ圧縮で客観画質を維持しつつ圧縮率を上げるための暗黒魔術あれこれといったところか。
「ソフトバンクBB、恐喝未遂事件容疑者逮捕を受け発表会開催」[BroadBand Watch] を読んでの感想。
協力者への対処については「内部協力者は本人が直接情報を退職後に入手して恐喝したという訳ではないため、現在の法律では対処が難しい」というのが実情だという。
と書かれているけれども、Yahoo BB って、使用人との NDA 契約してないわけなのだろうか？ NDA 違反で、民事損害賠償が普通のコースだと思うのだけど。被害額の算定は例のお詫び代＋逸失利益で簡単に認められるだろうし。上の引用での発言が、NDA なんてやってないよというアピールだとしたら恐ろしい。
PC 発注 とか LOOX T70NH [1] で書いたノートの重さにもそろそろ慣れてきたけど、それでも 2kg 近いおもりを職場への行き帰りに運んでることは変わらないわけで、腕は疲れる。そんなこんなで、バッテリ駆動時間を維持しつつ軽くする方法について妄想してみたり。
松下の Let's Note とかだと、外装を薄く切り詰めて重量を稼ぎ、その分をバッテリーに回しているわけなんだけど、いっそ外装がそのままバッテリーになってたりしたら面白いかもと考えた。十分な強度と加工性を備えた蓄電可能な素材で筐体を構成するだけなんだけど、まー今後５年ぐらいじゃ現実的な話ではないなー。そんな素材ないだろうし。
上で書いた内容が、どこかで見たアイデアだったような……と記憶を検索。笹本祐一「小娘オーバードライブ」(1994, 角川スニーカー文庫) に到達。「じぇーぴーえるがえりのまっどさいえんてぃすとにせいぎのひろいんとしてもてあそばれるじょしこうせいのはなし」な訳なのだけども、その中で出てきたアイテムが電気二重槽繊維で織られたパワードスーツだった……はず。
１年ほど前に多発した、メディアプレイヤーで動画を再生すると上下反転してしまうという問題。この問題の原因は非常にシンプルで、MS がきちんと仕様を文書化していないのが悪い。この原因を、時系列をさかのぼって解説してみる。
時は 10 年以上前。Windows が誕生しようとしていた時代。Microsoft は DIB (Device Independent Bitmap) という表示機器に依存しない画像フォーマットを作り出した。いわゆる BMP ファイルである。このフォーマットでは、ひとつの英断がくだされている。一般に、ディスプレイやプリンタなどでは、上から下へ Y 座標を増やす形で割り当てる。コンピュータ上で画像を扱う場合、それと同様に最上部ラインが先頭アドレスに最下部ラインが末尾アドレスとなるように、データを結合した形でメモリを持つのが普通だった。DIB ではそれとは逆に通常の XY 二次元座標と同様の Y 座標割り当てを行い、下から上に Y 座標値を増やしていく。メモリに保持する場合も、最下部のラインが先頭アドレスになるように、最上部のラインが末尾アドレスになるように結合する。
もう少し詳しく書く。通常のディスプレイなどでの Y 座標割り当ては次のように、上から下に座標値を割り当てる形になっている。
しかし、DIB での Y 座標割り当ては次のように、下から上に割り当てる形となっている。
これは推測になるが、「なぜわざわざ既存デバイスとまったく一致しないデータ保持方法を採用するのだ」というクレームがあったのかもしれない。DIB では上から下への Y 座標割り当てを行うモードも用意されており、その場合、画像の高さとしてマイナスの値をヘッダに記録することとされている。この場合、メモリ上でのデータ保持方法も最上部ラインが先頭アドレス、最下部ラインが末尾アドレスとなる。
時は過ぎ行く。Windows OS は世界に満ち溢れ、DIB フォーマットのために発生した BITMAP 情報ヘッダも AVI や DirectDraw 等に流用されるようになった。
AVI に流用された BITMAP 情報ヘッダでは、高さの正負による Y 座標割り当ての変更は非圧縮 RGB 画像 (DIB フォーマット) と共に使われる場合に限定され、それ以外の圧縮画像では普通に正の高さが上から下の Y 座標割り当てフォーマットにも使われる。（そもそも圧縮画像でメモリ格納順をいじることはできないので）
これが YUV オーバーレイの場合に問題になった。YUV は非圧縮フォーマットである。やろうと思えば、下から上の座標値を割り当てて、その順でメモリにデータを保持することも不可能ではない。あるメーカは YUV オーバレイで、上から下順のメモリを要求する場合に、DIB フォーマットではないからと正の高さを使うようになり、別のメーカは非圧縮画像なのだからと負の高さを使うというぐあいに作成元によって仕様が正反対になってしまった。
最近では開発者が皆もう諦めて、YUV データの場合、正の高さが指定されようが、負の高さが指定されようが、上から下の順の YUV データが渡されると解釈する形で問題は表面化しなくなってきているのだけど、それでも時々思い出したようにオーバーレイでの上下反転トラブルというのが発生したり、そもそも負の高さの YUV データというものに対応していなくて動かないというトラブルが出たりする。
自分のためにメモ。
(defun c-auto-indent-all-line ()
(interactive)
(beginning-of-buffer)
(loop
(c-indent-line)
(if (not(next-line))
(return nil))))
以上 ~/.xyzzy に追加。某仕事で作ってたソースの上に一段階 namespace をかます羽目になってしまったので、作業量を減らすべく。キーワードの設定がまずかったのか、そもそも必要とする人がいないのか、検索しても見つからなかったのが悲しい点。
6/1 邪悪な本で触れた Rate Distortion というキーワードの解説とか。もともとはシャノン大先生が発見した理屈で、非可逆圧縮 (lossy-compression) での圧縮下限の存在についての証明とかだったりする。
レート歪理論について大雑把に解説すると、歪を許容する（非可逆）圧縮では、一般に下のグラフに描いたような下限が存在し、それを超える圧縮はできないというもの。
上の図の曲線をレート歪曲線 (RD 曲線 / Rate-Distortion Curve) とよぶ。この曲線には次のような性質がある。
レート歪曲線は非可逆圧縮での下限を示すわけなのだけど、別の言葉で表現すると、レート歪曲線は最適圧縮時のビットと歪の交換レートを示しているということができる。
例えば、A ビット消費して B のひずみがある場合と、C ビット消費して D のひずみがある場合、どちらがよりのぞましい圧縮かということを比較したいときに、レート歪曲線を利用して、A, C を歪に変換して R(A) + B と R(C) + D で大小を比較すれば、どちらが優れた手法かということが判断できることになる。
6/8 xyzzy で auto-indent に書いた lisp を更新。
(defun indent-buffer () (interactive) (indent-region (point-min) (point-max)))
敗因は indent-region に気がつかなかったあたり。というわけで、某友人 K に感謝。