画像処理ライブラリとしてのOpenCV

まずは、最近日本語のOpenCV本が出ていますね。

OpenCV プログラミングブック

OpenCVはもともとインテルのImage Processing Libraryという売り物のライブラリの一部分をオープンソースにしたものと聞いています。

ライブラリ内でも、画像を格納する構造体の名前などにその形跡をみることができます。

OpenCVの特徴としては、

• 静止画・動画・キャプチャ画像や画像ファイルフォーマットを意識することなくライブラリ内に画像を読み込める。
• 定番の画像処理アルゴリズムはすでにライブラリ化されている。

というあたりに利点があるように思います。

ただ、C++ですので、.NETとの相性は正直言ってよくありません。

そこで過去にSharperCVというOpenCVの.NET移植版を利用する方法の記事を過去に書いたことがありますが、もうShaperCV自体のサポートは停止しているという状況だったりします。

画像処理アルゴリズムを開発する環境について考える

最近、ある画像から特定の特徴を持つ領域を抽出するアルゴリズムを探索する依頼を受けております。
いろいろ既存のといいますか、定番・定石の画像処理方法というのはあるのだと思うのですが、今回の対象は非常に画素も輝度も解像度の悪い画像が対象であることから、教科書どおりの手法がうまくいくとは限りません。

特に、人間の目だと「ここからここまでがこの範囲だな」なんてペンで辺縁をなぞるようなことができる画像でも、画素の特徴というより、全体の画像の中からの抽象的な特徴をとらえていることが多く、定番の処理だけで解決するのは難しい問題であったりします。

そういった画像をはじめとしたパターン認識には、ニューラルネットワークやサポートベクターマシーンのような学習型のものから、なんらかの特徴抽出をいろいろおこなって統計的にクラスタリング処理や決定木を構築したり、ファジィロジックを組んでみたりといろいろな試行のパターンがあると思います。

こういった作業を繰り返し試行錯誤している人は世の中に何万人といるでしょうから、そういったものはライブラリ化されていることも多々あります。

F#の入手とインストール

F#は下記のページで配布されています。

http://research.microsoft.com/fsharp/fsharp.aspx

Windows版のインストーラーではVisual Studio 2005/2008があれば、Visual Studioに統合されて、いきなり本格的な開発ができるようになります。

Linux/Mac上のMONOでも動作すると書いてあるので、F#のスタンスとしては、.NET Framework/CLIをMicrosoft Windowsだけの独占技術ではなく、Java VMのようなマルチプラットフォームのエンジンに育て上げたいという印象を受けます。

F#の印象

書籍を読んだ感想ですが、言語仕様はErlang以上に「ややこしい」です。
サンプルのソースを読んでもなかなかスーッと頭に入ってきません。

＃これを読んで、Erlangのシンプルさというのを非常に痛感しました。

コンセプトとしては、「.NET Frameworkとの互換性もとりながら関数型言語の良いところを組み込む」ということで、手続き型言語的な書き方も許す一方で、ML互換の書き方、F#固有の表現もありということで、プログラマのスタイルによって、同じことを実現するにもいろいろなコードが書ける印象を受けました。

＃まあ、ある意味Perl的であります。
＃書いたときには、「俺って天才かも！」というファンタスティックなコード
＃を書いたつもりでも一ヵ月後には、「何でこう書いたんだっけ？」みたいな。

ML互換ライブラリ用DLLなるものもあり、OCamlやHaskelなどをすでに使っている方は、逆にすんなり入っていけるのかもしれません。

F#の書籍

日本語の書籍はないようなので、英語の書籍を参考にしました。

Foundations of F# (Expert's Voice in .NET)

Expert F# (Expert's Voice in .NET)

Foundationのほうは、本当に基本的な文法や特徴を羅列しただけの本です。
Expertのほうは、多少突っ込んだ話になっていますが、やはりさらっと流したような内容です。

F#とは？

ネタはたくさんあったのですが、更新がずいぶんとぎれてしまいました。

先日までの記事で、Erlangの話をしていましたが、あれからいろいろ調べていたところ、Microsoftが.NET Framework上で動作させることを考えているF#という関数型言語があるということでいろいろ調べてみました。

背景としては、いろいろあるようですが、

• interactive scripting like Python,
• the foundations for an interactive data visualization environment like MATLAB,
• the strong type inference and safety of ML,
• a cross-compiling compatible core shared with the popular OCaml language,
• a performance profile like that of C#,
• easy access to the entire range of powerful .NET libraries and database tools,
• a foundational simplicity with similar roots to Scheme,
• the option of a top-rate Visual Studio integration,
• the experience of a first-class team of language researchers with a track record of delivering high-quality implementations,
• the speed of native code execution on the concurrent, portable, and distributed .NET Framework.

などから、今後.NET Frameworkのある部分の中心開発言語になるのではないか？とも言われています。

ただし、C#などがなくなって、今後全てをF#に移行するかといえば、そういう話ではなく、C#が得意な部分はC#で実装して、F#が得意な部分はF#で実装してというような、アプリケーションのドメイン毎の使い分けが重要になると考えているようです。

Safety of cardiac pacemakers and ICDs in magnetic resonance imaging

Safety of cardiac pacemakers and ICDs in magnetic resonance imaging

ペースメーカーやICD植え込み患者に対するMRI撮影は安全か？という話題です。
NASPE Exam.という電気生理・ペーシング治療全般を対象にした北米地域の試験の問題で、「ペースメーカー患者に対してMRI検査を施行してもよいか？」という設問があり、「しても良い」という選択肢が正解とされていたことで、私の周囲で騒然となりました。
その理由は、「ペースメーカー患者に1.5TのMRIを施行しても問題がなかった」という論文を根拠にしているようですが、「問題がなかった」ということと、「安全だ」ということは全く別問題です。
こちらの論文では、1.5TのMRIを使ってファントム試験をしていますが、シビアな機能不全を起こすケースがあるので安全ではないと結論付けています。

このあたりは、ペースメーカーやICDを植え込むことによって診断や治療の選択肢が制限されることに対する医師、あるいは患者の抵抗をペースメーカー業界がなんとか抑え込みたいという業界の意思が全世界的に働いている中で、そういった楽観的あるいは無責任な議論に科学的なアプローチから一石を投じる論文だと思います。