オープンソースと収益化

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)。

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

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

 

更新記録 2018/06/21

  • ROI のキャプションが日英混合表記になっていて、気になったので全て日本語で統一した。

やはり、文字が密集した中での漢字の視認性の良さは際立つ。

日本語環境の整備 + ROI カラーリングの工夫 など、独自性もでてきた。

一般公開・配布などの検討を進めてもいい時期かもしれない。

 

ソースを見てもらえれば、なんでこの構成にしたかはわかると思う。

#include "/usr/local/include/(ライブラリ)/*****.h"

などとビルドする環境のライブラリを直接呼び出している。例えば、画像関係が得意な人なら、自前の画像処理ライブラリを持っていて、そちらを使いたいというケースが多い。この場合、Horos に元から入っているライブラリは、邪魔になってしまう。その点を配慮した。

 

HorliX/Horos/OsiriX written in Objective-C

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 の日本語版をメンテするようなことをいってましたが、本家の開発がストップして以降、メンテもできていないようです。
オープンソースがなんでも叶えてくれる魔法の道具とでも思っていたのでしょうか?

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

 

OsiriX Lite の現在

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

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

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

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

ただ、意外なことに OsiriX には未だにオープンソース版が存在する。6月の初頭にちょっとしたプルリクエストがきており、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 開発チーム

 

データベース周り

HorliX/Horos/OsiriX は、データベースとして  SQLite を採用している。

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

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

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

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

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

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

 

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


ここらへんは、このあと、ちょっと勉強。

coreData という ORM が使われてました。そのため、ぱっと見、わかりにくくなっていたわけです。例えば、Z_PK などは coreData が管理しているカラムで、改変時にはそれほど意識しなくてもいいものです。
ここら辺のデータベース周りの知見は、わかった範囲内でメーリングリストに流しておきましたので、必要あれば過去ログ探してみてください。

 

ROI

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

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

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

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

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

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

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

 

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

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

なので改変。

 

 

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

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

 

(追記)なので、まず、色目の修正。

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

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

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

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

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

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

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

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

 

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

 

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

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

 

解剖ちゃんホーリックス

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

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

「解剖ちゃん」という。

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

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

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

これである。

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

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

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

 

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

 

(追記)今度は、昔、ウチでバイトしていた学生さんが面白いことやってくれました。


ぼくのかんがえたさいきょうのウマむすめ-ホーリックス-』(秋葉ちゃんねる

やや、悪ノリですが、嫌いではないので、許す(笑)。

一方、『ホーリックス、Horlicks、そして HorliX』は打って変わって好まとめ。


真面目に書けばできるじゃん(笑)。

(追記2)この記事、「ホーリックス」でググってもけっこう上位に来てますね。ええと上で説明しているのは、アプリの方の HorliX (ホーリックス)です。
競走馬のホーリックスは Horlicks 。母が Malt だったので、麦芽飲料の Horlicks にちなんで命名されたようです。
若駒の頃は、そんなに目立たない馬だったようですが、真面目な性格だったようで、その後、本格化。1989 のジャパンカップでオグリキャップと死闘を演じ、見事、2’22″2 という芝 2400m の世界レコードを打ち立てました。
HorliX は Horos + OsiriX で HorliX なんですが、競走馬の方も意識はしていてそのアイコンは、「大海原に白馬」となってます。もちろん、ホーリックスが芦毛だったためです。

 

DICOM XA

医療画像を吐き出す医療機器は、レ線撮像装置やCTなどの他にもMRIや超音波などがある。ダイコムの世界では、それらの機器/画像を区別するためによくモダリティという言い方をする。CR, CT などの特徴的な略語が与えられている。

radialist 先生が取り組まれていたのは、XA (X-ray Angiography) の画像複号に関する事案だ。いわゆる「透視」というやつで、インターベンションはこの画像情報によるアシストがなければ、たぶん仕事にならないと思う。

リアルタイムではもちろんだが、後の利用のためにも手軽に再生できることが望ましい。

もちろん、OsiriX MD や病院備え付けの高額なビューアなどでは再生できるし、おそらく HorliX/Horos でも典型的なものなら再生できる。

問題は、これを再生できるお手軽な windows 用ビューアがないって話で、医局などでちょっと画像を見てみたいというような場合、かなり不便だと思う。HorliX/Horos のソースコード上で参考になりそうな箇所をみつけたら、チェックしていきたい。

 

MPR

一般の画像処理には疎い私は、最初、MPR と言われてピンとこなかった。

MPR とは Multi Planer Reconstruciton の略で、3次元モデルを適当な断面で表示させたものということでいいと思う。

それなら、わかる。

今、HorliX は、テストをしているが、その時「カラーで MPR ができるのは OsiriX MD だけだ」というようなことを言われた。

その言葉が何を意味しているのかわからないのだが、こういう画像のことだろうか?

 

CT の画素を適当なパレットで着色して、任意の断面で表示させるということなら、それほど難しくないような…。

 

船出

github リポジトリの方は大掃除となったが、ファイル構成などを自分好みに変えたので、かなりすっきりした。

今の問題は、ローカルのリポジトリの肥大化で、調べたら20Gを超えていた。

アーカイブしている app がけっこうあるとはいえ、とんでもないサイズになったものだ。今では、ビルドするだけでも10分以上はかかる。→ Ver1.0.7 にいたってはめでたく? 30 分超え。もう笑うしかない。

マカーでもなんでもない私がこれまで開発に使ってきたのは、MacBook という機種だ。マックのノートの中では最も非力なマシンで、このままでは計算資源という点から、開発に支障がでそうだ。

 

技術的には、読めない DICOM ファイルが特定され始めた。問題が明確化されるという意味では良いのだが、意外に根が深そうなので、その点はやや不安。
今のところわかっているのは、Philips の超音波関連のスタディで、部分的にしか読み込めない。weasis でも試したが、やはり、部分的にしか読み込めなかった。(なお、本家 Horos は無条件に crash する)
某大学の解剖学教室で調べてもらったところ、OsiriX MD では問題なく読み込めるようである。さすがだ。

解析はこれから。Xcode と向き合い始めてから、ほぼ一月。これからが本番といったところだろうか。不安な面もあるが、わくわくもしている。

なお、これに関係して、ネットで情報収集をおこなったが、

Dr. Radialist’s Diary

が興味深かった。某有名病院の循環器科の先生の公開ブログ、と思いきや、ダイコム関連の話題も豊富。

やはり、動画関係のダイコムで苦労されていた。DICOM XA という規格があるのを始めて知った。

HorliX プロジェクトは、もともとは、 OsiriX が高額になりすぎて手が出しにくくなったから、Horos を日本語環境で使いたいから、というかなり現実的・個人的な目的で始められたが、その先は意外に広いようである。

(追記)ところで DICOM XA の規格のキモは、JPEG-LS の展開・圧縮だと思うが、日本語の情報は極めて少ない。

JPEG 2000 と JPEG-LS と Lossless JPEG

で、オープンソースソフトウェアを利用して実現する方法が開示されているので、興味のある人は一読を勧める。