次世代型 HorliX

現行の HorliX を Mac AppStore からリリースしたのは、2018 年のことだから、かれこれ 5 年前のことになる。

売れ行きも評判も上々で気を良くしていたんだが、すぐに今も続く懸案事項が持ち上がる。

それは当時のアップルが打ち出した

OpenGL の廃止・Metal への移行

という方針だった。

HorliX に限らず、画像系のアプリはほとんど OpenGL に依存していたから、それなりの騒ぎになったことは覚えている。

幸い?すぐに廃止ということにはならなかったが(ちなみに、今でも OpenGL は使えている)、Metal が普及するにつれ、そのパフォーマンスの良さに「移行はやむなし」という雰囲気に変わってきたように思う。

私も、この方針が打ち出された直後、次期バージョンのことを思い浮かべた。

当初は、まずプラットフォームを Qt に移そうかと考えていた。
Qt はかなり早い段階から、Metal 対応を進めていたので、構想としては悪くなかったと思う。実際、試験的にプロトタイプも作成したりした。

ただ、どうしても本気になれなかったのは、HorliX を構成する膨大なライブラリ群もまとめて Qt で面倒をみなくてはならなくなることだった。

何か本質的でない気がした。

Metal への移行が思っていたより緩やかなことがわかってくると、アプリの Metal 対応は次第に考えなくなっていった。

ここ数年はそんな感じだった。

ところが、別件で画像処理関係で Metal を触ってみると、意外に扱いやすいことがわかってきて、HorliX 云々は別にしていくつか試験的なコードを書いてみた。

例えば、2D ビューア。

3D ビューア。

機能を豊富に盛っているわけではないが、最低限のラインはできているんじゃないかと思う。

当初は何かに使うという予定はなかったが、Metal による 2D や 3D 画像の取り扱いに慣れてくると、「これらを使って、次期 HorliX (PHORLIX と呼んでいる)できるのでは?」と思うようになった。

ここからの話は長くなりそうなので、いったん切ります。

 

DCMTK Ver 3.6.7

ちょっと前に twitter でも触れたのだが、DICOM 解析用のライブラリ DCMTK が Ver 3.6.7 にアップグレードされた。

このバージョンでは、ネイティブで arm Mac にも対応したので、早速、 M1 MacBookPro でビルド。

HorliX に組み込む

一部の機能を HorliX に搭載した。

ところで従来の HorliX のビルドシステムはお世辞にも洗練されているとはいえず、これを機会にかなり手を入れた。

ユニバーサルバイナリ(一つのバイナリファイルで Intel Mac と arm Mac で動作可能なファイルをこういう)まで一回のビルドでできれば申し分ないのだが、各種設定が面倒なため、当面は arm アーキテクチャにしぼって対応を進めていく予定だ。

(追記)やはり、ユニバーサルバイナリは、アーキテクチャ毎にビルドして、lipo コマンドで、それらを一つのファイルに落とし込む、というのが基本のよう。

デスクトップアプリ単体なら、一度に生成する、というのもなんとかなるかもしれないが、horlix のようにソースコードの大半がライブラリという場合は、やめておいた方がいいでしょう。

ライブラリとして使ってみる

知り合いの先生が、dcmtk を純粋にライブラリとして使ってみた例を提示している。(『DCMTK を Mac で使う』)

私も試してみたが、コマンドラインツールでは紹介されている方法でうまくいく。が、cocoa アプリでは(ビルド自体はできるが)実行させたときに、落ちるようだ。

最初、???だったのだが、どうやら、タグ解析時に使う dicom.dic がサンドボックスのせいで cocoa アプリから読み込めないのが原因のようだ。

解決方法は色々あると思うが、最も簡単なのはビルトインの辞書を使う方法だろう。

外部フォルダに置かれた辞書ではなくビルトインの辞書を使うためには CMake でライブラリを構築する際に ↓ のように

DCMTK_DEFAULT_DICT を builtin に設定する。

というわけで問題なく cocoa アプリから dcmtk が使えるようになった。
試しに実際のダイコムファイルから特定のタグ情報を抜いて、画像を表示させた。

コントラストがおかしいが、白黒反転すると正しくなりそう。

おそらく、US (Unsigned Short) の値を特に工夫せずにそのまま使うとこのようになる。

臨床的にはかなりまずいのだが、dcmtk 自体はうまく動いていると考えてよいのでまずは一安心。

クラスの階層構造

ところで、dcmtk は(多くのオブジェクト指向で書かれたライブラリがそうであるように)各クラスは階層構造を取っている。

上のサンプルでは、タグ情報を抜いてくるのに DcmDataset というクラスのメソッドを使ったが、このクラスの階層は以下の通り。

DcmDirectoryRecord は使ったことがないなあ。

まずは、興味の持てそうなクラスの主要なメソッドを試しに使ってみると次第に使い「慣れ」ていくようになると思う。

動画系は扱えるか

ここまで書いたついでで、動画系 dicom の話題。

dicom の転送構文(transfer syntax などという。訳語がいまいちピンとこないが)には、mpeg などの動画フォーマットも定義されている。

当然、dcmtk でもこれらのフォーマットが扱えないかが気になるところ。

海外でも同様の疑問は上がっているようだ。

現状だと「扱えなくはないが、安定性に欠ける」といったところでしょうか。

 

(続く)

OpenDolphin Ver 6

ちょっと手が空いたので、OpenDolphin-2.7m を JakartaEE 9.1, java17 環境に移行した。

軽くまとめ。

主な変更点

主な変更点は二つ。

・画像の取り扱いの変更

・ウェブレイヤーの追加

まず、画像に関して。

これまで、画像の取り扱いが jpeg に限定されていたのだが、この制約を取り払った。

ただし、従来のデータベースとの互換性を保つため、jpegByte あたりのコードには直接変更を加えず、新規に画像保管用のカラムを加えた。

これまで、データ構造は LSC 時代の 2.7 と全く同一にしていたのだが、この変更でこの原則は崩れた。

ただし、API にはある種の追加はしたが、これまでのものを削除することはしなかったので、以前のバージョンのデスクトップアプリを使えば、使用感は変わらないと思う。

一種の上位互換。

API の追加は、まだ進行中。煮詰まってない。

画像のフォーマットは山ほどある。どこまでサポートするかは現時点では決められない。

次に、ウェブレイヤーの追加に関して。

以前から、「クライアントは Java デスクトップアプリである必要はない」ということは言われていたのだが、ではどう構成するのか?という具体的な議論はなかった。

個人的には、3層クラサバ化がいいのではないかと思っていたので、今回、OpenDolphin HTML・PDF Viewer をウェブサーバー化して、フロントエンドサーバーとした。

諸々の機能は実装中。

サーバーサイド

フロントエンドサーバーを加えたので、単に「サーバー」と言った場合、従来のサーバーと混同してしまう。

そこで、従来のサーバーを BackendServer と名称変更した。

クライアントサイド

前述のように、クライアントは従来のデスクトップアプリと新規に作成したフロントエンドサーバー(ブラウザタイプ)に別れた。

デスクトップアプリ

今回のアップデートが最後でしょうか。

フロントエンドサーバー(ブラウザ)

以前に dolphorca と呼んでいたものがこれにあたる。

名称

これまでにも、ノーマル 2.7-m ベースのいくつかのカスタマイズバージョンがあった。

例えば、以前に書いたように(『聴診音クラファンからの・・・OpenDolphin』など参照)、研究支援用のプロトタイプバージョンなど。

ところで OpenDolphin のアプリケーションサーバーといえば、WildFly がデフォルトである。
が、若干修正することで GlassFish でもデプロイ程度はできる(正常動作はしないが)。
こういったバージョンも存在した。

このように非公開のいくつかのバージョンがあって、バージョン番号はいささか混乱していた。

そういった経緯で今回移行したプロジェクト群を総称して(数字的には 2.7 から一気に飛ぶが) Ver 6 とした。