Inside HorliX/Horos

horlix や horos のプログラム的な特徴。

OverView

全体的なまとめ。

データベースの構造

通常の DICOM 関係ソフトとは若干異なり

Alubum - Study - Series - Image(s)

となっている。

HorliX/Horos/OsiriX のデータベースの構造

Study - Seriese - Image は、DicomStudy - DicomSeries - DicomImage というクラスに対応している。ファイルの各種データ（Patient ID, Modality …）は、ORM である CoreData を介して sqlite ファイル (Database.sql) に永続化されている。
ただし、実際、データベースとのやり取り細かく指定しているのは、DicomData クラスである。

『HorliX/Horos/OsiriX のデータベースの構造』なども参照。

2Dビューア

NSOpenGLView 由来の DCMView クラスで２次元画像データを描画させている（実際の動作は、各種 ViewerContoroller が管理）。
したがって、グラフィックエンジンが OpenGL から Metal に完全に移行した場合は、全く使えなくなる。
対応策としては、これまで DCMView を引き渡していたところを Metal 由来のビューに変えればいい。
Metal に関しては、関連ライブラリの整備やノウハウの蓄積などが進み、発表当初に比べ、かなり使いやすくはなってきている。

理屈の上ではビューの置換は可能だが、改修コストを考えると Metal 使用を前提としたアプリを新規に起こした方が楽かもしれない。

3Dビューア

Volume Rendering を行なう VRView, Surface Rendering を行なう SRView などがある。
VRView で使われるビューは DCMView ではなく、ライブラリである VTK から提供されるビューである。
この時の手続きは若干複雑であり、そのためかしばしば不具合（対象が視野から見切れるなど）の原因となる。
VTK から提供されてはいるが、元々は MacOS の OpenGL で生成されたもので、これも OpenGL -> Metal の移行が起こると使えなくなる。

対応策は 2Dビューアの時と同様。

補足

データベース関係

OverView でも触れたが、dicom 関連を扱うソフトは大抵の場合、
　Patient-Study-Series-Image(s)
という階層構造を持っている。
HorliX/Horos/OsiriX(Open Source version)の場合、PACS というよりはビューアとして供される場合が多いので、UI を反映してか
　Album-Study-Series-Image(s)
になっている。
このうちデータベース上の Image テーブルに対応しているのが、DicomImage クラスだ。
しかし、HorliX のライブラリとして使われている DCMTK にも DicomImage という同名のクラスがある。
通常の C++ プロジェクトであれば、名前空間を用いることで両者の区別はつく。しかし、HorliX/Horos の開発言語である Objective-C には名前空間の概念はない。
今後のことを考えるとクラス名の衝突を避けるためにアプリの側の DicomImage クラスをリネームした方がいいと考えた。
少々迷ったが、HorliX では DicomImage → PHDicomImage とリネームした。