HorliX/Horos 動作テスト プチβテスト 

HorliX/Horos は、開発環境ではそれなりに動くようになってきたので、他の Mac で動くかどうか試してみた。とはいっても手持ちの Mac ですぐに使えそうなのは、一昔前の MBP ( Mac Book Pro) のみ。

これでがんばってみる。

 

一般の Mac での動作確認

コードに署名をしたものは、やはりというべきか開けなかったが、無印は問題なく動いた。

ややパワー不足かと思っていたが、「ノートにしては大画面」+「GPU 使用」のおかげでかなり鮮明な画像を描いてくれた。

 

アイコンなどカスタマイズ

また、某教育機関向けのカスタマイズ作業にもとりかかった。アイコンを変えただけだがけっこうかわいくなった。→G-HorliX と命名。

まだ、公開許諾が取れてないので、ぼかしいれなきゃならないのが残念。

公開許諾が取れましたので、それに関する記事を書きました。

解剖ちゃんホーリックス

ネットワーク対応 PACS編

これで、同一ネット内に2台の HorliX/Horos がつながったので、PACS 的に DICOM 画像を受け渡しできるか試してみた。(PACS 関係は詳しくないので間違いがあればご指摘ください)

MacBookPro に HorliX

MacBook に G-HorliX

が走っている。AEタイトルや IP アドレスなどを適当に設定。

G-HorliX でツールバー上の「Send」アイコンを押下するとこのようなダイアログが出現する。

以前に落としていたダイコム画像を MacBookPro の HorliX に Send する。

一生懸命送ってます。

HorliX 側でも受領中。361枚のシリーズものなので数分かかる。感心したのは受領する度に通知が表示されたこと。

開いてみる。

ちゃんと送れてましたね。

なお、その後、大容量PACSサーバー Orthanc にもほぼ同様のやり方でファイル転送できるようにもなりました。→ HorliX can link with Orthanc

 

ネットワーク対応 SSL通信

続いて、これを SSL 通信でおこなってみたい。というのもデバッグしているとき、本家 Horos のコードのままだとバグがでているのに気がついたから。わかる範囲で修正してエラーメッセージはでなくなったが、正しく動作しているか確認したいのだ。

と思ったのですが、いきなり自己証明書で PACS 的な使い方をするとわけがわからなくなりそうなので、まずはウェブサーバー機能で試す。

SSLテストは、OpenSSL のコマンドを叩かないといけないのでいつも避けてたのだが、OS X はキーチェーンアクセスというものを使ってサーバー証明書がグラフィカルに作れるらしい。まずはそこから。

キーチェーンを起動して、証明書アシスタント >> 証明書を作成

 

指示に従って項目を選択。

大事なのは、最終的に「SSLサーバ証明書」をつくること。なお、名称は G-HorliX SSL とした。

これは、いわゆるオレオレ証明書というものです。実稼働させるときは、VeriSign 社などから署名してもらうとよいでしょう。

 

この作業が終わったら、HorliX に戻り 環境設定(preference)>> Web サーバ で設定画面を出し、https 通信を選ぶ。

再起動後、ウィンドウズ機ブラウザからまず

http://(HorliX IP アドレス):3333

を呼び出す。当然、つながらない。次に

https://(HorliX IP アドレス):3333

を呼び出す。今度はつながる。

このときの通信のやり取りをキャプチャソフトで解析すると

となってました。無事、SSL で暗号化されてましたね。

なお、通常の http 通信で同様の解析をすると

こんな感じで傍受できちゃいます。(当たり前ですが)平文ですので、一目見ただけでもやり取りしている DICOM 情報は、TOSHIBA の CT で撮像されたものだとわかりますね。

なお、本家ホロスはクライアントブラウザから URL を呼び出すとサーバは、キーチェーンを利用できない(作製した SSL 証明書を呼び出せない)らしく

というような画面で止まります。予想した通りの挙動。

本家では使えない SSL を使えるようになったり、なんか本家を超え始めた予感。

 

CDからのエクスポート

github issue に↓というヘルプがあった。

 

Can’t seem to load images from CD/DVD.
When DVD is popped in, the pop up window asking what to do with the files comes up, but when “copy” is clicked, the disk ejects without copying the files.

If I try to load them from the “Import” button top left, or from the File >> Import…>>Import Files menu, the copying happens at 1 image / 5 minutes (yes 5 minutes).

Can anyone help?

Mac OS Sierra 10.12.5

え? そんな落とし穴が、と思って HorliX でも CD から画像を読み込ませたが、300枚ほどを1分かからずに読み込みました。

 

HorliX Ver 0.0.1

ホロス( Horos ) のコードを少々手直しすれば、Xcode 9.3 でもビルドは可能です。

まだ gihthub にあげる段階ではないのですが、少々解説します。

Horos on Xcode 9.3

なぜ、ホロスのコードが Xcode 9.3 でビルドできないのかといえば、同包されているライブラリのうちいくつかが 32bit でしかコンパイルされていないためです。

たいていのライブラリはソースを 64bit でコンパイルし直せば、問題ありません(この作業はほぼ終了)。

問題は、ソースがもはや存在しないライブラリです。

ここは私もちょっとひっかかったのですが、そういったライブラリのうち内容が推測できるものに関しては機能を新たに実装し直してビルドを通すことにしました。

こうするとビルドは通るのですが、その代わり元のライブラリはもう使えません。

結局、DICOM Viewer を部分的に作り直しているようなものですね。

このせいでファイル構成などはかなりすっきりしてきたと思うのですが、その代償として機能の一部が犠牲になりました。

代表的なところだとダイコムプリントでしょうか。

関連ソースを読むとネットワーク上のダイコム対応プリンタというものに独自のデータ形式で印刷データを渡しているのですが、前述のように機能が実装してあるソースがありません。がんばれば、実装も可能なんでしょうが、データ形式もよくわからないし、そもそもダイコム対応プリンタなるものが普及しているようには思えない。なので、この機能はオミットしました。

いや、どうしてもダイコムプリンターを使いたいという人がいれば、実装をがんばってみてください。みんな幸せになれますから。

HorliX

また、64bit 化を推し進めるうちにプロジェクト自体が本家 Horos から、微妙に離れてきたようなので(もう、コードも機能も違ってきている)、以前使っていた HorosJ というネーミングは今後止めます。

いちおう、HorliX (ホーリックス)と名付けましたので、今後はこの名称でお願いいたします。

Horos + OsiriX 

なので、Horlix ですね。

 

 こちらの名馬の名にもちらっとひっかけてたりもしますが。

 

DICOM ファイル入手先

HorliX/Horos のサンプル画像として紹介していた akihabara taro 君のページがリンク切れになったようなので、海外サイトなどを物色。

DICOM Library

が目についた。

Web DICOM Viewer はなかなか使えそう。アップロードしたときの匿名化は自動でやってくれた方がいいかな。

試しに腹部 CT のデータを落として、HorliX に読み込ませた。

スライス厚が 0.6mm 程度なので動画書き出しすると面白いかなと思ってやってみました。

どんなもんでしょ?

これ読んでるだけでは伝わらないでしょうが、 HorliX はライブラリを適宜 64bit に置き換えているので、書き出し速度は本家 Horos に比べかなり速くなっています。

 

 

Horos 3.0 をソースからコンパイルする - High Sierra 編 –

HighSierra + Xcode 9.3 の組み合わせだと  HorliX/Horos のビルドはうまくいかないのだけど、HighSierra + Xcode 9.2 の場合は、ビルドはできるようです。

 

今まで試してなかったウェブサーバー機能も試す。

クライアントからブラウザ経由で無事アクセスできました。

画像は日本画像医療システム工業会さんからお借りしてきました。

なんかリンク切れになったようなので、海外サイト紹介の予定。

 

HighSierra 対応、(部分的)日本語化とけっこうイイ線までいってんのかと思います。

なお、Horos のソースを直接改変すれば、High Sierra + Xcode 9.3 でもビルドは可能です。→ Horix Ver 0.0.1

 

 

Horos 3.0 をソースからコンパイルする - Sierra 以前のOS編 –

そういうわけでHoros をソースからコンパイルしてみることにした。OsiriX があっちの世界にいってしまったので、仕方ない。(なお、Horos というのは医療画像ビューアです。詳しくはこちらをご参照ください)

といっても当方の Mac 環境は MacBook (12インチ)なのでがんがん使うわけにもいかないだろう。コンパイルしてちょっと使ってみる程度を目標にする。

なお、OS は 10.12 、Xcode は 9.2 。

準備(ここが大事)

CMake と pkg-config が必要になってくるので、あらかじめインストールしておく。homebrew がはいっているならば、

brew install pkg-config
brew install cmake

で問題ないと思う。

こっから先は単純作業。

 

ソースコードの取得

ホロスプロジェクトの github リポジトリからソースコードを取得する。

git clone "https://github.com/horosproject/horos.git" ~/horos3

数分で取得は終了すると思う。




コンパイル

先ほどつくった horos3 内にある horos.xcodeproj をダブルクリック。

自動的に Xcode が立ち上がるはずだ。

メニューバー >> Product >> Schema

で、まずコンパイル対象に Unzip Binaries を選ぶ。これでまず Build 。

これはあっという間に終わる。

次に、お待ちかね、Horos のコンパイル。

先ほどと同様の手順で今度は Horos を選ぶ。

で、 Build 。

この後、Xcode は、黙々とコンパイルしてくれる。ITK (というライブラリ)をコンパイルするのにかなり時間喰っている様子。途中、NSForm は deprecated ですよとかアラートが出るが(たぶん)気にしなくてよい。

MacBook だと 30 分程度でコンパイルは完了する。とりあえず Run させてみましょう。

無事立ち上がる。

試しに適当なダイコムファイルを喰わせてみる。

大丈夫、読み込めました。

以前に作成した3Dモデルは

いけてます。

お疲れさまでした。

なお、現在(2018/05)、github に上がってるバージョンは 3.0.1 です。

 

日本語化

Ver 3.0.1 から部分的にですが、Horos が日本語化されました。

上記のコンパイルがうまくいけば、特別な操作なしに日本語化された状態で立ち上がると思います。

てか、私が日本語化したところを本家が取り込んだんですけどね。

Horos 本家

Horos 日本語版 HorliX

時間がなかったのでサブメニューが日英混在という…。

ここはこう訳してほしいというのがあれば、コメント欄にでも書き込んでおいてください。手がすいたときに反映させます。

 

 

まとめ & 反省点

Horos はソースコードからコンパイルできる。

日本語化もできる。→ もともと日本語化されています。

Xcode のクセがいまいちつかめていない。

 

High Sierra でコンパイルするときの問題点

おそらくそのままではエラーが出てビルドできない。

同包されているライブラリのいくつかが32ビットコンパイルだからだ。

まずはXMLパーサーの Apache Xerces (アパッチ・ザーシーズ)から手をつける。

 

→長くなりそうなので稿を改めます

 

Horos 再び

旧バージョンとしてすっかり放置されていた当ブログであるが、アクセス解析みたらそれなりに来訪者がいるようだ。

なかでも、「ん?」と思ったのが、「horos 日本語化」あたりで訪れてくれる人が多いこと。

ホロス(horos)コミュニティになんかあったのか?とHPのぞきにいったら、けっこう変わってましたね。

なかでも驚いたのは、Horos Academy なるトレーニングコースが設置されたこと。

ホロス、学帽かぶってるよ…。

あと、ユーザー同士の Q&A のコーナーがごっそりなくなっていた。私もけっこう初歩的な質問には答えていたんだけどなあ。慣れない英語で。

全体的に教育・サポートで収益化をはかりたいという方針が前面に出てきたようだ。

how to install みたいな記事も上記アカデミー内にうつされたようで、これだと、初心者にはソースからコンパイルして Mac にインストールすることも難しいだろう。

 

なんだろう。この軽く裏切られた感…。

 

ちょっとインストールトライしてみるか。連休だし。

 

(追記1)…おおっぴらに書いていいかどうかわかりませんが、ダウンロードページは、こちらのようですね。

(追記2)…依然のように Xcode で一発!というわけにはいかないようですね。CMake が導入されてました。

(追記3)…参考までに OsiriX に関して調べましたが、愕然。商用版の OsiriX MD とデモ版の OsiriX lite があって、MD の方は $699 。これはちょっと高くなりすぎのような…。

(追記4)…日本語化したものでもこれはかなり注意が必要。

 

レンタルサーバから遠く離れて

このブログを含め各種コンテンツは某社のレンタルサーバ上で動いているのだが、

・PHP7 系列は当分使えそうもないこと

・Java は今後とも動かないこと

が、確定的になり乗り換えを検討することになった。安価で容量もたっぷりあって今まで重宝していたのだが、機能の進化が止まった以上、そうせざるを得ない。まー、またどこかのレンタルサーバで、と思っていたのだが、AWS (Amzon Web Service) も使えるのでは、という話も出てきた。

ネットではこんな情報もあるし。

本当にいけるのかな?

 

DICOM Viewer に segmentation 機能追加検討

CT 値(ハウンスフィールド値)が求まると面白いことができるようになる。

その一つは、画像上である程度まで組織を分離(segmentation という)できるようになることだ。

例えば、前回の画像で

CT 値 組織
-109 ~ -10 皮下組織
-9 ~ 24 表皮組織
25 ~ 229 筋組織
230 ~ 骨組織

と閾値処理すると↓のような感じになる。

大雑把にはいい線はいっているのだが、細かいところではダメダメである。

骨組織は文句なし、筋組織はまずまずといったところだが、致命的にダメなのは神経組織がまったく分離できないこと。

これは神経組織のCT値が 30~40 であり、筋組織と値が被ってしまうことによる。

かなり以前に行きがかり上この課題に取り組んだことがあるが、そのときはアルゴリズムを工夫することで、半自動的にセグメントできるようになった。

最近の研究結果はどんなもんだろうかと先ほどざっと調べたが、あまり決定的な仕事はなされていないようだ。

やはりあったかと思ったのは、deep learning の手法を用いて云々というもの。流行りなので手を出したい気持ちはわかるのだが、今ひとつピンとこない。この課題の延長線上には、当然、「計算機による画像診断」というかなり重要なテーマが控えているのだが、その際には、どうしても「診断根拠」というものが必要になってくる。現時点での deep learning 的手法は、判断の根拠といった部分の機構が上手く説明できていないような気がする。

もちろん、探索的に用いるのなら有効だろうが。(確か Alpha Go も新手の生成のときにしか deep learning を使っていないはずだ)

ともあれ、目的も成果もわかりやすいこの分野、みなさんもトライしてみてはいかがでしょう?

なお、Orthanc のメーリングリストでもこの話題が出たので、興味がある方はご一読を

 

air-h-128k-il

C# で簡易 DICOM Viewer

いさんで DCMTK をコンパイルしたものの、 C# からは、当然、直接は使えない。

何か適当なツールがあるだろうくらいに考えていたのだが、ありそうでいて意外にない。GDCM というライブラリを使う手もあるらしいが、これはこれで一手間かかる。

やや困る。

面倒なのでライブラリなしで直接ダイコムファイルを読み込んで解析。(結局、こうなる‥‥)

それっぽくは書き出せたが、確かジーメンスは CT値に何か下駄をはかせていたはずで、コントラストがおかしい。

(追加)‥「下駄をはかす」というのは Rescale Intercept というらしい。(DICOM上の)データセットが必ずしも CT 値とは限らないため、

CT 値 = (生データの値) * Rescale Slope + Rescale Intercept

で、変換する。Tag は (0x28,0x1052)。この式に基づいて変換すると

と撮像・記録したときのコントラストで画像が再現できる。

よくわからなかったのは、Window Center & Width に値が二つ設定されていた点。40/700 と 200/3200 とであった。まあ、(40, 200) の設定でよいのだろうが、これがジーメンス固有のものであるかはちょっとわからない。

air-h-128k-il

技術的中間搾取

以前に windows 環境下でかっこいい DICOM Viewer がないみたいなことを書いた。

では、Mac 環境下の OsiriX や Horos が、満足すべきものかというとそうでもない。機能の豊富さは認めるが、ちょっと凝ったことをしようとすると、ソースの改変が必要になってくる。が、これらのプロジェクトは、ソースの改変をするには、ドキュメンテーションが決定的に不足しているように思える。

ところが、これらのパッケージを支えている ITK や VTK といったライブラリは、とんでもないくらいにドキュメンテーションが充実している。使われている英語も平易だ。

なぜだろう?(笑)

これは、以前に電子カルテを取り扱ったときにも同様の感想を抱いた。Java 自体が C++ に比べれば習得しやすい言語だし、hibernate や jersy といったライブラリも開発元サイトにいくとドキュメントが充実していることがわかる。

上流にある技術のキモは真に新規性がありかつわかりやすいのだが、そこから派生していくにしたがってどんどんわかりにくくなっていく。

いつものことといってしまえばそれまでなのだろうが、高度経済成長期ならいざしらず 21 世紀のオープンソースプロジェクトでこんなことしててもしょうがないんじゃないの?とは思う。