HorliX on MacOS Monterey

2021/10 月末に Mac の新しい OS Monterey がリリースされたようなので、アップデート。

前回の BigSur とは異なり、大型アップデートというよりはマイナーチェンジに留まるようだ。

HorliX の動作チェック。

目立った問題はなし。

BigSur で動作するならば、Monterey でも動くでしょう。

 

猪股弘明

 

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 でも無事に動いています。

 

HorliX on OSX 10.15 Catalina (Beta)

Catalina の正式版に関する記事はこちら(↓)で。

HorliX on Mac OSX Catalina


Mac OSX の次期バージョン Catalina (OSX 10.15) のベータ版を Mac の一台にアップデート。
HorliX を走らせてみたが、試しに 2D Viewer での表示や 3D Viewer でボリュームレンダリングさせても問題なく動いた。
詳しい検証はこれからだが、主要な機能は使えるかと。

 

Catalina の正式版に関する記事はこちら(↓)で。

HorliX on Mac OSX Catalina

HorliX 開発チーム

 

HorliX カスタマイズ案件

HorliX は、AppStore から撤退を余儀なくされたわけだが、やはりというべきか、直接問い合わせ・カスタマイズが増えるようになってきた。
先日、某医療系団体からこんな問い合わせがあった。一部掲載。


メールにてもうちょっと詳細な技術的な回答をおこなったが、ここでも軽く解説しておくと…

シネマティックレンダリング→おそらく無理です。シネマティックレンダリングは、確か、複数の光源を設置し、その反射光をかなりのレベルまで計算させないと(有名メーカーがおこなっているようなレベルの)奇麗な画像は得られないと思います。現行のアルゴリズムを少々いじった程度ではでは難しい。

・・・と言ってたんですが、M1 + Metal のパフォーマンスがかなりのもので、シネマティックレンダリングまではいかなくても、かなりの画像が得られそうです。

試しに椎骨のポリゴンモデルを単一照明で3D描画させたんですが、リアルタイムで上のような画像が得られました。ちなみに私は Metal は初心者ですし、3DCGの lighting に関してもそんなに詳しくないので、そんなに凝った手法は使えないのですが、その割にけっこう綺麗な画像ではないでしょうか。
動画はこちらからどうぞ。

(ボクセルなどの)独自計算アノテーション→領域が確定したボクセルを数え上げるのは、さほど難しくない。問題は、数え上げたい領域をセグメントすることで、プラグイン作成の難易度は、領域を確定させるアルゴリズムによると思う。可能なものであれば前向きに取り組みたい。

こういう質疑応答はなんかいいですね。

ただ、基本的には従来版の HorliX のソースコードは公開しているわけだし、基本的にはプラグインの類は自分で作成してほしいと考えています。
理工系のトレーニングを受けていない医療関係者はしょうがないと思います。が、臨床工学技士や診療放射線技師など医療職でも技術よりの方はその素養がある程度あるわけですから、勉強だと思って取り組んでほしいなあと思います。

 

猪股弘明
医師:精神科(精神保健指定医

PET/CT フュージョン画像

おそらくここら辺まで来るとよほどのことがない限り一般臨床医には必要ないと思うのだが、HorliX/Horos/OsiriX では PET/CT fusion (フュージョン)画像が作成できる。

今までこの機能は使ったことがなかったのだが、この部分のコードに若干の修正を加えたいと思ったので触ってみた。

適当なサイトから PET/CT 用のダイコムファイルを落としてくる。

スタディ内の PET 画像もしくは CT 画像を 2D ビューアを立ち上げたのち、他方の画像をビューアをもう一つ追加して表示させれば自動的にフュージョン画像を作ってくれる(別のやり方もあるのだが、ここではわかりやすさ重視でこちらを採用)。

例えば OsiriX ではこのようになる。

もちろんここから 3D 表示もできる。HorliX でボリュームレンダリングさせてみるとこうなる。

落としてきたサイトには soft tissue sarcoma と説明が書いてあったので、おそらく左大腿の高輝度領域がそれではないかと思うのだが、じっくり読んでいる暇はなかったので確信は持てない。

また高輝度領域と書いたが、画像のコントラストが対消滅後に生成された光子の検出カウント数を単純に反映させたものなのか、それともそれを体重等で補正した SUV (Standard Uptake Value) なのかはわからなかった。

が、ここは一応画像が問題なく得られたということで先に進もう。修正したいのはその先の SUV 関連だからだ。

で、しばらくソースコードを読んで得られた結論は、「Horos には(というか Fork した当時の OsiriX には)放射線同位体を注入した時刻、被験者の体重などから、(光子カウント数を反映した)ダイコムのピクセル値から、臨床的に有用な SUV 値を計算する機能が実装されていたようだ」というもの。ようだ、と書いたのは、私がその計算式を今すぐ評価できないから。さすがにこれは調べないとわかんない。

しかし、この機能、実際に PET が稼働している施設以外はあんまり必要ないんじゃないかと思う。→読影の先生に聞いたら「異常集積があった場合、SUV で確認をとる」とのことなので、次回か次次回のリリースまでには復活させます。失礼しました。

今回、手を入れて、この機能を根こそぎオフにした。

しかし、フリーソフトでここまでつくりこむという姿勢に当時の OsiriX Team の志の高さがうかがえる。

その他、修正事項

今のところなし。

 

(参考)そもそも PET とは何ぞや?という方は
わかりやすいPETの話
をご参照ください。

 

にほんブログ村 病気ブログ 医者・医師へ

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

今では 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 本体のバグフィックス。問題は①か②か。ここらあたりの選択は、開発者の好みが出るところ。②はやることが決まっているが、調べることも含めてとにかく作業量が多い。①はバグがどこにあるか特定するのが難しく、作業時間/手間がどの程度かかるかまったく読めない。

 

(続く)

 

 

 

DICOM US を読めるようにする

日本語化は日本語化で進めるにして、私が HorliX 絡みで問題に思うのはやはり US (超音波)関係。

おかしな US を読み込もうとするとデータベースが使えなくなってしまうのだ。

読めない分にはまだいいが、それまであった正常なデータにまで影響が及ぶのはまずい。

※…ただし、データベースが完全に破壊されるわけではなく、それまでのデータは /HorliX Data/Database.noindex/10000 などに配置されているので、再読み込みなどをすれば復旧はすると思う。

 

一応、手がかり↓はつかんでますので、これから修正作業にはいります。

て、悠長なことやってたら、horosproject の中の人が解決したっぽい。

先、越された。

 

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 を日本語環境で使いたいから、というかなり現実的・個人的な目的で始められたが、その先は意外に広いようである。