2026年8月のこと

前々からやろうと思っていたのだが、Horos の解説記事と HorliX の解説記事を新調した。

Horos -wikipedia 風解説-

HorliX -wikipedia 風解説-

旧記事をどうするかなんだが、今回はそのまま廃棄にする予定。

ところで、最近 Horos に関して言われているのは「限界零細業者にとって都合のいいプロジェクトだった」っていう考察。
issues を見ればわかるが、どこそこの表示を変えてくれとかそんなのばっかり。
おおかた
顧客「ここのフォントを変えたい」
業者「うちならできますよ!」
みたいな背景があったんだろうな。
そんなの自分でやれよと思うのだが、それもできない業者が有り難かっていたんだろうな。

 

HorliX/Horos

HorliX 開発の経緯を知る人は、HorliX を紹介するにあたってよく HorliX/Horos などと表記する。
HorliX が Horos の fork だからなのだが、では、HorliX が Horos の改変を全て取り込んでいたかというとそんなことはなく、ほとんどの改変は取り込んでいなかった。

代表的なものが roi-color-rotation-UI で、大元のアイアディアやソースコード自体の提供が Hiroaki-Inomata/air-h-128k-il 名義でなされたにも関わらず、Horos の凝ったコードを取り込むことはしなかった。
Horos のコードの方が見栄えがいいので、周囲は「なんで?」と思っていたのだが、最近になってその理由がわかってきた。
新しいコードが生成する保存形式では他アプリへの互換性も後方互換性も無くしてしまうから、というのがその理由だろう。

大抵のビューアでは、ROI を DICOM SR というフォーマットで記録する。
Horos もそうなのだが、SR の内部的に独自形式を使っていて他のアプリでは読めない。ここでさらに独自の情報を加えてしまうと、古いバージョンの Horos でもこの情報が読めない。
これではなんのための改変なのかわからない。
HorliX 開発陣が選択したのは、この改変を取り込まないこと、つまり、動作時にのみ ROI の色がくるくる変わるだけで、色情報そのものは保管しないこと、だった。
確かにこうしておけば、アプリ間の互換性そのものは保たれる。その後、改変するにしても作業の見通しがいい。

ああ、そういうことだったんですかと答え合わせさせてもらった気分です。

ataraxia
ANN2b

(追記)これ書こうか書くまいか迷っていたんだが、思い切って書くと、群馬大の dicom viewer の紹介ページがひどい。
ダイコムに関与する開発者・研究者目線で言うと Horos や miele は、ほぼ完全に「使えない」ソフトだ。
ROI の計測データやセグメンテーションの結果が、他のアプリに移行できないのだから、まともな解析用途に使えるわけがない。
閲覧するだけならいいではないかと思いはするが、それでもさすがに「OpenGL に依存するために deprecated な機能を使っている」ことくらいは明記すべきだろう。
群馬大医学部がゴタゴタしているのは知っているが、その一端が出ているよう気がする。

バイブコーダーたち

某氏が Mac 向けの DICOM Viewer のおすすめ記事書いているが、いや、マニアック(笑)

Metal ネイティブ対応云々でワンライナーのコマンド出してくるあたりが、実に「らしい」。

それはともかく、その記事で角辻先生の MultiDICOMViewer が取り上げられていたので、いくつかコメント。

MultiDICOMViewer

まず、アプリは OSS ではあるが、開発者に OSS の流儀に従う意思はあるかといえば、ないでしょう。

PyQt 使う → Qt 入っている → GPL 適用

という流れで見かけ上 OSS にする必要があっただけだから。OSS の理念に感銘を受けてとかいう話ではない。しかも、他アプリの fork ではなく、エージェントと二人三脚でスクラッチで作っているのだから、OSS 的な運営をする気持ちは微塵もないでしょう。

OSS らしさがないことに少し残念に思う気持ちもあるが、今後はこういう人たちが増えていくでしょう。

だから、AI の助けを借りてたまたま「バイブコーダー」になった人に見られる共通の特徴のようなものついて考えてみたい。なので、以降は、角辻先生が、という話ではないです。

作りたいものを作ってオシマイ!

これはあるでしょうね。
動機が「◯◯を作りたい!」だと思うので、本人にとっては何の不満もないのだろうが、ちょっと惜しいなと思わないでもない。ストレージ機能や出力機能を付け加えたらもっと良くなるのに・・と思うことは多々あるからだ。ただこういった感想は、ある程度目が肥えているから言えるのであって、そこはバイブコーダーとは感覚が違うのだ。

上と関係しているのかもしれないが、これだけ AI が進化しても

アプリを作れない人たちもいる

のは、もうちょっと認識されていい事柄だ。

(続く)

 

PaxViewer の技術的側面

PaxViewer はほぼフルスクラッチで書いたが、そこは DICOM 関係、OSS の助けを借りている。
技術解説にちょうどいいと思うので、どのように使われているか軽く説明。

DCMTK

dicom タグ解析の定番ですね。ただ、表示にはこちらは使わず、もっぱら PACS 部のタグ解析です。

GCDWebServer

今回は、ウェブサーバは独自実装していない。
macOS バージョンは、GCDWebServ を採用。

Crow

windows バージョンのウェブサーバには、Crow を採用。

Cornerstone.js

詳しくはこちらの公式サイト参照。
表示の dicom タグ解析は DCMTK ではなくこちらです。

VTK.js

詳しくはこちらのサイト参照。
視覚ライブラリの定番 VTK に JavaScript バージョンがあるとは思いませんでした。
ありがたく使わせてもらってます。

 

HorliX dev team