HorliX on Mac OSX Catalina

Catalina の正式版がいつのまにかリリースされていたので、アップデート。

HorliX は無事動いているようです。

最新、Ver1.0.7 は、ダウンロードページからどうぞ。
日本語で使いたい方は、(もちろん)Japanese Ver を落としてください。

アノテーションの「文字化け?」について

日本では報告されていなかったのですが、2D ビューアや 3D ビューア上で描画されるテキスト文字が解読できないくらい乱れるという問題が指摘されていました。
HorliX であれば

github issues: HorliX with CATALINA , TEXT LINE ILLEGIBLE

Horos であれば、

github issues: Length assessment bug [ROI] , Annotation colour is green, cannot change after update Catalina

あたり。

報告されているとはいっても、かなり特殊な条件でしかおこらないようなので対応を後回しにしていたのですが、3次元表示(ボリュームレンダリングなど)あたりのコードを整理・手直ししていたときに、「あ、そういうことか」と思い当たる節があり、下記のような操作を実行してみたところ上手くいきました。

HorliX のメーリングリストに流したのですが、ここでも解説します。

かなり特殊な実行環境だと思うのですが、ROI などを使った場合、


というようにまるっきり文字が読めない現象が出現するときがある。
このバグが生じるのは、実行環境の Mac のモニターのカラープロファイルが意図せぬ設定になっているせいなので、これを修正する。
具体的には、まず、画面左上にある林檎マークをクリックしてメニューアイテムを表示して『このMacについて』を選ぶ。

するとパネルが現れるので、『ディスプレイ』を表示させ、パネル右下の『”ディスプレイ”環境設定…』ボタンをクリック。

するとディスプレイ設定パネルが出現する。
ここで『カラー』を選ぶ。するとカラープロファイルの設定画面に切り替わる。

文字が判読できないような場合、ディスプレイプロファイルが『一般RGBプロファイル』以外になっているので、これを『一般RGBプロファイル』に選び直す。

この設定変更の後、再度アプリを立ち上げると

と文字が正常に表示されるようになります。

ソースコードレベルでの修正は検討しているところです。(できれば OS の側で修正して欲しいんですが)

その他

今のところ、Catalina 移行に伴うバグらしいバグは上がってきていません。

今後の予定

3次元表示周りは、今一つコードが整理しきれていない印象があるので、ここは現在修正中です。

VR (ボリュームレンダリング)

なお、上記のサンプルは MacOS BigSur でも無事に動いています。

今後の予定(追加)

Volume Rendering のところを整理する、みたいなことを言ってましたが、ここはどう頑張っても OpenGL になってしまうので(VTK の機能を利用しているため)、Metal で同様の機能を書いてみました。

オリジナル同様、RayCast Mapping という手法を使ってます。

OpenGL は廃止になることがわかっているため、こちらの方がいいでしょう。

 

HoroXaust2018問題 〜ロゼッタの呪い〜

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 も64ビットアプリ、基本機能はけっこういいですよ、処理によっては OsiriX MD より速い(と言ってくれるユーザーさんもいる)とか。
とちょっと宣伝。

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

 

Horos 3.1.2 リリース。しかし….

最近、Horos の Ver3.1.2 がリリースされた。

開発者の一人としてもインストーラー版の出来は気になるところなので、今日、落としてきた。(なお、ダウンロードは、こちらのページからどうぞ。所定の事項を記入するとダウンロードページの URL が記載されたメールが届きます)

さっそく使ってみると….

 

メニューなどもある程度日本語化されている。が、肝心の 2D ビューアが立ち上がらない…….orz

なんのために日本語リソース提供したんだか。

おそらくインストーラー版つくっている人のチェックミス。

英語圏の人にとっては英語版さえ正常に動けば、確かに問題ないわけですが、日本人としてはちょっと悲しい。

 

horosproject の中の人がいうには、すぐに Ver 3.2.0 をリリースするとのこと。

それまでのつなぎでよければ、HorliX をつかってみてください。

最近は機能も微妙に変わってきたとはいえ、数か月前までは同一のソースを使っていたので、使い心地はそんなに変わらないと思います。

こちら↓のページから落とせます。

HorliX ダウンロードページ

 

OS は HighSierra 以上が必要です。

 

 

放射線科読影レポート

放射線科読影医以外ほぼ必要ないと思うのだが、Horos にはレポート作成機能がついている。具体的にいうと適当なスタディを選択した状態でツールバーの

のアイコンを押下すると、指定したワープロソフトが立ち上がり読影レポートを作成することができる。

デフォルトのワープロは pages だが、MS Word や LibreOffice に変更することもできる(少なくともソース上ではそうなっている)。

今日、ここら辺をいじっていたのだが、変更をどこでするかわからない。しばらく探してやっと見つかった。どこにあったかといえば「環境設定」>「データベース」で表示されるパネルの一番下。

こんなところに…..。

なんでワープロの設定項目がデータベース関連のパネルに配置されているんだよ。これは知ってないと見つけられないと思う。

 

ところで、 HorliX では諸々の理由でしばらく LibreOffice はサポートしません

見捨てたわけではなく、メンテに時間がかかりそうなので時間が取れるまでそうせざるを得ないというのが実情です。

 

オープンソースの光と闇 -光編-

今では HorliX/Horos は、Philips 社の US(超音波)画像も読めるようになったわけであるが、この解決までの道のりが、その経緯を見守っていてくれた人たちから「感動した」とか「不思議な感じがした」と言われることが多いので、ちょっと思うところを書く。

まず、オープンソースにおける開発の特徴に関しては、

伽藍とバザール

というこの分野では基本的かつ必読の文献があるので、一読をすすめる。

 

Linux は破壊的存在なり。インターネットのかぼそい糸だけで結ばれた、地球全体に散らばった数千人の開発者たちが片手間にハッキングするだけで、超一流の OS が魔法みたいに編み出されてしまうなんて、ほんの 5 年前でさえだれも想像すらできなかったんだから。

 

あまりに有名な冒頭の一節。これになぞらえて言うなら、こんな風に表現できるだろう。

HorliX/Horos は破壊的存在なり。インターネットのかぼそい糸だけで結ばれた、地球全体に散らばった両手の指の数にも満たない開発者たちが片手間にハッキングするだけで、超一流の DICOM Viewer/PACS が魔法みたいに編み出されてしまうなんて、ほんの 5 年前でさえだれも想像すらできなかったんだから。


 

問題の発端は、Horos では、Philips 社の US 装置が吐き出すある種の DICOM ファイルを読めない、というバグレポートから発する。(読めない、というかクラッシュする、といった方が適切。それくらいあっという間に落ちてた)

Philips DICOM US が読みにくいというのは、以前から知られていて、例えば

iQ-VIEW(おそらく昔の K-PACS)だと、ファイル自体はなんとか読めるが肝心の画像は

と見事におかしなコントラストで描出される。また、全体のファイル構造も正しく反映されていない。

廃れた感のある iQ-VIEW に代えて、「今でも現役」 weasis でまったく同じファイルを読み込ませてみる。

全体のファイル構造は正しく読み込めているが、一部のシリーズがまったく描画できない。

このような結果のため、Philips DICOM US が読み込みないのは仕方がない、というような見方もあったようだ。

だが、Horos 陣営にとってこれが捨てておけない問題だったのは、OsiriX MD が上にあげたファイルを難なく読み込んでいる事実があったからだ。これはちょいとばかり悔しい。いつかは解決しなければならない問題だという認識は、世界中に散らばった各開発者には漠然と共有されていたと思う。

もちろん、そこはオープンソースコミュニティ。中の人を除けば、開発優先順位が、かっちり決まっているわけではない。

このとき、私の頭の中にあったのは、bug fix 系であれば

① Philips DICOM US problem

② DICOM PRINT problem

であった。

もちろん、機能の独自実装もやりたかったが、どれも手間がかかりそう。となると Horos 本体のバグフィックス。問題は①か②か。ここらあたりの選択は、開発者の好みが出るところ。②はやることが決まっているが、調べることも含めてとにかく作業量が多い。①はバグがどこにあるか特定するのが難しく、作業時間/手間がどの程度かかるかまったく読めない。

 

(続く)

 

 

 

オープンソースと収益化

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

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

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

 

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 が管理しているカラムで、改変時にはそれほど意識しなくてもいいものです。
ここら辺のデータベース周りの知見は、わかった範囲内でメーリングリストに流しておきましたので、必要あれば過去ログ探してみてください。