差分画像からのプルダウン判定が確実に行えればこうなることもなかったのだけど、どうにも信頼性に欠ける値にしか評価できなかった。すごく煮詰まってる。今週中にリリースなんて絶対に無理だ。
フレーム単位処理だと小さな縞がノイズに埋もれて、ブロック単位処理だとフレームからのフィードバックを掛けても安定した評価を行うことができず、フレーム単位処理で閾値を導入してみたら薄い縞が検出できなくなってしまった。３方塞がり。
今は良い評価方法も思いつかないことだし、デバッガ上で変数モニタしながらパラメータとコードを変更するのもいい加減嫌になってきたので、フィルタ中イメージに文字列を描画する関数の作成に逃避してる。CreateCompatibleDC, CreateCompatibleBitmap, TextOut, ああ面倒。でもこれは作業を積み上げていけば最後にはきちんと機能するものだから楽。
今頃気がつくのはかなり間抜けだけど、現在の仕事先にはブルーブックがあったことが判明。まだ読んでないし、暫くは読む暇を取れそうもないけど、読んでも NDA に引っかかるんでそれで得た知識を何も書けないのが悲しい。IEC 61834 を購入すれば同じものを誰でも読めるものとはいえ、自分で購入した訳じゃないから。
こういうと聞こえが良いけど、実際のところは少しだけ手の込んだ printf() デバッグ。一応動くようになったので スクリーンショット。
どうやって出してるかは ヘッダ および ソース を参考に。好きに使ってくれて構いません。てか本体の EXFUNC に同じ機能があるとプラグイン開発ってもっと楽になるんじゃないかな〜と思ったり。
また足が筋肉痛。原因まで一緒。今度サーバルームで作業しなければいけないときまでに、コンパクトな三脚式の折りたたみ椅子を購入することにしよう。
アルファ版。30 や 24 ならそこそこ取り除けるようになったのだが、60 は壊滅。特に縞の出ている部分が小さいと最悪で、縞があることを認識しようとすらしない。
比較的縞領域が広くて、二重化まで進んだとしても、今度は二重化の画質が悪い罠。つーか AviUtl 標準の二重化は何をどうやってあんなに高画質（縞がきっちり消える上に、シャギーが無い）にしてるのだろう。一度 240 に減らしてから拡大してるのかと考えて試してみたのだがあの画質には届かなかった。
二重化のコストをあそこまで下げることができれば、判定失敗時に二重化で逃げることができるのだけどな〜。うぐぐ、60 に関しては暫く忘れることにして、拡張 AVI 出力との連携に取り掛かろうとか考えてたのに。
今回公開したアルファ版には、インタレースを解除する機能しかありません。フレームを間引いて fps を変更する機能はつけてません。それは AVI 出力プラグインの機能として実現される予定です。
普通コード書いておきながら呼び出すの忘れたままテストして、シャギーが取れないな〜どうすれば取れるのだろうとか言うやつが居るだろうか。AviUtl の二重化は単純な ([-1]+2*[0]+[1])/4 であったことが判明。あぁ、バカすぎ。
えーと、土曜日に出したものはそういうものだったりするのですが、まぁ想定ユーザは readme.txt に書いた通りなので問題ないでしょう。やっぱりバイナリは入れない方が恥を晒さずに済んでよかったかも。後悔。
日曜は中古で入手した Sense Off をしてたので、インタレース解除や拡張 AVI 関連の進展はありません。で Sense Off 感想ですが、私には合いませんでした。形而下に囚われたオールドタイプのままででいいです。
統一感のない音楽も薄っぺらな描写も突き抜けた設定も微妙に歪んだ立ち絵も苦行の果てにしか見れないあのシナリオも全部判ってやってることでしょうから、何も言えません。はい。
外は暑い。室内は寒い。長袖で行くべきか、半袖で行くべきか、それが問題だ。
去年も同じ事を書いていたような記憶があるけど、やっぱり冷房の噴出し口直下の席はきつい。暑いよりは寒い方がマシだけど、それにしても限度がある。適当な羽織るものを持っていけば問題は解消するのだけどね。
二重化の問題も解消したことだし出力側に手をつけようかと考えていたのだけれど、やっぱりもう少し精度を高める必要があるかと考え直した。なるべくならば、これ一つで他には何も必要ないのが理想なわけだけど、現状はそれとは程遠いので。
60 への対応が甘いのもそうだし、シーンチェンジでの周期変動はあるけど 3:2 プルダウンしかしていない .hack OP でも解除ミスがあるのはまずかろう。フレームを一つの変数で評価するのはどうにも無理っぽいので、評価フェーズと解除フェーズ分けて、ブロック毎の解析結果もバッファするようにして何とかできないか試してみる予定。
開発環境として使用中の PC の中で二番目に古い HDD の、IBM Deskstar 60GXP から異音が発生するようになってしまった。電源を入れているだけで、まるで軸受けが歪んでいるかのような高周波を発してくれる。
まだデータを読み出せるうちに、早く新しい HDD を購入してデータを移植せねばならない。不幸中の幸いでシステムドライブとして使用していた方でなかったのでそれほどの手間はないのが救い。
今まで HDD トラブルには一切当たらずに済んでいたのだけど、一体何が原因だったのだろう。縦置きのマウンタにセットしていたのが悪かったのか、Promise Ultra100 に繋いでいたのが悪かったのか、電源容量が不足がちだったのか、取り込み時の作業ドライブにしていたのが悪かったのか、そもそも IBM 信仰が間違っていたのか。
まあ、120GXP もそろそろ \15k を切りそうだし、もう一つ買っとくのも悪い話じゃない。今月の給料が出たら買いに行くことにしよう。
存在するはずの無い物を見つけてしまった。職場近くの書店でのこと。徳間文庫版の佐藤大輔「レッドサン・ブラッククロス」が全７巻、５冊ずつ平積みになっていたのを見たときの驚きが判るだろうか。
再版されたのかと考えて、思わず奥付を確認してしまったが、１巻は 1995 年の第５刷で７巻は 1996 年の初版本だった。一体何処から発掘してきたのだか……
やっぱりあの書店は変だ。近くにああいう職場がある以上、ASCII の「最新 MPEG 教科書」が置いてあることはまだ理解できなくも無いけど、これは異常だ、普通じゃない。
大手町まで行くついでがあり、そちらの仕事が順調に片付いたので、帰りに秋葉原によって HDD を購入。17650 円とあまり安く買うことができなかったけれど、探すような時間が無かった以上仕方がない。7000 円ケチって 80G を購入すれば良かったかな〜と思わなくもないけど、後で 40G に泣くのも嫌だったので。
職場には 15:30 に帰れたので、そのまま仕事するフリすらしようとせずにテレビで観戦。潔いと評価してくれる人ばかりだとうれしいのだけど、世の中そうはなっていないらしい。悲しいことだ。
インタレース解除は順調に煮詰まっている。ブロック評価をバッファする形式へ作り変えてみたのだけど、24 ではなく 30 や 60 として評価されてしまう。まだ差分データの扱いがうまくできていないらしい。
インタレースノイズの判定精度が悪い原因の一つがクロスカラーにあると判明。とりあえず色差信号を差分判定から取り除いてみる。
結果。問題のシーンでのインタレース判定は正しく行われるようになったが、色のみが変化する（YCS6 で残像が出るような）シーンで当然のように正しく判定されなくなる。クロスカラーおよびドット妨害を考慮した上で輝度信号・色差信号のどちらを判定に使用するか決定してやらねばならないらしい。やる気が失せる。
という訳で、土日はフテ寝してた。部屋が荒れてきてるのでそろそろ掃除機かけないとまずいのだけど、その気力がでなかったので。あー適当な画像認識工学の教科書を探した方が早く片付くかもしれない。どんどん泥沼にはまりこんでいる。
インタレース解除のテスト用素材として、昔 VAIO C1 で取り込んだ某 OP を使っていて気がついたのだけど、どうやら C1 に搭載されている MPEG-2 R-Engine には 3D Y/C も組み込まれているらしい。
動画部分でドット妨害（というよりも色境界でのぎざぎざ）が目立ったのでひょっとしたら 1D Y/C なのかと思ったけれども、コマ送りをしてると静止画ではドット妨害が少しずつ減っていく。見てると面白い。ひょっとしたらフレーム間圧縮だと、フレーム毎に色相反転してしまうクロスカラーよりもドット妨害の方が有難かったりするのかなと妄想中。
3D Y/C の他にも、シーンチェンジで I フレーム挿入して GOP 切り替えもしてくれるのでなかなか良い HW なのかもしれない。といってもノート PC でビデオキャプチャなんてしないし、非ノートでメーカ PC を買うことなんて絶対ないから無縁といえば無縁なのだけど。
しっかし、こういう絵が取れる HW がある以上、クロスカラーの影響を避ける為とはいえ色差成分を評価対象から除くとかしてはいけないんだろうな〜。むきーー、未だにどうやってクロスカラー判定を組み込めばいいのやら思い浮かばない。
夏ボーナスが振り込まれたので、多少余裕ができた。そういうわけで Intel C++ Compiler の購入手続きを進めてみる。国内で買うとクソ高いので intel.com からオンライン購入できないか調べてみたのだけど、クレジットカード決済のライセンスファイルのみ購入でも、US/Canada のみの模様。E-mail での注文ならばどこからでも受け付けているようだけど、私にはそんな英語力は無いので断念。国内代理店 からの購入に切り替える。
いきなり送信フォームの内容確認メールが SJIS のまま charset=ISO-2022-JP な multipart として送られてきて萎える。当然のように文字化けしていて読めない。多分これ社内の担当者向けのメールなんだろうな〜、これがまったく問題なく読めるとっても高機能なメールソフト使ってるんだろうな〜とか色々と考えてしまう。つーか WEB 通販サイト真面目に運営する気あるのかな？ 最低限 SSL ぐらいは常識だと思ってたけど使ってないみたいだし。支払方法は銀行振り込みを選択したからいいけど。
営業時間内の注文だったので、フォームの送信から 1 時間以内に注文確認と支払い方法の案内メールが今度は読めるフォーマットで送られてきたから、我慢できない訳じゃないけど。お客さんに見える部分はもう少し真面目に作った方がいいんじゃないかな。見透かされちゃうよ。
帰社した折に、会社の同僚から「パターン識別」を貸してもらうことができた。素直に嬉しい。まだ第１章を眺めただけなのだけど実に判りやすく書いてあってやっぱり向こうの教科書は素晴らしいと痛感。
適当な例を挙げて問題点を明確にし、しかもそれが解決可能だと示した上で、学ぶことが社会的にも役に立つと指摘してくれるのだから、こりゃ学生はやる気出すよな。第２章のベイズ決定理論も楽しそうだし、ありがたく読ませてもらいます。
Intel C++ Compiler が昨日到着。今は色々とコンパイルオプションを変更して遊んでいる。/Gr オプション（__fastcall 標準）を指定するとコンパイルに失敗することがあるのが不安点。
MPEG-2 VIDEO VFAPI Plug-In は MPEG の出力周りで２つほどバグが見つかっているのと、シリアル・ママに一件要望が入っているので、そちらの対応が済んだ時点で Intel C 版をリリースの予定。パターン識別を現在読んでいる最中なので、これは少し先になるかもしれない。
週末パターン識別を読み進めてみた結果、独立なパラメータ（特徴）がある場合の判定方法は何となく判ったつもりになれたのだけど、相互依存したパラメータをどう組み込めば良いのか悩んでいる。もう少し真面目に解析学と統計学を学んでおくべきだったのかも。式を見てもグラフもコードも浮かばないのは致命的。
インタレースノイズの判定なんて、OCR に比べれば幾何変換を考慮しないで済むだけ楽なはずなんだけどな〜。くぅ、学が足りない。
AviUtl 0.98b の YUV 処理は個人的にはあれで構わないんじゃないかなーと思ってます。別にクリップしてる訳じゃないし。AviUtl だと 16 bit 領域のうち 12 bit 分を有効範囲として扱ってるので、4 bit 分のマージンがあるんですね。
なので、ITU-R BT.601 範囲外の信号も（有効範囲からはみ出すけど）別に失われるわけじゃないんです。まーフィルタプラグインによっては独自にクリップ処理してるかもしれないので、絶対に失われないとは言い切れませんけど。
理想を言えば、YUV を外部形式から内部形式に変換する場合はシフト演算だけにして欲しかったかなと思います。けど、それを判別できるほどの目は持ってないので、言っても仕方がないかなと。
正直パターン識別だけを読んでいても、数学的表現に幻惑されてしまってなかなか本質がつかめないので、WEB で参考になる資料がないかググることにした。「ベイズ決定理論」で一番目にヒットしたページから辿って パターン認識とニューラルネットワーク へ到達。
ああ、これぐらいの数式なら何とか読める。パターン識別を読む前の私なら、このページを眺めても何が書いてあるのかさっぱり判らなかったと思うが、問題点と解決方法をおぼろげに理解した今ならば何とか理解できる。
で、感想。k最近傍 (k-NN) が一番コードに落としやすく、汎用性も高い。でもクソ遅くなる上に、学習させるのに異様な手間がかかりそうなので使えない。やっぱ適当に２次元プロットできる独立なモデルを作って、プロットから確率分布を推測してコードに落とすしかなさそう。
ゲラゲラ、あー最高。すっごく笑った。素晴らしい訳をありがとう。詳細を知りたい人は 2ch UNIX 板 某スレッド 546-550 を参照のこと。
今日は M4 の OpenSSH のアップデート作業で privilege separation 周りの設定に非常に苦労させられてたんで非常にタイムリーだった。当然ながら更新は成功していて、今は 3.4p1 が動いてるので笑っていられるんだけど、苦労してる最中だったらまた別の感想を受けたかも。
