DICOMと医用画像
この解説は、DICOM VRやDICOMオブジェクトの世界を、一緒にさまよってくださった方のみが進めるNextステージです（笑）。VR？DICOMオブジェクト？な方は、前の解説に戻って確認をお願いします。。
DICOMオブジェクトの探求は、惑星DICOMに旅行に行ったときに、挨拶ができるようになるかどうかくらい基本です。この挨拶ができない人は、まだこの先へは進めません（神獣も召喚できませんよ）。
さて、ここから先へ進める方は、次の重要なステップである「DICOMと医用画像との関わり」を紐解いていきましょう。
昨今の医用AI産業は、とてつもない勢いで成長しています。AIの開発に欠かせないのが学習データであり、特に学習データに画像が必要な時は、DICOMほどふさわしいものはないでしょう。
これまで見てきたように、DICOMには現実世界の属性が多分に組み込まれており、AI開発者はこれらの属性を駆使して、実際のワークフローにFitする推論モデルを開発できます。
画像は、DICOMデータ辞書に記載されているように、よく知られた特性（ピクセル配列の幅、高さ、ピクセルあたりのビット数）を持っており、DICOM は明示的（Explicit）または暗示的（Implicit）なVRでピクセルデータをエンコードしています。
DICOM画像には、ピクセル値の配列が格納されます。ピクセルは、1ピクセル（サンプル）にどのくらいの情報を持たせるかによってタイプが分けられます。
8 bit グレースケール：OB（1バイトの1ピクセルサンプル）
16 bit グレースケール：OW（2バイトの1ピクセルサンプル）
32 bit グレースケール：OF（4バイトの1ピクセルサンプル）
64 bit グレースケール：OD（8バイトの1ピクセルサンプル）
RGB：OBまたはOW（1 or 2バイトで、３ピクセルサンプル）
など
ピクセルサンプルは、色を構成するための要素です。グレースケールの場合は白黒なのでサンプルは一つのみ、RGBの場合は３つあります。32 bitや64 bit画像は少し特殊な画像で、ピクセル値が小数まで記録されてい
る画像データです。核医学画像や、計算画像、病理画像などのグレースケール画像として活躍します。
ビットごとに、格納されるPixel Dataタグの種類が変わります。
8 bit/16 bit：PixelData属性
32 bit：FloatPixelData属性
64 bit：DoubleFloatPixelData属性
RGBはPixelData属性が利用されます。
以降は、一般的に用いられる(7FE0,0010)Pixel Dataタグを対象として話を進めます。
DICOMは、ピクセルを(7FE0,0010)Pixel Dataタグへ格納するために、さまざまな画像フォーマットをサポートしています。
フォーマットは大きく二つに分類できます。
DICOM専用：DICOMでのみ使用されるフォーマット。これらは一般的かつ古典的な画像フォーマットに基づくものです。ピクセルバイトをパッキングした生のビットマップに似ています。いわゆる、非圧縮画像です。
DICOMに受け入れられているフォーマット：JPEG、RLE（Run Length Encoding）、ZIP、JPEG2000やJPEG-LSなど、画像を圧縮（Compression）できるフォーマットが含まれます。
まずは、前者から見ていきましょう。
DICOMのBitmap
デジタル画像は、ピクセル（画像要素，実際の画像を形成する小さな点）で構成される長方形のマトリックスです。
例えば、一般的なMRI画像があるとして、その幅が256ピクセル、高さが256ピクセルだとすると、256×256＝65536ピクセルあるということになります。このピクセルを左上から一行ずつ書き出すと、65536個のピクセルのシーケンス（列）になります。まさに、ビットをマップしているわけですね。これをDICOMファイルに保存することになります。
ピクセルは、一般に、左上（あるいはソフトウェアによっては左下）からラスター走査（1行目、2行目、3行目、、、という順に）で順次処理されます。
さて、デジタル画像の属性について、重要なものは何でしょうか。
画像の幅と高さ：これは知っておく必要があります。これらの積は、画像解像度と呼ばれます。画像内の総画素数を表します。
色：グレースケール、またはカラー。
カラーサンプル：色を表現するために必要な構成要素数です（グレースケールなら1、カラーなら3）。
ビット：ピクセルサンプルに割り当てられている情報量。大きいほど細かいコントラストを表現できます。8ビットグレースケール画像の場合、グレースケールの諧調は2^8=256段階と、表現できる色の数を計算できます。ビットはピクセルサンプルごとに配置され、基本的には、コンピュータ上で8の倍数に切り上げられます。
ハイビット：ピクセルサンプルを8の倍数に切り上げられたビット内で使う際に指定される上位ビット位置。
この他、ピクセル値が符号付き（Signed）/符号なし（Unsigned）のどちらの数値で表現されているのかどうかを示す(0028,0103)Pixel Representation属性（符号なしなら0、符号ありは1）や、RGBの場合はRRR…GGG…BBB…なのか、RGBRGB…なのかを示すPlanar Configuration属性なども重要です。
ピクセルのエンコーディング
次の図は、16 bitグレースケール画像のピクセル構造を示しています。この例では、ピクセルサンプルは、12ビットで表現されているものとします。
コンピュータ内のデータは、バイト単位（1バイト＝8ビット）で格納されています。そのため、12ビットのピクセルは一旦、キリの良いバイト単位（8の倍数）に切り上げられることになります。すると、この例では、ピクセルサンプルあたり確保されるメモリは16ビットとなります。ただし、ピクセルサンプルはもともと12ビットの情報しか持っていませんから、ハイビット＝11となります。え？なんで12ビットじゃないの？と私は思いましたが、0 ベースのカウントになるので、Bits Storedな値（12ビット）から-1した値がHigh Bitとなります（特別なことがない限り、この計算は一般的です）。
このように、すべてのピクセルに同じ16ビットのメモリが割り当てられ、画像全体がそのピクセルサンプルのシーケンスとして扱われることになります。
次の図は、カラーDICOMピクセルの構造の場合です。考え方はグレースケールと同じですが、RGBそれぞれでピクセサンプルを持つので、サンプルごとに処理を行うということになります。他のサンプル（この場合、緑と青）にも同じ16ビットのメモリが割り当てられ、画像全体がそのピクセルサンプルのシーケンスとして書き込まれるのです。
次に、ピクセルエンコーディングの別の例を見ていきましょう。
この場合、Bits Stored =10ビットにピクセルサンプルが格納されています。しかも、先ほどとは違って、下位ビット（Low bit）は2ビット目からカウントしています。
DICOMはHigh Bitと格納されたビット（Bits Stored）の値を属性に保持しているので、Low bit 位置を (High Bit + 1) - Bits Storedから逆算できるようになっています。すべてのピクセルが、この方式に従って処理されることになるのです。
DICOMのピクセルエンコーディングで最も厄介なのは、DICOMが未使用のビットをどのように利用するかということです。
この例では、未使用の領域は次のように計算できます。
Bits Allocated - Bits Stored = 6 bit
上の例では、ビット 0-1 と 12-15 には、ピクセルデータが含まれないため、6/16=37.5%の記憶容量が無駄になっています。
このスペースをうまく活用するために、DICOMベンダーは、画像オーバーレイピクセル（元の画像のピクセルデータとは特に関係がない）などの追加情報をそこに保存していた時期がありました。
要するに、あるデータストリームの断片を他のストリームの断片の間に詰め込んで、空白になっている全ビットを使用するようにしたのです。
この方法は、現在使われている画像圧縮やハイスペックな汎用のハードウェアが利用できなかった時代には人気があり、ピクセルサンプルの間に他のデータを格納することは、ストレージを最適化するクールな方法と考えられていました。
しかし、やがて、このアプローチは時代遅れになってしまいました。最近では、未使用の画素ビットを活用するよりも、画像圧縮を用いれば効率的にメモリを利用できるようになりましたし、もっといえば、ハイスペックなコンピュータで単純に処理した方が、難しいことを考えなくともよい（処理系でビット混乱を招くよりはよい）と考えられるようになってきました。
しかしながら、"bit squeezing" 技術はDICOM標準であり、古いDICOMユニットを扱う場合に、これらの処理に出くわす可能性があります（DICOM PS3.5 のAnnex D では、その他の可能なサンプルエンコードスキームについて説明しています）。
画像に重要な属性
これまで述べてきたように、DICOMは画像をDICOMオブジェクトとしてまとめる際に、重要な画像属性をすべて格納します。また、これらの属性は、必須であることが多いです。
DICOMデータ辞書から引用した、いくつかの重要な画像属性を示します。
(0018, 0050) Slice Thickness：画像の厚み（mm）
(0018, 0088) Spacing Between Slices：画像スライスの連続方向において、ある画像のボクセル中心から、対応する次の画像のボクセル中心までの間隔（mm）
(0020, 0032) Image Position (Patient)：画像の左上隅の x, y, z 座標
(0020, 0037) Image Orientation (Patient)：患者を基準とした画像の最初の行と最初の列の方向余弦。x, y, z 軸のそれぞれの行の値と、x, y, z 軸のそれぞれの列の値
(0028, 0002) Samples per Pixel：ピクセルサンプル数（グレースケールなら1、カラーなら3）
(0028, 0004) Photometric Interpletation：ピクセルデータのタイプ（MONOCHROME2、RGBなど）。
(0028, 0006) Planar Configuration：カラーピクセルのエンコードタイプ。RRR…GGG…BBB…なのか、RGBRGB…なのかを示す（前者は1, 後者は0）。
(0028, 0008) Number of Frames：一連のフレーム（要するに動画）に含まれる画像の枚数。
(0028, 0010) Rows：行数
(0028, 0011) Columns：列数
(0028, 0030) Pixel Spacing：ピクセル（ボクセル）のx, yサイズ（値の順番は、row(y), column(x)）（mm）
(0028, 0100) Bits Allocated：割り当てビット（読み込まれるときに確保されるメモリ）
(0028, 0101) Bits Stored：格納ビット（ピクセルが表現されているデータ量）
(0028, 0102) High Bit：上位ビット（割り当てビットの中でピクセルが利用する最上位ビット位置。一般的に、Bits Stored - 1で表される。）
(0028, 0103) Pixel Representation：ピクセル値が符号なし（Unsigned）か符号つき（Signed）か（符号なしなら0、符号ありは1）
(7FE0, 0010) Pixel Data：OB, OWなピクセルデータ（8/16 bitのグレースケールまたはカラー画像）
(7FE0, 0008) Float Pixel Data：OFなピクセルデータ（32 bit グレースケール）
(7FE0, 0009) Double Float Pixel Data：ODなピクセルデータ（64 bit グレースケール）
これらの属性は、DICOMのピクセル関連タグのほんの一部に過ぎませんが、他の画像フォーマットを扱ったことのある方なら、DICOMの完成度の高さをご理解いただけると思います。
例えば、(0028, 0030)はピクセルの物理的な寸法を知ることができます。例えば、CT 画像のピクセルが 0.54（縦; y, Row）×0.59（横; x, Column） mmであることが分かれることで、画像から物理的な測定を行うことが可能になります。
縦（y）、横（x）の値には順序があり、[Row, Col] （[縦（y）, 横（x）]）の並びで属性に格納されています。
Pixel Spacing、Spacing between Slices（画像間の間隔※ギャップではなくボクセル間距離）は、画像オブジェクトの正しいサイズを計算でき、精巧な3D再構成に利用されます。
Image Position (Patient)、Image Orientation (Patient)は、画像の位置を検査データ内で共有するために役立ちます。例えば、DICOMビューワで、複数の画像シリーズを開いて、画像送りをすると、画像送りをしていない画像上に、画像送りをしている画像の面の位置が表示されたりしますよね。あれは、これらのタグから位置を算出しています（もちろん、位置の計算時はPixel SpacingやSpacing between Slicesが必要です）。具体的な計算方法は、画像再構成の解説で行います。
DICOMは、他の画像フォーマット（一般的なJPEGなど）にはない、画像データおよび関連するすべてのパラメータを保存するためのサポートをしています。これが、医療用画像処理におけるDICOMの成功の理由でしょう。
よく、医用AI開発時に、DICOM画像を他の「一般的な」フォーマット（JPEGやPNGなど）でエクスポートして、学習データを集めている人がいます。この方法は、DICOMを扱わなくてよくなるという利点はありますが、同時に、重要な属性データが失われます。後々、画像に関連する情報が必要になる可能性がある場合は、直接DICOMで扱うことを勧めます。
さて、属性云々ではなく、単に、画像をJPEGなどで圧縮してデータを軽くしたいと考える人は多いでしょう。DICOMはこの方法を提供しています。
DICOMは、JPEGやその他の圧縮方法でエンコードされたピクセルデータをDICOMオブジェクトとして内部でサポートします。なので、JPEGなDICOMが作れます。だからといって、このファイルをコンピュータへエクスポートしたら、「Image.jpg」というファイルができるわけではありません。あくまで、画像オブジェクトがJPEG形式でエンコードされた「DICOMデータ」を作ることができます。こうすることで、他の属性データを犠牲にすることなく、DICOMオブジェクト内の (7FE0,0010) Pixel Data 属性のピクセル・バッファを圧縮します。
この画像圧縮については別の機会に見てみましょう。
以上でDICOMビットマップの概要の説明を終わります。
Stay Visionary
この記事が気に入ったらサポートをしてみませんか？