aian さんはインスタンス mstdn.jp のユーザーです。アカウントさえ持っていればフォローしたり会話したりできます。 もしお持ちでないなら こちら からサインアップできます。

aian @aian@mstdn.jp

Rustやりたいんだけど、近頃詰め込みすぎてるんだよな…。厄年なので、少しセーブしないと。

長らくC++ + C + ASMな開発がメインだったんだけれども、この際、Rust + C + ASMとゆ選択肢を考えた方がいいかな、と思ってる。

あー…そうだ、もう一つあった。光学的な特性を緩和する方法として、古典的だけれども、前処理としてメディアンフィルタをかけておくと、ばたつきを抑えることはできる。ただこれは画像を劣化させるので、色を分類する時の前処理として位置づけて、出力は工夫した方がいい。メモリ食うんだけど。

もうひとつは、抜き出すべき色が構成しているコンポーネントの性質を考慮に入れる。線分が途切れていたら補完する。文字が隠れていたら残りの部分を考える。逆に潰れていたら潰している要素を除去する。ここまでくると知識処理なので、機械的な色除去だけでは手に負えなくなってくるわけだけれども。

対応として、人の色の見方を前処理に取り入れることを考える。いわゆる錯視や錯覚として認識された分を補正する。光学的な仕様と錯視の関係を考える必要はあるけれども、ひとまず前の例で言うなら、黒と赤に加えて「分からない」を加える。分からない色について、周辺のローカルな分布から、どちらに倒すかを考えるようにする。これでやや改善する。

s/無くなった/無くなった情報を/

component extractionは、あらゆるCVの前処理的な位置づけにある処理で、ここがしょっぱいと後段でどれだけ頑張っても、よくなることはない。原画像における属性の集合から、ちょうど必要な部分だけを抜き出すとゆことは、原画像に含まれている情報の量を落とすとゆことだったりする。変な情報の落とし方をして、無くなった回復することはまずできない。

これ、なにが厳しいのかというと、スキャナの仕様に依るところがあって、色の周縁部を上手く処理できなかったりする。例えば、黒地に赤の文字を抜き出すことを考えると、黒と赤の周縁部に緑色が入ったりする。スキャナの光学的な仕様やJPEG圧縮の案配で、こうなってしまう。で、この緑を残すかどうか、ピクセル単位の色分布では色の出自が分からないので、判断できない。

とあるネットの記事に手書きノートの裏写りや汚れを除去するものがあった。色の分布を大域的に取得し、クラスタリングして、特定の色だけ除去ないし残すとゆ手法。機械学習に興味のある向きの間では割と話題になっていたんだけれども、しかし、手法としてはオーソドックスで、現実に適用するとこの手法はだいぶ厳しい。

Otsu's Methodって、日本人である大津展之さんの方法なんだけど、Wikipediaにはこの方法の日本語ページがないんだよね。画像処理界隈における前処理軽視の姿勢がうかがわれるぞよ。

Otsu's Method書いてみるかな。あちこちに実装はあるから、改めて新しいもんを作るわけでもないんだけど。

0/1だけの方形波に対する効率的な巡回畳み込み演算を考えられるだろうか。ウォルシュ変換は、区間[0,1)において、f(t)が可積分であることが必要だけど、まあこれは大丈夫か…。

この点、多くの図面画像が疎に描かれていることが多いことを利用すれば、データ構造(2次元)は疎行列と同様の持ち方をすればいい。同時に、問題としてRWの性能が出てくる。これ以上はちょっと話しづらくなってくる。

図面解析系のアプリケーションは、とにかく時間との勝負になることが多く、それはとにもかくにもファイルがデカいからだったりする。単純に読み込むと、長辺が18Kピクセル超のファイルなどもザラにあるので、単純にメモリに展開しているとあまり大したことはできない。この点からして、ひとつの工夫が要る。

そもそも、図面解析とは何をするのか。機能レベルでいうと、スキャンしたラスタ画像の図面に対して、主に次のようなことをする。
・各種ファイルの読み込み
・ノイズ除去(青焼き印刷なども含む)
・歪みの正規化
・線種の認識
・各コンポーネントの認識
・OCR
・数値とコンポーネント(寸法線など)の紐付け
・ベクタライズ
ここら辺までが基礎機能。この上に、アプリケーションごとに付加機能を開発する。

図面解析系のプログラムを少しまとめているんだけれども、この分野はほとんど完全にブルーオーシャンなので、先行事例がない。既にできることはあれこれあるんだけれども、ユーザの動きを想像できないところがあって、ちょっとUIや提供方式をどうするかで悩んでいる。

科学的事実は、作法に照らして検証できることから分かりやすい。一方で、裁判所がするような事実認定は、証明自体が歴史的証明なので、かなり微妙な話になってくる。

ファクトチェックの自動化とゆのは、なかなか大変なことであるよな。そもそも、事実ってなんだよ?とゆ話で。

機械学習の技術屋さんも、自分の古巣であるソフトウェアデザイン方面に引き寄せて、現物を作ることに主眼を置いた方がいいと思うんだけど、理論方面に引きずられる傾向があって、それなら学校に行って学者になった方がいいとは思うんだよね。ここで書くようなことでもないけど。

オブジェクトの復元と背景テクスチャの推論とゆのは、人間的に見て同じようなことをしてるように見えるけれども、機械の処理としては別物として取り扱った方がいいと思う。同じ枠組みで取り扱うこともできるんだろうけれども、注目しているコンテキストが違うので。