投稿日:

OsiriX Lite の現在

HorliX/Horos の ROI の UI を改変するため、数年ぶりに本家 OsiriX を github から落としてきてソースからビルドした。

多少、引っかかったので、適宜ソースを修正。結果、問題なく Xcode 9.4 でもビルドできた。もちろん HighSierra で動く。

なお、参考にしようとしていた箇所はやはり MD とは動作が違っていたため、役に立たなかった。

OsiriX MD はオープンソースではなくなったというのは本当だったようだ。

ただ、意外なことに OsiriX には未だにオープンソース版が存在する。６月の初頭にちょっとしたプルリクエストがきており、rossetantony 自らがマージしていた。

要するに、これは、「OsiriX にはオープンソース版が存在する。現在も開発を続けています。OsiriX MD は、収益化のためにオープンソース版とは別物になりました。もはやオープンソースでもなんでもありません」ということなのだと思う。

これはこれで良いのではないかと思う。

 

と先ほどは書きましたが、若干、考え方を変えました。

というのは、ついさっきなんですが、@rossetantony が、私のプルリクエストを断ったから。プルリクの内容は、ある程度日本語化された xib ファイル（cocoa で実際の UI を決めているファイル）一式と彼のプロジェクトを HighSierra + Xcode 9.4 でビルドするための若干の微調整。なお、プルリク時にコンフリクトおこしてますが、それは、その前のマージが意味不明なもので私が無視したから。

こちらとしては、「OsiriX のオープンソース版の開発を続けるなら、支持しますよ」というちょっとした好意の表明だったんですが…。

こういうことをすると「rossetantony という人物は、オープンソース版を最新の環境ではビルドさせたくないし、日本語環境も提供したくない。オープンソースという言葉を使いたいがためにビルド不能なソースコードを github に上げている」という風に悪くとっちゃう人も出てくると思うので、あまり良い対応ではないような気がします。

と思ってたら、スレを再び open にして結局マージ。謎だ。

 

彼の真意はよくわかりませんが、そのときの私のソースは、

air-h-128k-il/osirix

に上げてあります。たぶん、こちらは何の修正もなしにビルドできるかと。また、ビルドしたプロダクツは

こちらのダウンロードページ

からどうぞ。Ver 5.8 〜 6.0 相当ですが。

あと、他の SNS 経由で「なぜ、OsiriX は、クローズドな開発を宣言したのに、わかりにくい形でソースを公開しているのか？」という質問があったので、書いておくと、おそらく OsiriX が使っているライブラリの使用条項によるものだと思われます。
OsiriX は、dcmtk, ITK, VTK,…. といった有名どころのライブラリを使用していますが、その多くが正真正銘のオープンソースです。私も、全部のライブラリのライセンスを把握しているわけではありませんが、例えば、VTK （オブジェクトを表示させるためのそれはそれは重要なライブラリ。ただ、設計のクセが強く HorliX ではちょっと手を入れて使ってます）のライセンスは、いゆる 3-clause BSD license です。このライセンスは、VTK を同包したソフトをクローズドにしてもかまわないというけっこうユルいライセンスですが、それでも、同包した場合には、このライセンスを引き継いでいるということを表示しなくてはいけない、というシバリがあります。

一般的にいって、GPL 系は、ソース公開に関する条件が厳しいため、それに従って公開しているものと思われます。

また、一部で rossetantony や pixmeo（OsiriX の現在の開発元）の評判が悪いのは、この手のシバリを彼らが無視しているためです。

なおソースコードにあたると、コードを提供したプログラマは数多いです。一部に、そういった人々の著作権表記も (L)GPL 的にはなされなければならないという解釈をしている人がいたりします。ライセンス的な妥当性はひとまずおくにしても、現実問題、無理でしょう。人数が多すぎます。ソースコード上でのサインがなされていて、ソースコード自体が第三者にも見える形で公開されていればOKと考えるというのが適当かと思います。

 

⭐️ なお、現在では、OsiriX Lite もオープンソース版とは関係なくなったようだ。聞くところによると OsiriX MD の機能制限版だとか。32bit のアプリ配布しても Catalina 以降は起動することすらできないから、それはそうか。
でも、もうオープンソースでもなんでもないですね。

⭐️ 最後の著作権表記云々のところは『「開いたイルカ」再び』の「慣例的な著作権表記」に実例をあげながらわかりやすい解説があります。参考にしてください。

⭐️ なお、文中で出てきた Horos というのはまだオープンソースだった頃の OsiriX を Fork したプロジェクトです。
詳しくは『Horos wiki 風解説』あたりをご覧ください。

HorliX 開発チーム

 

投稿日:

OsiriX 系のデータベース構造

HorliX, Horos, や Miele-LXIV などの OsiriX オープンソース版派生アプリ、いわゆる OsiriX 系は、データベースとして  SQLite を採用している。

データベース実体は、デフォルトでは、ホームディレクトリ/書類 の **** Data である。SQLite はあまり使ったことがないので、物色。

3DSTATE…たぶん、3D 画像を編集した時の状態を保存しておくためのフォルダ。

Database.momd…おそらく、データのモデルが記述してある。たぶん、これがキモ。→ momd は coreData を使ってモデルからデータベースを作成する際に自動生成されるファイル。機能的にはキモかもしれないが、コーディング上ではそれほど気にする必要はない。

Database.noindex…ダイコムファイルそのもの。特にバイナリにはせず、ファイルをぽんと置いた形になっているわけですね。

Database.sql…テキストファイルと思いきや、そのまま開くと意味不明文字列。うーーん。→ 完全に引っかかりました。これが、sqlite のデータベースファイルそのものでしたね。しかし、通常 .sql ファイルというのは、テキスト形式でデータベースのスキーマなどを記述しておくものですが。。。

INCOMING.noindex…普段は空。たぶん、一時ファイル置き場。

この程度の理解では改良はおぼつかない。これは、もうちょっと真面目に勉強する必要がある。

というわけで、ここらへんは、このあと、もうちょっと勉強した。

coreData という ORM が使われてました。そのため、ぱっと見、わかりにくくなっていたわけです。例えば、Z_PK などは coreData が管理しているカラムで、改変時にはそれほど意識しなくてもいいものです。
ここら辺のデータベース周りの知見は、『inside HorliX/Horos』にまとめてありますので、ご興味のある人は一読を。

なお、PHORLIX では、coreData は使っていません。
OsiriX 系に限らず、AI エージェントは ORM を避ける傾向があるためこういう構成になる場合が多いようです。

 

投稿日:

ROI

ROI という言葉がある。Region Of Interest のことで、文字通り関心領域と訳される。

医療画像を見たとき、慣れた医師であれば、どの部分に注目して何を計測すればいいかわかっているが、DICOM Viewer はたとえ OsiriX MD といえども自動でこの作業をおこなってくれるということはない。したがって、操作者が「関心」領域をコンピュータに教えなければならない。

例えば、心胸郭比を求める場合は、以下のような操作になる。

まず、計測したい画像を立ち上げる。次にメニューバーよりアイコンの機能を変化させるボタンを押下。心胸郭比の場合は、関心領域は直線になるので、Length を選ぶ。

開始点でクリック、ドラッグして、終了点で再度クリック。

するとその直線の撮像時の実空間での距離が計測できる。

心胸郭比は、12.500/29.455 x 100 = 42.438 [％] ということになり、心肥大はないと判定できる。ちょっと直線の引き方が甘いのは大目に見てほしい。

 

と、なんでこんなチュートリアル的な内容を柄にもなく書いたかといえば、この分野で早速リクエストがきたから。海外の方の要望は、ド直球という感じですね。

確かに、関心領域が近接した場合、表示が見にくい。

なので改変。

 

 

英語版では、omrd さんの要望に沿って不要なレーベルを全て削ぎ落とす。日本語版は、漢字の視認性は捨てがたいと思い、残しておいた。

なお、これはぐりぐりのテストコードというやつで、狙った動作をさせるために変数管理などかなり無理をさせている。色の調整などを含め、リリース版に含めるためには、もうちょっと修正が必要。

（追記）なので、まず、色目の修正。

のデフォルトのグリーンから始まって、トパーズイエロー→キャロットオレンジ→マドンナブルー→…の順で描画する。

ただし、これは描画途中であって、いったん手を離して ROI を確定すると、最後に確定した ROI がデフォルトのグリーンで表示される。文字にするとわかりにくいですが、使ってみるとたぶんこの動作は一発でわかると思います。

また、色もいわゆる「洋色」メインにしました。

実装も「オブジェクト」・「クラス」を意識してコーディングし、かなりシンプルな形になったかと思います。

なるべく一般性を失わないようにと心がけたせいか面積系の ROI でも一発で狙ったように動きました。

キャロットオレンジ→トパーズイエロー→デフォルトグリーンの順に囲んでいったので、最後に書いた部分がデフォルトのグリーンで描画されているわけですね。

「海馬の体積が何パーセント減って…」などというとき役に立つかと。

（参考：『アルコール依存症患者では視床枕の体積減少がみられる』）

上記の改変の結果、今のところ ↓ のような操作性になっています。

（追記２）上記の機能は、ROI-color-rotation-UI という呼称が割と一般化したようです。

ソースコードを提供した Horos さんのリリースノートにも、この表現が使われています。
色がくるくる変わっていく感じが表現できていて、なかなかいいかと。

（追記３）などとけっこういいこと書いてますが、ROI の保管形式に関しては色々問題があります。この点に関しては『Horos なんちゃって日本語化』に詳しく解説してますので、一読ください。
簡単に言えば、Horos/HorliX の ROI の保存形式は、現在の DICOM 規格にあっていない、ということです。
PHORLIX では、この点を考慮して ROI-color-Rotation-UI を採用した上で DICOM SR で保存しています。だから、PHORLIX で作成した ROI は、他のアプリ、例えば weasis や 3D Slicer で読めます。
標準規格というのはかくありたい。

 

投稿日:

解剖ちゃんホーリックス

関係者の公開許諾が取れたのでちょっと書かせてもらうと、ホーリックス（HorliX）にはアイコンを変更したバージョンがいくつかあり、そのうちの一つは群馬大医学部解剖学教室向けである。

群大解剖学教室は、最近の大学らしく情報公開を意識したネット活動をおこなっており、HPはかなり凝っている。twitter 公式アカウント @Kaibo_chan にも絵師 @robops さんデザインの‏可愛いキャラアイコンが設定されている。

「解剖ちゃん」という。

私が、Horos に絡み始めたのもこのアカウントの中のひ…  いや解剖ちゃんがそそのかしたせいである。

確か「Horos 実習で使う予定なんだけど ”なんちゃって” じゃない正式な日本語化ってできないかしらね？」みたいな感じだったと思う。

その話はひとまず置くとして、解剖ちゃんは（自分たちが講義で使いたいという現実的な目的があるにせよ、それをなるべく安く使いたいという要望はあるにせよw）時にめげそうになる私を励ましてくれた。内輪でやった βテストにも参加してくれた。その感謝の意を込めて、記念に公式キャラをアイコン化したホーリックスを一台贈呈したのだった。

これである。

なんだろう、このメインビューとドックアイコンのミスマッチ感は（笑）？

これ以上ないというくらい機能主義的にデザインされた HorliX/Horos/OsiriX の UI に、萌え要素がちょっぴり入った解剖ちゃんアイコン。私も最初は正直「あれ？」と思っていたが、使っていくうちに愛着が出てきた。解剖ちゃんもアプリ起動時に「私が、私が跳ねているっ！」と喜んでくれた（と思う）。

実際に実習で使われるかどうかはまだ不明だが、もし使われるなら、将来医師になる学生さんたちの良い思い出になってくれればと思う。10 年後に「そういえば、解剖の時、変わった DICOM ビューア使ったよなあ。あれ、今もあるの？」などと思い出してもらえれば、開発者としては嬉しい限りだ。

最後にはなりますが、キャラデザインのブログ記事での使用・紹介、および Mac app へのアイコン化を対価なしに快諾していただいた @robops 氏に深く感謝いたします。

（追記）これはネガティブな批判になるので書こうか書くまいか迷ったが、結構の人が言うようになったので言わせてもらうと「2026 年の今にもなって Horos を推奨ビューアのように紹介している群馬大解剖学教室の教育方針は教育機関としておかしくないか？」という批判がある。

まず「Horos は新しい macOS でも使える」などと紹介している点。

もちろんこれは誤り。Tahoe あたりでも不具合は頻発していたし、Golden Gate に至ってはほとんどのほとんどのスタディでビューア自体が落ちる。
執筆時期が古いならこういう紹介もわからないでもないが、2026/4/13 に村上徹という人が更新しているにも関わらず、こういった記載を残しているのは明確な意思を持って推奨しているとしか思えず、ある意味悪質。

次に設計が現行の DICOM 規格に適合していないにも関わらず、そのことに一切触れない点。

2025年にもなって、不具合が日本語表示だけしか挙げられないのはいただけない。

詳しくはこの記事の「設計の陳腐化」あたりをご参照ください。
要するにアノテーションを画像に直接焼き付けるなど現代的な DICOM 規格から外れているビューアを（そのことに触れずに）取り上げるのは教育的ではないという批判です。