PHORLIX -003-

実用的かと言われると、ちょっと疑問なのだが、とりあえずアプリとしての体はなしてきたので、PHORLIX のベータ版を差し替え。

外見上は、Volume Rendering 機能や About… ページ、2Dビューアのスライダーなどが追加されたことに気がつくと思うが、内部ロジック的にもあちこちに手を入れている。

 

HorliX はダイコムシリーズをどう扱っているか?

HorliX がダイコムシリーズをどう取り扱っているかわからないところがあったので、実験的なスタディを取り込ませる。

本来であれば 361 枚からなるスタディの上(頭側)から20枚をチョイスした擬似的なスタディを作成。

しっかり取り込んでくれて、ボリュームレンダもできる。

ダイコムの規約的にも予想はしていたんだが、あるシリーズは自分が何枚の画像からなるか「知らない」。
知らなくても利用には問題ないし、後から画像を追加できる利点がある。

というわけで、このスタディにさらに尾側10枚ほどを追加。

アラートは出現するが、

描画自体はできる。

だが、このボリュームレンダはイマイチ。

位置情報を使わずに Instance Number の順にテクスチャを生成しているようで、見事に中間が省略されている。

昔の OpenGL はどうか知らないが、Metal だと3次元的にテクスチャを生成できるので、ないところは適当なオブジェクトで埋めた方が多分いい。

この知見を PHORLIX にも反映。

スタディ・シリーズに関しては、それぞれ StudyInstanceUID ・SeriesInstanceUID が識別子になるようにデータベースの構造を変更。

細かいことを言えば、StudyInstnaceUID などが必ずしもユニークな識別子であるとは限らないのだが、今回は目を瞑る。

スタディ・シリーズの仕様がはっきりしてきたので、ビューアにスライダーをつけて連続表示できるようにした。

 

 

PHORLIX -002-

GW の空き時間を使って、進めるところは進めてしまおうといくつか機能追加。

JPEG2000 & JPEG-LS 対応

JPEG2000, JPEG-LS で符号化されたデータも表示できるようにした。

ロジックのミス(データの受け渡しで根本的に考え違いしてた)で描画が極端に遅くなってしまったが、ここはそのうち大幅に手を入れる予定。(→ある程度、改良。まだ、改善の余地があるが、そこまで遅くはなくなった)

ちなみに、最初は、「あれ、JPEG2000 の展開アルゴリズムってこんなに時間かかるっけ?」とか「配列ばんばん使ったのでメモリーリークかな?」とピントが外れたことを考えていたが、デバッグ時の

が目に入ってきて、勘違いに気がついた。
(メモリーの消費はそれほどでもなく、CPU の稼働率が異常に高いのでこれはメモリーリークではない)

思い込みって怖いねー。

・ダイコムディレクトリ

・3次元描画

あたりが次の目標。

シリーズやスタディなど複数ファイルから構成されている場合

メモ。

シリーズやスタディなど複数ファイルから構成されている場合をどうするか?

規格的には DICOMDIR というのがあるのだが、最近は見かけない。

無視して、ファイル内容から類推して、データベースに格納するか。
シリーズなどに isVolumic などのプロパティを追加する必要がある。

(続く)

 

 

 

PHORLIX

以前から、諸々の理由で、「機会があったら、OsiriX とは別系統のビューアーを作成してみたい」と思っていたのだが、空いた時間を利用してコーディングしてたら、プロトタイプができてしまった。

機能的には、CR の画像が表示できる程度で、これ以外の機能はないに等しいのだが、基本設計的にはそれなりの水準にあるのではないかと思う。

諸々の理由とは書いたが、具体的には以下のような事情があったせいだ。
(先日、ML に流した内容を転載)

私が、OsiriX (直接には Horos ですが)のカスタマイズに着手したのは 2018 からです。
当初はあれだけ機能豊富なアプリのソースコードが公開されて、それほど手間要らずで
ビルド可能、微修正も容易、ということで圧倒されていました。

しかし、現在の視点からみると

・グラフィックのほとんどすべてが OpenGL に依存しており、MacOS が本格的に
Metal に移行した場合は、使えなくなる

・他人の書いたコードは、読むのが大変。修正入れる場合は、さらに労力が要る。

・Objective-C のプロジェクトとみた場合、書き方が古く、ところどころに迂遠なところが散見される

といった問題点があります。

βテスト

かなり気が早いのだが、βテストも開始した。

 

HorliX と dcm4chee-arc-light を繋ぐ

以前に HorliX と Orthanc を繋いだことがありますが、今回は Java 系の PACS サーバ dcm4chee-arc-light と繋いでみます。

web アプリ経由での通信(WADO-RS などという)もできるようなのですが、まずは、古典的なダイコム通信で。

準備

dcm4chee-arc-light は Ver5 系になって、LDAP が採用され、運用にこぎつけるだけでも大変だと思いますが、この辺は

dcm4chee-arc-light 5.29.2 のビルド

dcm4chee-arc-light 5.29.2 のデプロイ

あたりの記事をご参考に。

今回は、接続テストですから、あらかじめバイナリが配布されている Ver5.29.1 を Ubuntu にインストールしておきます。

HorliX 側の設定

まず、HorliX 側の設定ですが、環境設定 -> Location で dcm4chee の DICOM ノードを登録します。

デフォルトだと dcm4chee は AETitle = DCM4CHEE, Port = 11112 になっているようです。これを指定。
注意! IP アドレスが localhost になっていますが、ソースで確認したら bind IP address が 0.0.0.0 になっていたので、ここは変更する必要はないです。

すると UI 画面右の source に DCM4CHEE という項目が出現します。

dcm4chee-arc-light 側の設定

次に dcm4chee-arc-light 側の設定。

メニュー -> Configuration -> AE Title で HorliX を AE Title に追加します。

これで準備は完了。

HorliX から dcm4chee-arc-light に送信

いたってシンプルです。

送信したい study や series を DB 画面から、先ほど触れた source (DCM4CHEE) にドラッグ&ドロップするだけです。

送信が無事終わると、dcm4chee 側で画像の確認もできます。

dcm4chee-arc-light の画像保存場所

WildFly HOME -> satndalone -> data -> fs1 に実体があります。
画像が増えてきた場合は fs2, fs3… になると思われます。

その他

horos でも同様の手順で dcm4chee-arc-light とリンクして使うことができると思います。
通信周りは horos とそれほど変わっていないはずなので。

 

 

 

 

HorliX on MacOS Monterey

2021/10 月末に Mac の新しい OS Monterey がリリースされたようなので、アップデート。

前回の BigSur とは異なり、大型アップデートというよりはマイナーチェンジに留まるようだ。

HorliX の動作チェック。

目立った問題はなし。

BigSur で動作するならば、Monterey でも動くでしょう。

 

猪股弘明

 

HorliX リリース3周年記念 -世界を変えるのに3年もいらない-

HorliX が Apple AppStore で配信を開始したのが 2018/8/8 なので、今年(2021)の8/8でちょうど丸3年になる。

記念に何かしようと思って特設ページをつくってはいた。
当初は、3周年記念モデルなどを作ろうかと思っていたのだが、新型コロナやらなんやらでなかなか時間が取れず、その先に進めないでいた。

結局、内輪で欲しいと手を挙げてくれた人に現行の Ver1.0.7 (もちろん使用期限なし)を新規にビルドした。
先日、なんとか配布を完遂させた。
お世辞もあるだろうが、かなり喜んでいただいたようだ。

正直、かなりほっとした。

8月いっぱいくらいは、このキャンペーンを続けようと思っているので、第二弾もお楽しみに。