DCMTK を Mac で使う

なぜか次世代 HorliX (PHORLIX) の活動が活発化しているみたいで、私も乗り遅れまいと何かできることを探す。

隙間時間使って、ちょっとしたアウトプット出したいとなると、DICOM のタグ解析あたりか。

しっかりやるとなると大変だが、DICOM のタグ解析のライブラリとして有名な DCMTK を Mac でお試しに使ってみよう。

といっても最新 Ver 3.6.7 のライブラリ構築はできている。

意味あるかどうかはわからないが、コマンドラインツールを Xcode でビルドしてみる。

Xcode で Objective-C のコマンドラインツールのプロジェクトを生成して、バイナリツールのソース(今回は dcm2json にした)を持ってきて・・・とやる。

あっさり成功。

CMake ではできているので、当たり前か。

若干、迷うとしら、リンカオプションの与え方。

ライブラリ自体をビルドした時、私は WITH ZLIB を YES にしたので、zlib 自体のコードはライブラリやヘッダに含まれているはず。

最初、「だから、zlib 関係のオプションは要らんかな」と思っていたが、実際ビルドすると、zlib_version が undefined symbol(s) で見つからないとリンカに怒られてしまった。

dcmtk と zlib は(同包されているとはいえ)本来は、別ライブラリなので、それもそうか。

結局、-lz というオプションを与えて解決。

きれいにビルドできましたとさ。

しかし、libzlib とかって Mac のどこにあるんでしょうね?

時間あったら調べます。

補足:DCMTK ビルド時に zlib や iconv を使ったかどうかは人によって異なるし、しばらく経つと自分でも忘れると思うのでので、dcmtk のライブラリを使いたい時は

#ifdef WITH_ZLIB
#include <zlib.h>                       /* for zlibVersion() */
#endif
#ifdef DCMTK_ENABLE_CHARSET_CONVERSION
#include "dcmtk/ofstd/ofchrenc.h"       /* for OFCharacterEncoding */
#endif

をおまじないのように書いておくといいかもしれません。

参考:libzlib を見つけに行く時に、Xcode で使える環境変数を知っておくと便利。

Xcodeのスクリプトで使える環境変数(備忘録)

あたりを参考に。これは使ってないと忘れる。

なお、Xcode から、ビルドしたいコマンドラインツールに引数を与える方法はこの記事参照。

 

 

 

dcm4chee-arc-light 5.29.2 のデプロイ

前回の記事で、ビルドが完了したので、WildFly 26 へデプロイ。

公式の教えはここ

少々ダルいが、手順通りやっていくか・・・などと言ってましたが、これがとにかく長い。

ポイントのみにします。

Initialize Database

ここはそんなに面倒でもない。

今回は postgreSQL を使用。

pgAdmin が使えるなら、コマンドを叩くより速いので、そうした方がええかも。

ユーザー dcm4che さんを作成し、このユーザーをオーナーとするデータベース dcm4che を作成。

データベースのスキーマの一覧およびスクリプトは、(PostgreSQL に限らず)ここにある。

今回は、

create-psql.sql, create-fk-index.sql, create-case-insensitive-index.sql

が必要ですが、ソースコードの dcm4chee-arc-light -> src -> resources 以下にあります。

sourceforge からバイナリ落としてきた人は解凍すればわかるので説明は割愛。ソースコード落としてきた人は、上の位置にスクリプトはあるので、それを使いましょう。(どっちでやっても同一の内容です)

これも pgAdmin から操作した方が楽。

これで、テーブルが作成されます。

DICOM 仕様書で規定されている patient – study – series の構造がこのテーブル構成からも窺えます。

Setup LDAP Server

LDAP というのは、Lightweight Directory Access Protocol の略で、MS の Active Directory の上位概念みたいなやつです。

Mac では、他の Unix マシン同様、既に入ってます。
各種設定ファイルは、/etc/openldap を参照。

GitLab でソースが公開されていますが、GitHub にもそのミラーサイトがあります。(ちなみに C。もはや Java でもなんでもない…)

wiki の解説にもあるように、この考え方自体は興味深いんですが、いかんせん、後に出てくる諸々のプロジェクトがメンテされてなさすぎ。

ところで、OpenLDAP の設定をするのに

・slapd.conf にschma などをセットする

・dynamic runtime configuration を使う

の二通りの方法が書かれていますが、後者の方が簡単でしょう。

なのですが、後者を使う場合、ldap-utils が必要です。が、この MacOS バージョンはありません。とすると、前者の方法論を取るしかないと思うのですが、これがなかなか大変。検討中です。

Ubuntu にデプロイする場合は『Ubuntu 18.04にDcm4chee-arc-lightをインストールする』がまとまってますので、参考にするといいかと思います。

(前者の方法論は、後日、まとめる予定。以下はメモ的なもの)

OpenDJ のリポジトリ

Apache Directory のソースコード
org.apache.directory.checkstyle-configuration.version のバージョンを 2.0.1 に変更。

Setup WildFly

今回ビルドしたバージョンは 5.29.2 で、5.16.1 onwards (5.16.1 以降)なのでインストラクション通り進めれば OK な(はず)。

と思ってましたが、ここもそこそこ長い。

ポイントだけ書いておくと

・動かすだけでよければ、WildFly の細かなチューニングは後回しにして、まず module などを整備しましょう。

・5.29.2 では、WildFly の full バージョンではなく、web profile を使うので、standalone.xml を dcm4chee-arc.xml とリネームして、ここでポンポンポンと各種設定を行う。

のがいいんではないでしょうか。

一応、デプロイまでできると

フロントの ui を通じて各種操作を行うことができます。

 

dcm4chee-arc-light 5.29.2 のビルド

C++ 系の オープンソースの PACS は Orthanc が有名だが、Java 系では dcm4chee-arc-light が有名なようだ。

某先生も「arc-light は JakartaEE には対応していないので、手を出していないが、ライブラリの方はけっこう使えるようだ」と言っていた。

JavaEE 環境になってしまうがそこら辺は割り切って試してみますかね。

なお、ビルドはそれほど難しくありませんが、デプロイがとにかく手順がかかる。
よほどの事情がない限り、sourceforge で公開されているバイナリを使った方がいいでしょう。

ライブラリ dcm4che をビルド

dcm4che というのが dcm4chee-arc-light を構築するのに必要なライブラリ、arc-light は PACS サーバーそのもの、みたいです。

なので、先に dcm4che をビルド。

mvnw コマンドを使うらしいのですが、まずは maven をインストールしておきましょう。

git コマンドで

git clone git@github.com:dcm4che/dcm4che.git

として、dcm4che のソースをローカルマシンにもってくる。

リポジトリの教えにあるように

./mvnw install

としてビルドが始まりますが、mvnw コマンドは mvn の何かのラッパーのようでやや間があきます。

ビルドが始まってからは速い。

となれば、ビルドは成功。

dcm4chee-arc-light のビルド

これまでと同様にソースコードの準備。

git clone git@github.com:dcm4che/dcm4chee-arc-light.git

としてソースコードをローカルマシンに持ってくる。

ビルドにはオプションがあるので、お好みで。

とりあえず試すだけならセキュアな UI や API は要らないでしょうから、

mvn install -D db=psql

でいいと思います。

数分、かかりますが、ビルド成功。

dcm4chee-arc-light -> dcm4chee-arc-war -> target に war ファイルができているので、これをデプロイすればいいんでしょうか。

デプロイは面倒という記事が散見されるので、これは稿をあらためて。

 

JakartaEE と DolphORCA

おかげさまでネット上では『OpenDolphin -wikipedia 風解説-』がなぜか支持されているようだ。

元々は、ドルフィンのソースコードを眺めていた時に、(従来は)開発者認定されていない人の署名を見つけて、ちょっとびっくりしてそこらへんのことをまとめておいただけの記事だった。
が、その後も報告が断続的に集まり続け、その都度書き足していったら、現在の形態になったという経緯だ。

こういう斜めから入ったような記事でも、それなりに読まれたりするものなのですね。

意外な気もするが、納得できるところもある。

ところで、OpenDolphin の件で若い人から言われて印象に残っているのは、

現在の Java や JakartaEE の各仕様を使えば数行で処理できるところを、何でその十倍くらいのコードで(しかも)不自然に処理しているんですか?

という指摘だ。

正直、きっつ。。

まあ、一言で言えば、データ構造修正とコストとの兼ね合いの問題ですね(汗)。

データ構造の限界やその処理方法の古さは、われわれも認識はしていたが、ひとたび、データ構造に手を入れ始めると、それを内部的に処理している部分も変更せねばならず、そのコストが(修正した)利益に見合わないとみていた、というのが答えといえば答えになるでしょうか。

なんか、うまい説明になってないか。。。

ここら辺で興味深かったのは、某先生の判断と立ち回りだ。

ギリギリまで OpenDolphin 2.7 のデータ構造は維持し続け、変え時と見たら一気に変えてしまった。
(ここら辺の流れは、ここあたりから始まる一連のツィートを参照。)

この「変えて」しまったものが DolphORCA なんだが、設計の基本コンセプトからしてドルフィンとは大きく異なっている。

DolphORCA で採用された三層クラサバ構成に関しては『DolphORCA と三層クライアントサーバシステム』が良い案内になっている。

また、(直接、DolphORCA には触れられていないが)電子カルテ系と画像系のデータ構造の相性の悪さに関して

なぜ、全国統一カルテは無理筋なのか?
-カルテ系と画像系のデータ構造の本質的な相性の悪さ-
(EHR-DICOM data structure mismatch)』

という記事にかなりわかりやすく書かれている。
DolphORCA のデータ構造は、これらの考察を踏まえてかなりシンプルで使いやすいものになっている。
ここら辺の分野に興味のある方はぜひ一読をすすめる。