DICOMと画像圧縮
幅と高さがそれぞれ512のグレースケール（1ピクセルあたり1サンプル）、格納ビット数（Bits Stored）が12の典型的なCT画像を考えてみましょう。
この画像を保存するために必要なコンピュータのメモリはどのくらいになるか、計算してみましょう。
12ビットを格納するためには、2バイト（16ビット）を確保する必要があります。
画素数は、512×512なので、それを格納するための総バイト数としては
512 × 512 × 2 = 524,288 byte
つまり、CT画像は、 (7FE0,0010) Pixel Data属性のために、およそ、0.5 MB（メガバイト）のデータ容量が必要です。
一般に、CT画像は一枚ではなく、数百枚から数千枚の画像を含む複数のシリーズが検査で取得されます。たった200枚のCT画像で、およそ100MBを占めることになります（ピクセルデータのみで）。
このようなデータを「頻繁に」別の場所に転送したり、ダウンロードしたりするには、回線の速度も速くなければなりません。また、このような検査は毎日、何件も行われるわけですから、簡単に保存容量の上限に達してしまいます（実際には、画像サーバーに十分な保存容量が確保されているはずですが、一般のPCではすぐにいっぱいになる、ということで）。大きな病院では、一年間で何万件（仮に、一年365日、一日で50件の場合、18,250回！）ものCT検査が実施されています。
直接的なアドバイスとしては、「もっといいコンピュータを買え」とか、「もっと速いネットワークを使え」かもしれません。システムのハードウェアをアップグレードすることは良い考えですが、実際には、お金の問題が発生します。
また、画像検査装置の驚異的な進歩にも注目すべきです。
DRやCR、多列CT、デジタルマンモグラフィ、MRI、超音波装置など、生成する画像の解像度は良くなり（高くなり）、画像数も増えています。この結果、必然的に画像データのサイズは大きくなっています。
画像データ容量を圧縮する技術が必要なのはそのためです。
DICOM規格は画像圧縮に対応しています。画像圧縮は、（7FE0,0010）Pixel Data属性に格納されるピクセルデータを対象として、より短い形式へ変換します。これにより、元の画像サイズが大幅に縮小され、保存容量が節約できます。画像の送信またはダウンロード時間の短縮にも効果的です。
DICOMが独自の画像圧縮技術を発明したわけではありません。
DICOM は、RLE（Run Length Encoding）、JPEG、JPEG2000、JPEG-LS、および ZIP など、よく知られた画像圧縮アルゴリズムをサポートしています。これらのアルゴリズムはその専門の技術者によって別々に開発された経緯があります。DICOMは単にこれらを規格の中に採用したというわけです。 (07FE,0010)PixelData属性へ格納するピクセルバッファを、圧縮されたピクセルバッファにも対応できるよう、規格を調整したのです。バッファというのは、データを一時的に保持しておくための記憶領域です。
圧縮されたピクセルデータを持つすべてのDICOMオブジェクトは、Explicit VR LittleEndianでエンコードされます。
データの圧縮の考え方を簡単に
データ圧縮の直観的な考え方は、難しいものではありません。どんな圧縮アルゴリズムでも、冗長で反復的な情報を見つけて切り捨て、データをより短くしようとしているだけです。
圧縮の効率は、圧縮率（R_comp）で定量化できます。
R_comp = 元のデータサイズ / 圧縮後のデータサイズ
R_compが高いほど、より多くのデータが圧縮されていると考えます。例えば、R_comp = 10なら、圧縮後のデータは、圧縮前よりも1/10のデータサイズになります。
画像の圧縮アルゴリズムは、データの性質を残したまま、R_compを最大化するよう考え出されています。圧縮アルゴリズムは、大きく、可逆圧縮（ロlossless, 完全に元に戻せる）と非可逆圧縮（lossy, 元に戻せない）の2つのカテゴリに分類されます。
可逆圧縮（lossless）
可逆圧縮では、画像を圧縮（compression）して、そのあとにこの圧縮した画像を解凍（decompression, uncompression）しても、画像は変化しません。完全に元に戻ります。
これは、ピクセルバイトを巧みにグループ化したり、名前をつけて置き換えたりすることで実現されています。
イメージとして、次のような画素値の並びがあるとしましょう。
1000, 1001, 1002,1002,1000,1000,1001,1057,...
一般的な可逆圧縮アルゴリズムは、1000のような最も頻度の高い値を探り、短い記号に置き換えます。
例えば、"1000 "を "a "に置き換えると、元の文字列は次のようになります。
a, 1001,1002,1002,a,a,1001,1057,...
"a" は "1000" より短いので、データ全体の文字列が短くなり、"1000"の値を "a"で圧縮したことさえ覚えていれば、いつでも圧縮を解除して元に戻せるのです。
このような圧縮方法は「可変長符号化」と呼ばれています。可変長符号化で有名なのは、ハフマン符号化があります。
すべての画像には、必ず圧縮できる部分（同じ値をもつピクセルサンプル）があります。例えば、背景が黒い画像などです。
しかし、ピクセルの繰り返しはある程度までしか利用できないため、医用画像では平均的にR_compは 2～（相当良くて）4 程度です。その結果、圧縮後の画像サイズは元の画像の 2分の1 ～ 4分の1となります。
DICOMでは、次のような可逆圧縮がサポートされています。
RLE
Lossless JPEG
Lossless JPEG2000
Lossless JPEG-LS
ZIP
可逆圧縮で十分！という考え方もできますが、非可逆圧縮のメリットもなかなか大きいのです。
非可逆圧縮（lossy）
非可逆圧縮は、その名前が示すように、元にはもどさない圧縮です。こういわれると印象がよくないかもしれませんが、いい点もあります。高い圧縮率（R_comp）が達成できることです。
ただ、元に戻さないとは言うものの、大切な情報の大枠は残します。犬の画像が猫になったりはしません。高い圧縮率を達成するために、多少の犠牲を払うというものです。
犠牲というのはどういうことか、簡単にイメージしましょう。先ほどと同じ画素値の列を例に挙げてみます。
1000, 1001, 1002,1002,1000,1000,1001,1057,...
画素の強度が1000程度だとしたら、1000と1001の違いは、視覚的に認識できるでしょうか？おそらく、画素の輝度が0.1％しか変化していないため認識できないでしょう。
そこで、この差は許容できる誤差として、1001を1000に置き換えると、次のようになります。
1000,1000,1002,1002,1000,1000,1000,1057,...
ここからさらに、先ほど説明した可逆圧縮を適用すると、次のようになります。
a,a,1002,1002,a,a,a,1057,...
この結果、純粋な可逆圧縮よりもデータを短くできるわけです。
つまり、可逆圧縮が同一画素値のみを符号化に利用しているのに対して、非可逆圧縮は、目立ちにくい誤差範囲内にあるピクセル値に拡張しているのです。
上記の例では、1001値を誤差の範囲として圧縮しましたが、誤差を1002まで広げると、さらに圧縮できます。
a,a,a,a,a,a,a,a,1057,....
圧縮率を高めるために、誤差範囲を広げればよいのです。こうすることで、任意の圧縮率を指定できます。現在の非可逆圧縮アルゴリズムでは、R_compを100まで上げることができます（100分の1に！）。
もちろん、圧縮率を高くするほど、犠牲も大きくなります。視覚的に許容できる程度の妥当なR_compが設定される必要があります（10程度までが限度）。というのも、圧縮率を高くしすぎると、視覚的にもわかるくらいの画像上のアーチファクト（JPEGで過剰に圧縮されるとチェッカー・アーチファクトが発生します。一定の色を持つブロック様の見た目をしています）が生じます。そのため、10を超えるR_compは一般的には使われていないようです。元のサイズの10分の1に圧縮すれば、データも十分軽いですし、元の画像とほぼ見分けがつかないでしょう。ソフトウェアでR_compを制御できる場合、R_compは10以下に維持するのが無難です。
非可逆圧縮画像を使うときにはもう一つ注意が必要です。それは、非可逆圧縮を繰り返し行わないようにすることです。繰り返し行ってしまうと、画質が著しく劣化します。元のCT画像を適切な圧縮率（例えば、R_comp < 10）で非可逆圧縮-解凍を1回行った場合、解凍後の画像は元の画像との違いが分からないレベルになりますが、この画像の圧縮と解凍を保存や呼び出しのたびに繰り返すと、圧縮による画質劣化が累積されてしまいます。
思いもよらない非可逆圧縮ループ事故を未然に防ぐために、非可逆圧縮を利用しないというのも手ですが、後述するストリーミングの際などには積極的に利用したい技術になります。
DICOMで利用できる非可逆圧縮は主に次のようなものがあります。
JPEG Baseline8bit
JPEGExtended12Bit
JPEGLSNearLossless
JPEG2000
実際、DICOMによる画像圧縮のサポートの大きな課題の1つは、R_compをDICOMが完全に制御できないことです。
医療画像の非可逆圧縮の使用が臨床的に許容されるかどうかというコンテキストは、DICOM規格の範囲を超えています。JPEG非可逆圧縮の適切な圧縮パラメータ（例えば、圧縮率）の選択に関連する方針も、この規格の範囲外です。
DICOM規格には、2022バージョンではまだ正式にR_compを設定または検証するものがなく、圧縮アルゴリズムのみ転送構文によって選択できるようになっています。したがって、R_comp のサポートは常にDICOMメーカーに委ねられており、メーカーがこのオプションを提供している場合もあるようです。
コンピュータ支援診断と非可逆圧縮率
非可逆圧縮は、コンピュータ支援診断（Computer Aided Diagnosis; CAD）のアプリケーションにも影響を及ぼす可能性があります。人間の目には見えない非可逆圧縮によって生じた画質変化が、CADにとってのノイズとなって、CADの処理エラーを招く可能性があります。しかし、逆も言えます。CADは非可逆圧縮の適切さを評価する客観的なツールになりえます。元の画像と非可逆圧縮後の画像で同じ結果が得られるなら、画像が過度に圧縮されていないことを示す良い指標となるでしょう。少なくとも、そのように検証された「非可逆」圧縮率のもとで運用される画像を、CADへの入力に用いる場合は処理に支障をきたすことはないでしょう。
ネットワーク上のストリーミング(Streaming Compression)
ストリーミング・コンプレッションあるいはオンデマンド・コンプレッションは、標準的な圧縮アルゴリズムの賢い使い方です。
ストリーミングは、ウェブ上で動画を見るときなどに何度も目にするサムネイル画像に似ています。
例えば、画像枚数の多いMRI画像をダウンロードして確認する必要があるとします。数枚はすぐに見れるかもしれませんが、すべてダウンロードし終わるまで、全画像が見れない状態になってしまいます。ネットワークが十分に高速でない場合など、全画像を見ることができない状態が続くのはストレスフルでしょう。わざわざ画像全体を一度に読み込まなくても、ある程度の画質でいいので、画像をささっと確認できる方法が欲しくなるはずです。
このようなニーズに応えるのが、ストリーミング・コンプレッションです。
この圧縮は、欲しい画像を追跡し、現在表示している画像だけ高解像度にします。必要なものだけ高解像にすることで、処理中の画像データサイズを減らし、その結果、ダウンロード時間が短くなったように見せることができます。圧縮が働くことになるため、全体の画質は低い状態です。現在表示している画像のみを特別に高画質にするのです。ローカルPCにすべての画像をダウンロードすることが必要な場合は、このストリーミングと並行してウラで処理を進めておくことができます。
ストリーミング・コンプレッションを利用する際、ユーザーのモニターの情報が分かれば、そのモニターに十分、かつ、可能な限り低い解像度の画像をユーザーに送ることができるでしょう。
次に、ユーザーが特定の画像領域にズームやパンをすると、ストリーミング・コンプレッションはその領域のみに高解像度の画像を読み込むこともできます。
このように、「やりたいことができる」「早い」を提供することで、ユーザーの満足度は改善されるでしょう。
ユーザーは、特定の画像領域だけを見ることが多いです。特に病変が分かっているときなどは、数百枚の画像全体のコピーは必要ないことがほとんどです。
ストリーミング・コンプレッションを用いることで、ユーザーは、高解像度の画像全体がダウンロードされるのを待たずに、作業を開始することができます。
画像全体のダウンロードを、「今」必要な部分だけに区別することで、ダウンロード時間というボトルネックを目立たなくすることができるのです。
これらの理由で、ストリーミング・コンプレッションは、遠隔画像診断システムで人気です。
ストリーミング・コンプレッションの唯一の欠点は、その主な利点である、画像ダウンロード全体を画像閲覧時間に分散させることにあります。
ユーザーが異なる画像を参照したい場合、新しく表示したい画像を優先的に処理する必要があります。頻繁なスライス送りは、優先度を簡単に混乱させてしまうでしょう。もしネットワークスピードが遅い場合は、最初から「ながら」作業は期待せず、（古典的であるけれども）ダウンロードを待って処理した方がいいと考えるユーザーもいるかもしれません。
圧縮とネットワークスピード
画像の圧縮はピクセルデータを短いフォーマットに短縮しますが、再度、画像として表示できるようにするためには、DICOMソフトウェアが毎回、圧縮されたピクセルデータを解凍（decompression）する必要があります。
私は、「圧縮画像だから画像の表示が速くなるでしょ」と思っていたのですが、 これは完全に間違っていました。単純なデータ転送の通信速度は速くなりますが、画像表示系の処理速度は、同じビットタイプで運用されるうえでは変わらないか、解凍時間を含めればむしろ長くなることもあるはずです。
例えば、R_comp=10で圧縮された画像ファイルがあり、30MBだとして、これを解凍すると、元のサイズである300MBに戻ります。表示系では、結局、300MBで操作することになります。
次に、ネットワークについては、ネットワークスピードが仮に100Mbpsであったとします。圧縮・解凍の時間がそれぞれ200Mbpsと仮定します（適当です）。
圧縮された画像を送信することだけを考えると：
(30 MB × 8) bit / 100Mbps = 2.4 sec
圧縮と解凍も考慮すると：
圧縮時間 = (300 MB × 8) bit / 200 Mbps = 12 sec
送信時間 = (30 MB × 8) bit / 100Mbps = 2.4 sec
解凍時間 = (30 MB × 8) bit / 200 Mbps = 1.2 sec
計 15.6 sec
オリジナルのまま送ったら：
(300 MB × 8) bit / 100Mbps = 24 sec
このくらいのネットワークスピードと、画像の圧縮・解凍スピードがあれば、オリジナルを送るよりも圧縮した方がトータルで早いので、画像の圧縮には効果がありそうだといえます。この例では、圧縮によって約1.5倍(24/15.6)処理が速くなることになります。一方で、ネットワークスピードが遅い、あるいは、画像圧縮・解凍処理時間が長い場合は、圧縮した方がスピードが遅くなります。ただし、圧縮によってスピードは遅くなっても、圧縮している分、ストレージへの負荷は減る利点は変わりません。
最後に
どのような圧縮方法を選択するにしても、PACSサーバー、モダリティ、ソフトウェアが利用しやすい転送構文でやり取りしなければなりません。固有のベンダーに依存する圧縮方法のみをサポートするようなPACSサーバーストレージは使用しないようにしましょう。同様に、圧縮率だけで判断しないようにしましょう。神獣を読まなくては。
Stay Visionary
この記事が気に入ったらサポートをしてみませんか？