PaxViewer v1.0.4
PaxViewer v1.0.4 の主な変更点は
・VolumeRendering における crop ツールの実装
・C-STORE のサポート
の2つ。
crop ツール

OsiriX/Horos/HorliX ではお馴染みのこの機能。
簡単なものだが、実装した。
今でも激重なので cropping cube を表示させて・・・というのはしばらくやらないつもり。
C-STORE サポート
実務的な問題で通信でスタディのやり取りをサポートする必要があり、まずは C-STORE を実装した。

上の図は Orthanc から PaxViewer にスタディを送信したときのもの。
コントロールパネルで AE title と待受ポートは指定できるので、適当な値をふってください。
PaxViewer v1.0.3
v1.0.3 の変更点は以下の通り。
・タグ解析機能の追加
・サムネイル表示の採用
タグ解析機能の追加
タグ表示は欲しかったのだが、どういう UI にすればいいか構想がなかった。
とりあえずは、スタディの最初の解析対象になったインスタンスのタグを一覧表示させればよかろうと、そういう動作にした。
今のところ PatientID と PatientName だけは編集可能にしている。

運用にもよると思うのだが、他施設のスタディを取り込むなら、この二つだけはないと困ると思ったからだ。
サムネイル表示の採用
Orthanc Explorer などは設計の際に参考にしたが、OsiriX のようなサムネイル表示がないのは個人レベルでの使用ではきつい。
今回、それっぽく作ってみた。
その他
アイコンを新調した。
PaxViewer v1.0.2
v1.0.2 の変更点。
・英語表示
・スタディ削除機能
・3DVR の操作性向上
など。この投稿も参照。
英語表示
ここでの評判がいいような気がするので慌てて英語表示を入れた。
今は index-en.html は使わないようだ・・・。
スタディ削除機能
ゴミ箱アイコンをスタディウィンドウの各行右に新設した。
物理削除なので注意! ファイルごと捨てます
ちなみにそれまでは登録はできるが削除はできない仕様だった。
3DVR の操作性向上
VolumeRendering でオブジェクトを回転させる際、水平方向はマウスの進行方向といっしょだったのだが、垂直方向がマウスの動きと逆になっていた。
修正した。
その他
隠し機能として特定 ID でのスタディ集約ページも作成した。他のソフトと ID 連携する時に便利。

上図は、OceanMini と ID 連携させている。
PaxViewer v1.0.1
HorliX の後継として PHORLIX はリリースしたのだが、まるっきり別件で PACS/DICOM 関係をいじる必要があり、その派生でブラウザベースの簡易 PACS/DICOM Viewer を作成した。
PaxViewer という。
おかげさまでリリース初日で 30 download された。
ほとんどフルスクラッチで書いたのだが、OSS ももちろん使っている。v1.0.0 ではそのライセンス表記が不十分に感じたので、v1.0.1 では licenses.html を作成して著作権表示やライセンス文書をそこに全てまとめた。

HorliX on MacOS Sonoma
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 のプロジェクトとみた場合、書き方が古く、ところどころに迂遠なところが散見される
といった問題点があります。
βテスト
かなり気が早いのだが、βテストも開始した。


