投稿日:

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

HoroXaust2018 問題というのがあるらしい。
http://www.osirix.jp/ 
で、提案されていた。
 
要するにバージョンアップもせず古い一部の 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 のサーバだ。
ソフトのバージョンアップを促すコードは実装されているが、クラッシュさせるようなコードは確認できなかった。
さらに 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 より速い（と言ってくれるユーザーさんもいる）とか。
とちょっと宣伝。

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

 

HorliX を MacAppStore で！

 

投稿日:

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 を自己責任で使うよりは（というか厳密には使っちゃダメ）、少々対価を払ってもいいからFDA お墨付きの MD を使う方が安心なのだ。

 

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

よくわからん。

 

投稿日:

HorliX/Horos/OsiriX written in Objective-C

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

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

あと、読んでいて気がついたのは、Horos プロジェクトがつけたコメントがけっこう間違っているように思う。信用してどハマりしたことがあったので、気がついた。もちろん、全部、間違えているわけではないし、有益なコメントも多く有り難いのだが、「ここ間違えちゃいかんだろう」というところで、いい加減なコメントつけて逃げちゃっている感じ。感覚的な言い方をすると。

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

全然、慣れない。