カテゴリー: OsiriX

HoroXaust2018 問題というのがあるらしい。

http://www.osirix.jp/

で、提案されていた。現在は、ドメインを変更したようで、http://osirix.asia/ 。

要するにバージョンアップもせず古い一部の OsiriX を使っていると突如プログラムが起動しない or クラッシュする、ということらしい。

でも、問題の特定はできているようで
「問題が起きるのは32ビット版で、OSS V5.8ソースコードあたりまでを使用しているもの」であり「起動後に http://www.osirix-viewer.com を見に行きバージョンチェックを行い、リリースから 5 年経過しているものは、起動させない or クラッシュさせる」
ということらしい。

ご丁寧にも Horos や HorliX もその可能性があると言及されていたようだが、当方の見解としては、Horos はほぼ間違いなくこうはならない、HorliX は 100% こうなることはありえない、というもの。

確かに OsiriX lite/Horos/HorliX のソースコードは似たような部分も多いが、少なくとも HorliX はソースの 32 ビットに入っていく部分（32 ビットコード）は一切使ってない。
使っていたら（32 ビットコードが含まれていたら）、AppStore から配信させるためのアップルの審査（Apple Review という）は通らない。
Horos はつい最近までユニバーサルバイナリを使って、32 ビットコードを使っていたが、現在はかなり改善されている。

起動直後のサーバとの通信だが、そもそも HorliX はそんな動作はしていない。バージョンチェックなどして、いちいち最新版へのアップデートを促すのが面倒だったからだ。バージョンアップするかしないかはユーザーが自由に決めればいいことではないか。
Horos は起動直後、サーバと通信しているようだが、それは OsiriX 関係のサーバではなく、horosproject.org のサーバだ。
ソフトのバージョンアップを促すコードは実装されているが、クラッシュさせるようなコードは確認できなかった。

さらに MacAppStore 版の HorliX では、サンドボックス化がなされているため、指定以外のサーバと通信させることができない。サンドボックス化しないと AppleReview に通らないのだ。
指定するとしても、なんでわざわざ http://www.osirix-viewer.com （OsiriX のサーバ）にする必要があるんだろう。

OS X のサンドボックスは強力で、URL の指定をちょっと間違えただけでも、ソフトと通信できなくなる。HorliX のプラグインのインストールで不具合が出たのもこのせいだ（次期バージョンで修正予定）。

でも、これはソフト本体がクラッシュする程度だからよいけど、ロゼッタ（アントニー＝OsiriX の作者）が本当に呪いをかけるなら、データベース OsiriX Data を削除するくらいのことはできたはずだ。そしておそらくは、もっとひどいことも。
でも、彼はそうしなかった。
なんだかんだ言われる人ではあるけれど、医師としての良識はある人だと思う。

でも、これ、取り扱い業者、クレームの嵐だったでしょうね。収束したみたいですが。
→ 他の業者さんに聞いた話では、全然収束してないみたいですね。動物病院などにはけっこうな数が納入されているらしく、対応が間に合ってないとか。どう収拾つけるんでしょうかね。
→ これ、収束はつかないですよね。
しかし、いい加減、一部の人たちに不快感を引き起こす可能性のある「ホロコースト」という単語で喩えるのは最低限やめたほうがいいでしょうね。

以前に杉本医師の立ち位置がよくわからない、みたいなことを書いたのだが、やはり「ユーザー」という扱いのようだ。

でも、以前に「アンバサダー」みたいな紹介のされ方をしているのを見かけたことがあるので、まったく無関係ではないと思う。

少なくとも OsiriX MD 本体の開発には関わっていないということだと思う。

他方で、外国人「ユーザー」は、HorliX vs Horos vs OsiriX に関してかなりはっきりとした議論をしているのであった。

欧米の方々って本当にこういうの好きですよね (^^;)

正直いって Horos をフォークした直後などは、OsiriX MD ははるか彼方で、比較するのもおこがましいと思っていた。
製品比較が成り立つくらいには成長したんだなあという感慨ひとしお。
でも、やはり OsiriX MD は機能豊富ですね。メッシュ切るソフトと連携とはやるなあ。

でも HorliX も６４ビットアプリ、基本機能はけっこういいですよ、処理によっては OsiriX MD より速い（と言ってくれるユーザーさんもいる）とか。
とちょっと宣伝。

まあ、今後は方向性が違ってくると思うので（搭載機能が変わってくると思います）、ダイレクトな「比較」は成り立ちにくくなってくると思いますが。

OsiriX がクローズドな開発に移行し、組織的な収益化を始めたとき、それなりに批判の声が上がったし、今もその声は根強くあると思う。
私は、HorliX プロジェクトを始めたとき、これはそのうち考えなきゃいけない問題になるだろうなと思っていたが、まだ先のことだろうと思い、これまで放置してきた。だが、Horos プロジェクトの中の人から、「ソースコードを共有しないか？」みたいなことを言われ、考えざるをえない状況になってきた。まとまるかどうかわからないが、現時点での考えを述べたい。

まず、これはオープンソースの中でもかなり特殊ケースだ（だから、オープンソースで収益を上げるのは、是か否かというような抽象的な議論とはまったく違うと思う）。OsiriX は完全に実現したし、Horos もその意思を表明しているのだが、実用に役立つことを目標にしている。具体的には、FDA（日本では薬機法でしょうか） が定める医療機器としての認承を取り、大手を振って臨床現場で使われることを目標の一つとしている。
FDA の認承をとるのにいったいいくらかかるのか私などは考えたこともないが、Horos などは目標の 1/4 も達していないという話だ（donation というのは聞こえがいいが、やはり限界があるのだ）。確か 2〜300万ほどで、日本だったら、PMDA に相談しにいっただけで終わってしまうのではないだろうか。
また、何らかの仕方でランニングコスト程度の収益化の手はずを整えておかないと、開発自体が止まってしまう。
だから、収益化は、外野の意見がなんであろうとも現実的な観点から必須だと思う。

なお、この方針を強く批判している人の多くは、医療職でもなんでもないケースが多いことに最近気がついた。具体的には、大学の基礎系の先生とか医療系ジャーナリストといった人たちだ。臨床現場での使用は想定しなくていい、自分の環境で DICOM 画像が見れさえすればいい、といった立場の人たちだ。こういう人たちの意見は、尊重すべき点も多いとは思うが、やはり最終的な判断には入ってこないと思う。

例えば、彼らがよく批判する OsiriX の高額化だが、技術者目線で見ると高額化した分、OsiriX (MD) の機能は増している。具体的には、読み込める DICOM ファイルの種類が増えたり（特に US 関係がほぼ例外なく読み込めるようになったのは臨床の先生からは歓迎されたのではないかと思う）、ネットワーク機能が強化されたり、といったことだ。

よく、@rossetantony のことを「汚れた」などと批難する人がいるが、「臨床供用のため開発コストがかかっていることを知っているにも関わらず、いつまでも無料で OsiriX を使い続けたいというあなたのその根性の方が汚れていないか？」と言いたくなることが私なんかはある。（ OsiriX MD の開発スタイルがライセンスを守れているかどうかはまた別の問題）。

また、OsiriX の方針転換は、医療機関経営者からは歓迎されたのではないかと推測する。無印 OsiriX を自己責任で使うよりは（というか単独で使うのは何かと問題がありそう。システムの一部として使うのはたぶんOK）、少々対価を払ってもいいからFDA お墨付きの MD を使う方が安心なのだ。

そこで HorliX なんだが、んーーーーー。

よくわからん。

（追記）よくわからないみたいなことを言ってましたが、とりあえず、Apple の Mac AppStore より、商用版をリリースしました（2018/8/8）。

これで、継続的に開発できる資金が確保できるといいんですが。

! 現在は直接配信に切り替えています。

（追記２）AI の進化によって状況は変わってきた。2026 年現在、AI エージェントの助けを借りたコーディングスタイルが主流になってきている。

ROI あたりから、Horos や OsiriX のコードを真面目に読み始めたのだけれど、意外に読みやすい。

読み始める前は、「ハイソな Mac のことだから、Horos/OsiriX のソースコードも、モダンで、レアなデザインパターン使いまくった難解なコーディングしてるんじゃないの？」と思っていたが、そうでもない。どちらかといえば、素朴な組み方していると思う。これはよく考えれば当たり前で、元々の作者のロゼッタさんは放射線科の医師。C/C++ 系のガチ職業プログラマのような「誰がこのロジック追えるんだ？」というような書き方はしなかった（できなかった）からだと思われる。

あと、読んでいて気がついたのは、Horos プロジェクトがつけたコメントがけっこう間違っているように思う。信用してどハマりしたことがあったので、気がついた。もちろん、全部、間違えているわけではないし、有益なコメントも多く有り難いのだが、「ここ間違えちゃいかんだろう」というところで、いい加減なコメントつけて逃げちゃっている感じ。感覚的な言い方をすると。
（この手の「手抜き」が不具合に繋がったと思われる例が『Horos の不具合』という記事で紹介されています。興味ある方は一読を。VTK の不適切な設定をこの後で書きます）

作業していて嫌なのは、やはり、Objective-C のクセ。

例えば、クラスからインスタンスを生成する際には

Person *person = [[Pserson alloc] init];

などという書き方をする。（追記 この記事が猛烈にわかりやすいので、おすすめです）

全然、慣れない（笑）。

Objective-C 特有の仕様で読みにくくなっているところなどを具体的に挙げていこう。

カテゴリ

#import "BrowserController.h"

@class DataNodeIdentifier, DicomDatabase;

@interface BrowserController (Sources)

-(void)awakeSources;
-(void)deallocSources;

-(void)redrawSources;

-(DataNodeIdentifier*)sourceIdentifierAtRow:(int)row;
-(int)rowForDatabase:(DicomDatabase*)database;
-(DataNodeIdentifier*)sourceIdentifierForDatabase:(DicomDatabase*)database;
-(void)selectCurrentDatabaseSource;

-(int)findDBPath:(NSString*)path dbFolder:(NSString*)DBFolderLocation __deprecated;
-(void)removePathFromSources:(NSString*) path;
@end
BrowserController+Sources.h

ファイル名が BrowserController+Sources.h になっている時点でほとんどの人が読むのをイヤになるんではなかろうか。
これはカテゴリというもので、BrowserController というクラスが別にあってこのファイルでそのクラスの拡張を図ってます。

Horos の 3D Viewer 、特にボリュームレンダリングに関しては、元のソースコード自体がかなり問題のある構成になっていて（実際、ここでよく不具合が出る）、少々手直した程度では、解決しないと思い、ほぼ同機能のアプリを PHORLIX Lite としてリリースしています。

たぶん、ソースコードにあたった人でないとわからないと思いますが、以下のような指摘があります。

実際のソースコードは以下の通り。

NSAttributedString *label = [[NSAttributedString alloc] initWithString:[NSString stringWithFormat:NSLocalizedString(@"value : %.0f\nalpha : %1.3f", @"don't translate the 'backslash n' before 'alpha', it is a new line symbol!"), pt.x, pt.y*pt.y] attributes:attrsDictionary];//original

CLUT の各ポイントの y 座標は、pt.y で表示されますが、Label での表記は pt.y * pt.y となっています。
アルファブレンディングの性質からいって、すごく間違っているということはないんですが、使っていてあまり気持ちのいいものではありません。

PHORLIX Lite では色加算はシンプルに

outColor = {color.x * color.x, color.y * color.y, color.z * color.z}  +
　{(1-color.x) * outColor.x,(1-color.y) * outColor.y, (1-color.z) * outColor.z};

で処理しています。
これでも、以下のような画像が得られています。

思うに、OsiriX チームが初めてボリュームレンダリングに挑戦したとき、これを実用レベルで実装していたのが VTK しかなかったので、少々無理があっても VTK を利用したというのが真相ではないでしょうか。

上で

もちろん、全部、間違えているわけではないし、有益なコメントも多く有り難いのだが、「ここ間違えちゃいかんだろう」というところで、いい加減なコメントつけて逃げちゃっている感じ。

 といっていたのは、具体的にはこういうことです。

さらに困るのは、「HorliX は Horos の分家みたいなものなのだから、Horos を非難するのはおかしい」という困った主張をする人が実際にいたことです。

レビューという意味での批判はしたことはありますが、単なる悪口のような「批難」をしたことはないつもりです。
ROI-color-rotation-UI などは HorliX 起源ですし、raw ファイルインポート機能も HorliX で復活させた機能です。
どちらも「本家」が実装していなかったし、その気配もなかったので、必要に迫られて独自に実装したというのが本当のところです。
なんでそれが「HorliX = Horos の日本語版」という解釈になるのかよくわかりませんし、不十分な機能を付加することがなんで「批難」にあたるのか意味がわかりません。（ちなみに最近言われているのは、こういった人たちは公式な技術文書を書いた経験がないので、評価すること=悪口を言っていると解釈しているのではないかという説です。確かに上の投稿をした人はアカデミックな業績は一つもありませんし、協力関係にあった業者も業績はほぼゼロです）

PHORLIX Lite に至っては、ほとんど完全にフルスクラッチです。
ある程度、実用的なアプリが作れるレベルの人ならば、元ネタがオープンソースであるかどうかは大して重要ではないと思います。
誰だって楽はしたいから、オープンソースプロジェクトで流用できるコードは探しますが、今回のように必要に迫られれば自作することになると思います。

一方、「オープンソースは本家が全て」というような宗教的な無茶な主張をした人たちは、Horos の日本語版をメンテするようなことをいってましたが、本家の開発がストップして以降、メンテもできていないようです。
オープンソースがなんでも叶えてくれる魔法の道具とでも思っていたのでしょうか？

おそらく業者かと思いますが、まるっきり信用できないような態度をとっていますね。