投稿日:

次世代型 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 でもこれらのフォーマットが扱えないかが気になるところ。

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

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

 

（続く）

投稿日:

PHORLIX について

現時点（2021 年末）で phorlix なる単語をググると以下のような結果になる。

要するにこの単語はGoogleに認識されておらず、代わりにミュージシャンと思われる Phoelix さんの情報がずらずらと表示される。

それはそうだ。
PHORLIX というのは我々がちょっと前にでっち上げた単語だ。
ある意味、カブッてなくてよかったと思う。（他で使われていないか確認するためにググったというのが本当のところ）

PHORLIX は元々は p-HorliX であった。

こう言っても意味不明か。。。

HorliX というのは、我々が開発している医療画像向けのビューアーソフトの名称で、リリースしてからかれこれ３年になる。

興味のある方は公式サイトを覗いてほしい。

HorliX は MacOS 上で動くのだが、この３年の間に MacOS の開発環境は激変した（主に Arm アーキテクチャの採用と OpenGL → Metal への移行）。だから「次に手を入れるなら、これまでの設計とは別系統のラインにしなくてはいけないだろう」という漠然とした思いを関係者は抱いていた。
これをなんとなく p-HorliX と呼んでいた。
たぶん p-HorliX の p は、post とか phazor という意味合いだったのだろう。

本当に「いつの間にか」そう命名され「なんとなく」そう呼ばれていたのだ。

そうはいっても、諸々の問題（開発するかどうか、するとしたらどういった開発体制を敷くのか等等）をいつまでもダラダラと先延ばしにするわけにもいかず、情報整理用にサイトがあった方がいいということになり、この度、サイトを開設したという次第だ。

また、ドメイン名は p-horlix にしたが、これだとどう発音していいかわかりにくい。幸い、英語では頭が ph という綴りになる単語が多い。
physics, physiology, philosophy…

繋げても違和感がないなら繋げてしまえとばかりに、ブログ名称は思い切って PHORLIX とした。
だから、PHORLIX を無理矢理発音するならば「フォーリックス」あたりになるだろうか。

 

猪股弘明（中の人を代表して）

（追記）google のクローラーはやはり優秀。
年が明けた 2022 元日には、しっかりインデックスされてました。