|
デザイン&開発理論
4. その他
4-a. 共焦点データの読み込みについて
4-b. 時代背景
4-c. ソフトウェア像
4-d. 開発時の仕事の分配について
4-e. プロジェクトの進め方、言うべきことと言わないでおくこと
4-f. 今回苦労した所
1. グレースケール値のズレ
2. オブジェクトの 3D ローテーション(カメラローテーション)
3. パラメータ群の追加
4-g. 生物学者である私がなぜソフトウェア開発を行ったのか?
4-h. 今後の展望
4-a. 共焦点データの読み込みについて:
共焦点顕微鏡は各社から出ており、会社ごとにファイルフォーマットが異なる。このファイルフォーマット群に対応するだけでも相当な開発リソースを要する。なのでデータの読み込みに関しては ImageJ 上で loci_tool というプラグインを用いて、各社の異なるファイルフォーマットを 8bit のマルチレイヤー tiff に変換して、本ソフトウェアではその tiff ファイルのみをサポートするという形にした。
4-b. 時代背景:
2006 年位から、GPU でレンダリングを行うソフトウェアが多数現れ始め、それに伴い搭載ビデオメモリも増大していった。同時に液晶ディスプレイも大型化し、1920 X 1200px という高解像度のものが安価で買えるようになった。また、2008 年に NVIDIA から発売された GTX280 は、これまでのグラフィックカードに比べて 2 倍の性能を有しており、ビデオメモリも 1GB と多い。このグラフィックカードをもってして初めて共焦点顕微鏡からのマルチチャネルボリュームデータを、高品質で安価にかつ実用的にリアルタイムでレンダリングすることが可能になった。
またこのころ医学/生物学分野ではソフトウェアによるレジストレーションが頻繁に使われ始め、異なる個体を 3 次元空間で重ね合わせて形態比較することが行われるようになった。ここでもマルチチャンネルのボリュームレンダリングが必要とされる。
また、2007 年に Brainbow という、複数の蛍光タンパク質をランダムで発現させて組織をラベルする方法が発表され、90 チャンネルを含むボリュームデータの作成が可能になった。余談ではあるがこれに伴い、2007 年と 2008 年の Olympus BioScapes コンテストには Brainbow でラベルした神経線維群が入賞している。
このような時代背景からも、本ソフトウェアが 2009 年にリリースされるのは非常に良いタイミングだったと思う。
4-c. ソフトウェア像:
私が目指すソフトウェア像は、コンピュータのプラットホームが許す限り、いつまでもユーザーに使い続けてもらえるものである。これを可能にするためには、徹底的に使い手のワークフローを洗いあげ、繰り返しの手順の数、マウスの動きなどを解析し、結果としてなるべく短い時間で複雑な作業がこなせるようにユーザーインターフェースを組む必要がある。また今回、画質に関しては複数の人達からデータをもらい、さまざまな癖がついたデータを立体再構成し、それらに対応していくことで必須なパラメータが追加され、結果として画質の向上を達成した。また、一度実装してから使い勝手の悪さ故に削った機能も複数ある。もし最初から機能ありきで各種パラメータを実装していたら不必要なものや、使い勝手が悪いパラメータ群の集まりになったと思う。
ソフトウェアの開発とは主に、機能実装とバグ取りの繰り返しである。機能をデザインして実装する、すると予期しなかった動作をすることが往々にしてある。そのとき、開発チーム内部のユーザー(調律師)が作り手に対して「何が問題なのか」を伝えることが出来なければソフトウェアの磨き上げは進まない。またその時に間違えたことを伝えれば、ソフトウェアは間違えた方向へ発展する。
物事を何日にも渡って真剣に吟味する調律師が開発チームにいない、そうした磨き上げられていないソフトウェア(パラメータが機能しない、異常に作業手順が多い、必要な機能は無いのに無くても問題ない機能は充実している)が世の中に山ほど存在する。そういったソフトウェアは長期に渡ってユーザーに使い続けられることは無く、ユーザーはすぐに他のソフトウェアを探し始め、そして移ってゆく。
4-d. 開発時の仕事の分配について:
開発はプログラマーと私(生物学分野、3D 神経解剖学者)の 2 人で一年をかけて行なった。こういった異分野間での共同作業時に、お互いのことをどれだけ理解すれば良いのか、人によって様々な意見があると思う。人によってはお互いがお互いの異なる学問を深く理解する、時には作業そのものを体験させる、という意見もある。
しかしプログラマーにはプログラマーの人生があり、生物学者のように 3 年間論文無くても普通、というわけにはいかない。また彼らの将来を考えたときに、人生を削ってまで生物学の実験を付け焼き刃ですることにどれだけの意味があるのか私には分からない。なので今回プログラマーにはプログラミングに専念してもらった。尋ねられた範囲では生物学のことについて答えたが、こちらから言って実際に共焦点を撮らせるとか、抗体染色をさせるなどは行っていない。実際にそれをやらせたところで、グレードの低いデータしか得られず、共焦点顕微鏡とサンプル調整の神髄が見えるようになるまでには膨大な時間がかかる。
またただでさえアカデミックソフトウェアは企業で開発するソフトウェアと比べて、圧倒的に開発リソースがとぼしい。しかしアカデミックソフトウェアであっても作成すれば、コマーシャルソフトウェアと比較される。その状況で開発リソースをさらに別のことに割くことを、私はどうしてもできなかった。
4-e. プロジェクトの進め方、言うべきことと言わないでおくこと:
まずプロジェクトには長期目標と短期目標がある。しかし元が生物学者である私の立場からは、どの機能実装がプログラマーにとって難しいのか、どういった順序で機能実装を行っていくのが後々のバグ取りをやりやすくするのか、そういったことの見通しが立たなかった。そこでプログラマーとは日頃から大体の時間単位を用いて話し、ソフトウェアの構造を自分で調べたり、バグから構造を類推して相手に尋ねたりした。そうすることで自分の内部で時間と機能実装の相関図を作っていった。また一緒に開発を進めていくうちに解決された問題群から、だいたいどれが短期で長期なのか分かるようになってきた。
開発時には、まずはプロジェクトがしっかりと進むことが大事なので 3〜4 個の一週間で解決できそうな目標を、重要度の順位付きで毎週提案した。同時に長期的な目標も 2 個提示した。2 個に絞った理由は彼も私もあまりに多くの解決できそうにない物事が山積みだと、短期で出来ることの問題処理のスピードに影響するからである。そうして提示した目標のうち、一週間で短期のもの 2 個解決できるときもあれば、短期を全部解決できてかつ長期を一部解決できるときもあった。ちなみにミーティングは毎週 3 時間程度、メールは週に 3 往復位が平均だったと思う。
開発開始後、半年程度経過した時点ではやりたいことの 2 割程度しか発言しなかった。本気で全てを解決しようとするとあまりに問題点が多すぎて、こちらとしても溜まるストレスが尋常ではないので(もちろんそれらを提案されたプログラマーも)、「どのみち今は世に出せる状態ではないし、いつか解決できるだろう」位の楽観視がちょうど良いと思う。
開発開始一年後、リリース日も近づき、残っているバグも数日で解決できるものばかりになってきた。私が使用していて気付いたことがあれば、その場でバグリストや機能要望リストに追加し、毎週それら全てについてプログラマーと協議するようになった。すなわち、言いたいことのほぼ全てを言えるようになった。また初回リリースにあたって何を仕上げて、何を削るのか(リリースまでにバグがクリアできない、バグレポートの山を避けたい)などは、およそリリース 2 ヶ月前に方針が決まった。
4-f. 今回苦労した所:
A. グレースケール値のズレ
多くのボリュームレンダリングソフトウェアは、暗いグレースケール値のシグナルをデフォルトで明るい値に持っていて表示する。その結果、暗いシグナルが本当に明るいシグナルを遮ってしまい、できあがりの絵は撮影者のイメージと微妙にずれる。私自身もこの仕様に慣れており、ボリュームレンダリングとはそういうものかと思っていた。しかし、Maximal intensity projection や Imaris2.7 の ray casting と比べると初期の本ソフトウェアの絵は明らかに、グレースケール値がずれていた。それは光源のせいかとも思ったが、プログラマーと詳しく話すうちに、元のライブラリの問題であると我々は気づいた。当初はこの問題にどのくらいの時間を必要とするのか見当もつかなかった。しかし 1 年近く開発を進めているうちにプログラマーの技術発展、人脈の増加といったものから、ある時いきなり 3 日で解決できた。問題が存在してもすぐに解決できそうにない場合、その時点で開発リソースを割かず、ただ覚えているだけというのも案外一つの解決法なのかもしれない。
B. オブジェクトの 3D ローテーション(カメラローテーション)
10 年前はこれだけで論文になり、研究室のメインテーマとなりえた。今回、最後の最後まで望んだ通りの 3D ローテーションが達成できなく、3 週間ほど全く進展がない状態が続いた。こればっかりは私もどうにもできず、ボールに置き換えて回転させる方法や、xy 軸方向と z 軸方向の回転を切り替える方法などの提案程度しかできなかった。また他に、SCI でフリーで配布しているソフトウェアのソースコードを入手してはと提案し、プログラマーが実際に手に入れてみたところ、癖が強すぎてとてもじゃないが理解できるものではないとのこと。彼曰く、カメラローテーションはみんなが独自で改良して実装している、企業はそうした技術がある人を雇っているだけで、カメラローテーションの王道は無い。とのこと。この問題が解決できないとき私は問題の背景を話し合うことしかできなかったが、全くバックグラウンドが異なる者同士であるため、それでも意志の疎通をはかれ、かつ良い勉強になった。
生物学の同じ分野の者同士ではあれをやったか、これをやってはどうか?と問題を抱える側をある程度追い詰めて次の道を導き出せるのだが、今回のような場合はそれはできず、私としてはプログラマーの考えを聞いて多少の提案をすることしかできなかった。
C. パラメータ群の追加
どのようなパラメータが共焦点データに有効なのかを、まず私の 10 年間における共焦点顕微鏡の使用経験から考えた。その結果、陰影、深さ方向の光量減衰、輝度調整、明るさ調整、low/high スレッショルドなど多くのパラメータをプログラマーに要望することができた。またガンマ調整に関しては他人が撮った共焦点データを解析していて実装を思いついた。
しかし、実装されてきたパラメータのほとんどは、こちらの思い描いた動作と微妙に異なっていた。例えば low/high スレッショルドを動かすとガンマも同時に動く、陰影は値をゼロにしてもエフェクトが残っている、深さ方向の光量減衰は非線形にエフェクト量が増える、その他多くのバグ等々。
これらを使用した時、まず私はなんとなく違和感を覚えた。そして何がこの違和感を生じているのか、ひたすら同じデータを再構成して、何時間もパラメータをいじって、その挙動からソフトウェア内部の処理を推察した。その後ノートに現在行われている内部処理のグラフと、本来行って欲しい処理のグラフを書き、そのノートをデジカメで撮ってプログラマーにメールで送信するということを行った。
こうした事柄はプログラマーと私の意識のズレからくる問題であり、非常に発見が難しかった。
4-g. 生物学者である私がなぜソフトウェア開発を行ったのか?:
最初からソフトウェア開発することを目的としていたわけではない。10 年に渡って共焦点顕微鏡とつきあってきた結果、再構成ソフトウェアに対して不満があった。連続切片から脳内で再構成すると存在している構造が、コンピュータ上ではどうしても可視化出来ない。なんとか可視化しようとするといくつもの立体再構成ソフトウェアを必要とする。
その不満故に visualization のプロ達の前でプレゼンテーションをして、自分の限界を超えてみたかったのだと思う。ユタ大に来て半年くらい、SCI 研究所で行われる定例ミーティングに勝手に顔を出し、自分が作った絵や、4D 解析の手法などをプレゼンテーションしていた。これらに対しては、どうやってその絵を作ったのか?という質問が多かった。
そのうちに私が、5 つのソフトウェアを使い分けてかつ自分で改良していることが SCI の研究者に伝わり、「よし、なら全ての機能を含むオールインワンのソフトウェアを Hideo の為に作ろう」と Chuck Hansen 教授が言ったのがきっかけだった。私はその場でホワイトボードに、共焦点顕微鏡から生じるボリュームデータの特徴と、何がこれまでのソフトウェアに足りなくて、私自身が何にストレスを感じているのかを述べた。(ソフトウェアの制作サイドからすると、解決するべき問題、ソフトウェアのニーズ、使い手のワークフローが得られた。)その後、Hansen 教授の研究室で本ソフトウェアの開発を専門に遂行する Yong Wan 大学院生を得て、彼と私との共同研究が始まった。
ちなみにこのソフトウェアの開発には一切の予算が付いていない。また、私は完全に趣味で開発しているため、ソフトウェア実行環境は自前で整え、学会発表も行っていない。自分で予算を持っていないポスドクであるのに本当に好き勝手にやらせてもらっている。なおかつこちらが困ったときには惜しげもなくサポートをしてくれる現ボスの Chi-Bin Chien 教授には深く感謝している。
4-h. 今後の展望:
今後、使用するビデオメモリの量を減らすことで、10 チャンネル以上のボリュームデータにも対応していきたい。まだ足りない基本機能の整備の他、4D データへの対応、自動セグメンテイション、ソフトウェア内でのポリゴンデータの作製、立体形態の計測とその結果の可視化ということを考えている。
大綱英生
1. 連続切片上に存在するいかなるシグナルも、3D で可視化できる
2. 5 分以内に、3 重染色データから最高品質の画像を作成可能
3. ユーザーは自分が何をしているのか、状況を「瞬時」に「完全」に把握できる
|