为什么某些CR/DR图像打开后是反色的？

为什么某些CR/DR图像打开后是反色的？

手工

本帖最后由 杜飞 于 2016-2-2 13:10 编辑        常常碰到这样一个问题，一些CR/DR图像打开后，默认就是反色的，只有手工反色后才能正常阅片。这是什么原因呢？      为了正常显示DICOM影像，我们除了需要正确读取Pixel Data, 我们还需要正确读取[0028,0004]  Photometric Interpretation。Photometric Interpretation告诉我们如何去显示Pixel Data，比方说，Monochrome2，Monochrome1说明这是一个灰图，如果是RGB， Palette Colour等就是彩图。回到上面那个问题，一般的灰图都是使用Monochrome2，Pixel值越大，图像就越白。但是，部分的CR，DR设备会采用Monochrome1， Pixel值越大，图像就越黑。所以，某些CR，DR图像打开后是反色的，有两种原因： 1）图像文件中的[0028,0004]  Photometric Interpretation设置错误了，将Monochrome1设置成了Monochrome2，或者相反。一般来说，设备上发过来的DICOM影像都没有问题，但是有的图像是经过第三方软件处理了，导致了[0028,0004]  Photometric Interpretation设置错了，或者该属性值丢失了。 2）DICOM Image的查看软件没有正确读取[0028,0004]值，对于所有的灰图都使用Monochrome2来解析和显示，这就导致部分Monochrome1的CR\DR图像默认反色了。         我们经常碰到的Photometric Interpretation有以下几种类型： Monochrome2 一般的灰图都采用这种，Pixel值越大，图像就越白。 Monochrome1, 只有部分CR, DR图像使用，Pixel值越大，图像就越黑。 Palette Colour, 一般用于彩超图像，每个像素占用8位或者16位，调色板保存在[0028,1201]RedPaletteColorLookupTableData, [0028,1202]GreenPaletteColorLookupTableData, [0028,1203]BluePaletteColorLookupTableData的属性中。 RGB, 这是最常用的彩图格式。 YBR_FULL  另外一种彩图格式， 存储格式为Ｙ(Luminance 亮度)， B(Blueness 蓝色)， R（Redness, 红色） YBR_FULL_422 一般用于JPG有损压缩格式的彩图，每两个像素共同使用32位，每一个像素都有自己的Ｙ(Luminance 亮度)，但是共享相同的B(Blueness 蓝色)， R（Redness, 红色）。所以，它的像素值存储方式是：YYBR,YYBT,YYBR YBR_RCT 用于JPEG 2000无损压缩彩图，Reversible Color Transformation, 可逆色彩变换。 Y = (R+2G+B)/4，  CB = B-G  ， CR = R - G G = Y - (CR+CB)/4 ,  R = CR + G,  B = CB + G YBR_ICT 用于JPEG 2000有损压缩彩图 Irreversible Color Transformation, 不可逆色彩变换。 Y = + .29900R + .58700G + .11400B CB = - .16875R - .33126G + .50000B CR = + .50000R - .41869G - .08131B 好了，基本上常见的Photometric Interpretation类型都已经介绍完了，这下我们可以愉快地解析DICOM影像中Pixel Data，正确地显示图像了。但是，现实是残酷的，你会发现还有很多图像还是不能正常显示。比方说，理论上，所有的DICOM影像文件中都必须有Photometric Interpretation属性并且不能为空？但是有的问题影像就缺失了这一项，如何处理？再比方说，在对彩图压缩的时候，Photometric Interpretation的类型需要根据压缩传输语法的类型进行修改。但是，有的程序忽视了这一点，导致我们需要根据传输语法对Photometric Interpretation的类型进行修正。再比方说，某产商的MR Perfusion文件采用了Monochrome1类型，但是有彩色的Palette信息，如何处理？等等。这些情况很常见，你可以说这些图像不符合标准，所以不能正确地打开显示。但是，客户不会听你的这个解释的，他们会说设备上可以正常显示，某某第三方Viewer可以正常显示，为什么你们的Viewer就不能正常显示？所以，我们需要加入许多特殊处理逻辑来处理这些特殊的问题影像，这样才能保证Viewer足够通用，足够健壮，能够正确显示尽可能多的影像。这是一个不断碰到问题影像，不断解决问题，一步步积累沉淀的过程。一个产品化的Viewer需要通过大数据量的问题影像集的检验才能够成熟