ImageJマクロでの解析におけるメモリの扱いについて

[Yuki Ohta]

いつも勉強させていただいております．

慶應大学博士課程の太田と申します．

マクロを使ったImageJでの画像解析について質問があり，

投稿させていただきました．

現在使用しているマクロを添付いたします．

（txtは添付できないようなので画像です．）

 

ライトシート顕微鏡で撮影した三次元画像から，

RFP(channel2)+の細胞塊の体積を算出しようとしています．

個々の細胞のSegmentationをする必要はなく，

塊としての体積が出せれば良いという状況です．

 

元のデータはサイズが大きすぎるので分割していますが，

それでも１つ１つのファイル（LIF形式）は1GB前後あり，

合計すると5TB程になります．

 

添付のマクロをFijiにインストールして走らせていると，

最初はサクサク進むのですが，徐々に動作が遅くなってしまいます．

扱うデータのサイズや数が多すぎることは重々承知ですが，

メモリをモニタリングしていると不必要な蓄積が見られるので，

メモリの扱いにも問題があるかと考えております．

現在メモリ対策で行なっていることは以下の点のみです．

 

・ImageJへのメモリの割り当てを最大にする

・バッチモードで進行，不要な画像はすぐに閉じる

・輝度があるスライスのみをcropしてから計算

・１枚解析が終わるごとにcall("java.lang.System.gc")を実行

・OS上でも30分おきにmemory cleanを実行するように設定

 

その他，ネットで調べた付け焼き刃な知識で

-XX:MaxMetaspaceSize=256m

-XX:MetaspaceSize=256m

-XX:TargetSurvivorRatio=50

-XX:+UseConcMarkSweepGC –

などのコマンドを入れてFijiをlaunchしてみたものの，

 

Java HotSpot(TM) 64-Bit Server VM warning: ignoring option PermSize=128m; support was removed in 8.0

Java HotSpot(TM) 64-Bit Server VM warning: Using incremental CMS is deprecated and will likely be removed in a future release

[WARNING] Ignoring invalid argument: -XX:MaxMetaspaceSize=256m

[WARNING] Ignoring invalid argument: -XX:MetaspaceSize=256m

[WARNING] Ignoring invalid argument: -XX:TargetSurvivorRatio=50

[WARNING] Ignoring invalid argument: -XX:+UseConcMarkSweepGC

 

のエラーが出てしまい，途方に暮れています．

 

勉強し始めたばかりでマクロ自体もかなり稚拙だと思いますが，

サイズの大きいデータや大量のデータを扱う際，

どのような工夫をすれば良いのか等，アドバイスをいただけますと幸いです．

よろしくお願いいたします．

[塚田 祐基]

太田さん、

大きいサイズのデータを扱っているとのことで、
正直、5TBのデータを一気に扱う機会がないので
的確なアドバイスができるとは思いませんが、いくつか案があります。

1. 処理をプログラムごとに分ける
z-projectionなどした後に処理をいろいろとしているようですが、
projectionなどの処理をしたデータを一度保存し、
改めて別のマクロで保存した中間データを読み込み別の処理をする、
とやると、始めの処理のメモリの問題から解放されると思います。
メモリを管理をモニタリングしているのであれば、負荷がかかっている処理だけ
個別に分けるというのも手だと思います。
データを一時保存するディスクスペースは必要になります。

2. JVMではなく、ImageJのメモリ設定をする
太田さんがされているImageJのメモリ割当設定は起動後の設定だと思いますが、
以下のサイトを参照に設定をしてみてください。
http://imagejdocu.tudor.lu/doku.php?id=faq:technical:how_do_i_increase_the_memory_in_imagej
私もきちんと理解していませんが、JVMのメモリ管理はいじる必要はないと思います（基本的に自動で適切に管理しているので）。
お使いのマシンスペックに依存しますが、64bitマシンであれば理論的なメモリの制限はないので、マシンに積んでいる分のパフォーマンスは得られるはずです。
また、似た問題についての議論をネット上で見つけたので
ご参照ください。適切なgcがちゃんと動いているかを確認するのも有益だと思います。
http://stackoverflow.com/questions/22912063/automatically-release-unused-memory-in-imagej-fiji

3. 問題を避ける
元のデータサイズが大きいので、解像度を下げて扱える程度の
サイズに落とすのも一つの手です。
知りたいことに完全に依存するのですが、必要最低限の解像度でデータ処理することは工学的によくやります。
例えば解像度を下げてデータを取得することも選択肢としてあると思います。

挙げている順番は思いついた順で、優先順位などはありません。
また、研究内容を知った上でどの程度の要件があるのかを理解しないと
適切なアドバイスにならないと思うので、一般的な対処法の一つとして受け取っていただければと思います。

大きなサイズのデータの扱いはこれからさらに需要が高まるので、
いろいろな解決方法をコミュニティとして共有できると嬉しいです。

ご参考になれば幸いです。

塚田　祐基

On 2016/12/21 15:26, Yuki Ohta wrote:
> いつも勉強させていただいております．
>
> 慶應大学博士課程の太田と申します．
>
>
> マクロを使ったImageJでの画像解析について質問があり，
>
> 投稿させていただきました．
>
> 現在使用しているマクロを添付いたします．
>
> （txtは添付できないようなので画像です．）
>

> <https://lh3.googleusercontent.com/-EI7G6IE-IK8/WFogcZ2OMaI/AAAAAAAAAC0/Iqey48XG74YsqQ1X7XTXNWltYfMCley7QCLcB/s1600/Keio_ohta_macro.tiff>

> --
> このメールは Google グループのグループ「ImageJ-jp」に登録しているユー
> ザーに送られています。
> このグループから退会し、グループからのメールの配信を停止するには
> imagej-jp+...@googlegroups.com
> <mailto:imagej-jp+...@googlegroups.com> にメールを送信してください。
> このグループに投稿するには imag...@googlegroups.com
> <mailto:imag...@googlegroups.com> にメールを送信してください。
> このディスカッションをウェブ上で閲覧するには
> https://groups.google.com/d/msgid/imagej-jp/6f5902dd-6809-4418-a910-16b468232195%40googlegroups.com
> <https://groups.google.com/d/msgid/imagej-jp/6f5902dd-6809-4418-a910-16b468232195%40googlegroups.com?utm_medium=email&utm_source=footer>
> にアクセスしてください。
> その他のオプションについては https://groups.google.com/d/optout にアクセ
> スしてください。

[Kota Miura]

太田さん、塚田さん

JVMのオプションをfijiで使うときosxの場合だと私の場合は.bash_profileで

alias fiji='/Applications/Fiji.app/Contents/MacOS/ImageJ-macosx'

を設定しているので、これだと

   fiji <JVM options> -- <imagej options> <fiji options>

というコマンドの書き方になります。重要なのは二重ハイフン（--）が、JVMのオプションとimagej/fijiのオプションのセパレータになっていることです。JVMのオプションだけを付ける場合でもこの二重ハイフンは最後尾につけないと、ImageJに対する引数として解釈されてしまうので”[WARNING] Ignoring invalid argument”という警告が表示されJVMのオプションが無視されます。太田さんのコマンドだと、どうもハイフンを一つしか付けていないのではないか、と思います。この点、確認してみてください。

あと、garbage collectorの選択ですが、巨大なファイルをマクロで繰り返し扱うような処理の場合、やはりメモリは開放させたいので

    fiji -XX:+UseParNewGC --

もしくは

    fiji -XX:+UseConcMarkSweepGC --

がおすすめです。fijiはデフォルトではConcMarkSweepGCを使っているはずなので、後者は意味がなさそうなものですが自分でオプションで設定するとなぜか挙動が良くなるので、ConcMarkSweepになにか余計な設定がFijiのランチャーに加えられているのではないかと思っていますが、このあたりは未確認です。

また、これらの場合、自動的なガーベージコレクション（GC）を邪魔しないようにcall("java.lang.System.gc")の処理は行わないほうがいいです。このシステムコマンドは、かなり古いもので、たしかにメモリは開放できるのですが、これをやってもやらなくても結果としてヒープの占有はあんまりかわりません。逆にモダンなGCに対して強制的なガーベージコレクションがしゃっくりみたいな感じで挟まれることになり全体的に遅くなってしまいます。

また、ヒープサイズの設定（-Xms  -Xmx）ですが、あまり大きすぎるとGCの効率が悪くなるので、必要なメモリサイズに設定することが肝要です。かつてはRAMが小さかったのでとりあえず最大にしたりしていましたが、昨今は余裕があるので、このあたりも見直してみると良いでしょう。

より新しいGCであるG1ですが、fijiではまだ使えないようです（ -XX:+UseG1GCを使うと起動しない）。一応いちばんいいことになっているので、javaから直接imageJのメインクラスを呼び出して、それに -XX:+UseG1GCをオプションとして加えるなど、工夫できるかもしれません。

あとは、自動的なGCを最適に作動させるために、他にいろいろオブジェクトのふるさの定義など設定してチューニングすることもできますが、この場合はやはりjavaのコマンドで呼び出して設定をいろいろ比較し、オブジェクトのライフタイムを把握する必要があります。

三浦

imagej-jp+unsubscribe@googlegroups.com

<mailto:imagej-jp+unsubscribe@googlegroups.com> にメールを送信してください。
このグループに投稿するには imag...@googlegroups.com
<mailto:imagej-jp@googlegroups.com> にメールを送信してください。

このディスカッションをウェブ上で閲覧するには
https://groups.google.com/d/msgid/imagej-jp/6f5902dd-6809-4418-a910-16b468232195%40googlegroups.com
<https://groups.google.com/d/msgid/imagej-jp/6f5902dd-6809-4418-a910-16b468232195%40googlegroups.com?utm_medium=email&utm_source=footer>
にアクセスしてください。
その他のオプションについては https://groups.google.com/d/optout にアクセ
スしてください。

--
このメールは Google グループのグループ「ImageJ-jp」の登録者に送られています。
このグループから退会し、グループからのメールの配信を停止するには imagej-jp+unsubscribe@googlegroups.com にメールを送信してください。
このグループに投稿するには、imagej-jp@googlegroups.com にメールを送信してください。
このディスカッションをウェブ上で閲覧するには、https://groups.google.com/d/msgid/imagej-jp/e0b0d4bc-fc83-e29c-1fe6-4eca504b90e0%40b.mbox.nagoya-u.ac.jp にアクセスしてください。
その他のオプションについては、https://groups.google.com/d/optout にアクセスしてください。

[Yuki Ohta]

塚田先生

早速のご返信ありがとうございます．

ImageJのメモリ設定は，確認した所

実装RAMの75%を超えた値を設定していました．

そのせいでgcがうまく働かず，

仮想メモリに入ってしまっていたかもしれません．

マクロ内のgcのcallは機能しているようですが，

劇的な効果はなく，最終的には蓄積してしまいます．

画像の解像度は，CCD imagerでbinningをかけて最低まで落とし，

z方向のスライスもなるべく間隔を大きくして撮影していたのですが，

それでもこれほどのデータ量になってしまいます．

撮影後のデータから解像度を下げることは可能なのでしょうか．

ファイル形式についてもTIFFに変えるなどはあまり効果がなく，

JPEGで圧縮すると画像の情報や解析結果が変わってしまったので

LIFのままで解析を進めていました．

storageは十分あるので，処理を分割することも検討いたします．

（情報共有のため，メールでのやり取りを転載させていただきました．）

太田

[Yuki Ohta]

三浦先生

早速のご返信ありがとうございます．

JVMのオプションは何とか警告なく認識されるようになりました．

二重ハイフンを入れたつもりが，「--」ではなく「–-」というよくわからない記号になってしまっていました．

要するに，打ち間違いです．単純なミスですみません．

SurvivorRatioやNewRatio，ヒープサイズ，メタスペースサイズなどは

特にチューニングはしない方が良いのでしょうか．

ヒープは大きめに設定しておいて，TargetSurvivorRatioを上げるなどは意味がないでしょうか．

また，マクロ内でのgc callはむしろ邪魔になるんですね．

多少はgcされますがあまり効果がないので疑問に思っていました．削除します．

オブジェクトのライフタイムでチューニングするのはとても効果がありそうですが，私には敷居が高そうです...

ひとまず，オプションでUseConcMarkSweepGCを入れる事でどの程度改善されるか試してみます．

太田

[Kota Miura]

太田さん

メモリ領域のチューニングはこれといった決まりがあるわけではないのでなんともいいがたいですが、私だったら

    fiji -XX:+UseParNewGC --

をためしてヒープ領域の大きさが単調増大みたいにならない様子だったらそれでよしとして、これにあと-Xmsと-Xmxの設定を行うぐらいだと思います。理由はそれ以上チューニングする必要性を感じないからです。オブジェクトのサバイバル時間や、オブジェクト世代の比率などの微妙な調整に時間をかけるのだったら、そのまえにJavaないし他のJavaのオブジェクトにアクセスできるスクリプトで書いて不必要になったらオブジェクトをnullにして自動GCを待つ形にするなど、きっちり管理したほうがいい、と私だったら判断します。

ざっとマクロを眺めてみましたが、まだスリムにできるなという印象を持ちました。スタックを複製するところが何箇所か、あと画像をマージするところで新たに3番目のスタックを作ったりしているところがあり、データサイズを考えればそうしたところでメモリも時間も食います。そうしたところを工夫して、本当に必要な複製や新規のスタック作成なのかよく考え、マクロのコマンドで代替に使えるものがないか探してなるべく総メモリ消費を抑えるような処理にすることをおすすめします。

三浦

--

このメールは Google グループのグループ「ImageJ-jp」に登録しているユーザーに送られています。

このグループから退会し、グループからのメールの配信を停止するには imagej-jp+unsubscribe@googlegroups.com にメールを送信してください。
このグループに投稿するには imag...@googlegroups.com にメールを送信してください。
このディスカッションをウェブ上で閲覧するには https://groups.google.com/d/msgid/imagej-jp/efe4c3d6-b416-4ff7-92ee-b721274bb072%40googlegroups.com にアクセスしてください。
その他のオプションについては https://groups.google.com/d/optout にアクセスしてください。

[Yuki Ohta]

三浦先生

返信が遅れまして失礼いたしました．

UseParNewGCで試したところ，動作が遅くなる事もなくなり，

問題なく全て解析できるようになりました．

マクロについても，アドバイスをいただいた通り，不要なduplicateの削除や

Object Counterの際にオリジナルイメージをcloseするオプションを使うなど，

メモリ消費を抑えるようにした事でかなり改善されたように思います．

これからも勉強させていただきます．

お忙しい中ご回答いただき，本当にありがとうございました．

慶應大　太田

2016年12月22日木曜日 20時08分16秒 UTC+9 Kota Miura:

太田さん

メモリ領域のチューニングはこれといった決まりがあるわけではないのでなんともいいがたいですが、私だったら

    fiji -XX:+UseParNewGC --

をためしてヒープ領域の大きさが単調増大みたいにならない様子だったらそれでよしとして、これにあと-Xmsと-Xmxの設定を行うぐらいだと思います。理由はそれ以上チューニングする必要性を感じないからです。オブジェクトのサバイバル時間や、オブジェクト世代の比率などの微妙な調整に時間をかけるのだったら、そのまえにJavaないし他のJavaのオブジェクトにアクセスできるスクリプトで書いて不必要になったらオブジェクトをnullにして自動GCを待つ形にするなど、きっちり管理したほうがいい、と私だったら判断します。

ざっとマクロを眺めてみましたが、まだスリムにできるなという印象を持ちました。スタックを複製するところが何箇所か、あと画像をマージするところで新たに3番目のスタックを作ったりしているところがあり、データサイズを考えればそうしたところでメモリも時間も食います。そうしたところを工夫して、本当に必要な複製や新規のスタック作成なのかよく考え、マクロのコマンドで代替に使えるものがないか探してなるべく総メモリ消費を抑えるような処理にすることをおすすめします。

三浦

2016-12-22 4:31 GMT+01:00 Yuki Ohta <yuki...@keio.jp>:

三浦先生

早速のご返信ありがとうございます．

JVMのオプションは何とか警告なく認識されるようになりました．

二重ハイフンを入れたつもりが，「--」ではなく「–-」というよくわからない記号になってしまっていました．

要するに，打ち間違いです．単純なミスですみません．

SurvivorRatioやNewRatio，ヒープサイズ，メタスペースサイズなどは

特にチューニングはしない方が良いのでしょうか．

ヒープは大きめに設定しておいて，TargetSurvivorRatioを上げるなどは意味がないでしょうか．

また，マクロ内でのgc callはむしろ邪魔になるんですね．

多少はgcされますがあまり効果がないので疑問に思っていました．削除します．

オブジェクトのライフタイムでチューニングするのはとても効果がありそうですが，私には敷居が高そうです...

ひとまず，オプションでUseConcMarkSweepGCを入れる事でどの程度改善されるか試してみます．

太田

--
このメールは Google グループのグループ「ImageJ-jp」に登録しているユーザーに送られています。

このグループから退会し、グループからのメールの配信を停止するには imagej-jp+...@googlegroups.com にメールを送信してください。
このグループに投稿するには imag...@googlegroups.com にメールを送信してください。