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 とした。