标签: dicom

如何识别dicom图像是否采用压缩格式？而且还想知道如何读取压缩图像的像素数据？

我正在尝试从标准尺寸(512 x 512或256 x 256)的numpy阵列创建一个新的dicom图像.看起来这应该是直截了当的,我已经调整了我的代码来自http://code.google.com/p/pydicom/source/browse/source/dicom/examples/write_new.py,它似乎执行相同的进程,但是当我保存文件时,我无法在RadiAnt或MicroDicom中查看它.

import dicom, dicom.UID
from dicom.dataset import Dataset, FileDataset

def write_dicom(pixel_array,filename):

    file_meta = Dataset()
    ds = FileDataset(filename, {},file_meta = file_meta,preamble="\0"*128)
    ds.PixelData = pixel_array.tostring()
    ds.save_as(filename)
    return

if __name__ == "__main__":
    import numpy as np
    pixel_array = np.tile(np.arange(256).reshape(16,16), (16,16)) * 4
    write_dicom(pixel_array,'pretty.dcm')

这种传输语法中的数据是如何组织的？标准说明:

此传输语法适用于整个DICOM数据集的编码.首先根据第A.2节中规定的规则对整个数据集进行编码.然后使用Internet RFC 1951中定义的"Deflate"算法压缩整个字节流.

最初我认为这意味着整个DICOM文件本身都是gzip压缩.但是如果整个文件被gzip压缩,包括包含识别传输语法的头,那么解析器/查看器如何能够读取传输语法以知道它被gzip压缩？

从给定这种类型文件的查看器的角度来看,它如何知道这种传输语法？寻找GZIP标题？

是否有使用此传输语法的公开示例图像？

我希望使用JavaScript提取,然后显示DICOM文件中的图像数据.我想知道是否有人知道任何框架或工具来帮助我这样做.提前致谢.

我不是一个经验丰富的程序员,只需要在我的VS2010项目中添加一个DICOM查看器.我可以在Windows窗体中显示图像,但无法弄清楚如何更改窗口中心和宽度.这是我的脚本:

DicomImage image = new DicomImage(_filename);
            int maxV = image.NumberOfFrames;
            sbSlice.Maximum = maxV - 1;
            image.WindowCenter = 7.0;
            double wc = image.WindowCenter;
            double ww = image.WindowWidth;

            Image result = image.RenderImage(0);
            DisplayImage(result);

那没起效.我不知道这是不是正确的方法.

我想弄清楚DICOM图像位置(0020,0032)是绝对坐标还是我所拥有的任何切片方向的坐标？

例如,我有两个平面,矢状和冠状平面与来自DICOM标头的(x,y,z)形式的相应图像位置(mm)交错.我的问题是,与冠状面的(x,y,z)坐标在同一3D空间中的矢状平面的(x,y,z)坐标,或者是仅对该平面特定的图像位置值.

那么,图像位置是基于某个绝对原点引用还是针对每个特定图像方向进行了更改？

非常感谢!

几年前我写了一个jpeg压缩器/解压缩器,它可以处理无损和有损的jpeg文件.它运行良好,但并不总是正确解码DICOM文件中的jpeg流.

我很了解jpeg,但我对DICOM知之甚少.DICOM中的无损jpeg不可能符合jpeg ISO标准.必须进行一些修改,硬编码,或者通过jpeg文件流之外的DICOM文件中的某个参数进行修改.

我的代码在大多数示例DICOM文件(compsamples_jpeg.tar)上都失败了:ftp: //medical.nema.org/MEDICAL/Dicom/DataSets/WG04/

这是当我解码这个集合中的第一个无损jpeg(IMAGES\JPLL\CT1_JPLL)时会发生什么:

dicom解码图像

左图像是从我的代码渲染的,右边是由在线DICOM阅读器呈现的:www(点)ofoct(点)com(斜杠)查看器(斜杠)dicom-viewer-online(点)html

(x)MedCon是一个开源的DICOM读取器,它与我的代码完全相同,所以我不是唯一有这个问题的人.xmedcon dot sourceforge dot net

我已经逐字节地阅读了这个jpeg流,绘制了霍夫曼树并用铅笔和纸计算了霍夫曼代码,我的代码完全按照它应该做的去做.这是霍夫曼代码:

• 0 00
• 4 01
• 3 100
• 5 101
• 1 1100
• 2 1101
• 6 1110
• 7 11110
• 8 111110
• 9 1111110
• 12 11111110
• 11 111111110
• 10 1111111110
• 15 11111111110

这是SOS标记之后的压缩数据:

• ff 00 de 0c 00(ff为填充字节后的00)
• 11111111 11011110 00001100 00000000
• 11111111110 si = 15
• 111100000110000 diff = 30768

在线查看器说第一个像素值是-3024.如果这是正确的,第一个diff值应该是-3024,但事实并非如此.

在此之后,我的代码正确地解码了大约2/5的图像,但随后解码了一个非常不准确的diff值:

• d2 a1 fe ff 00 e0(ff为填充字节后的00)

• 1010111 10100001 11111110 11111111 11100000

• 101 si = 5

• 01111 …

我的理解是，两次连续的 DIMSE 通信（请求或响应）之间的超时时间是 DIMSE 超时。

因此，在MWL操作中，MWL SCU（建立连接和关联）发送MWL CFind请求。SCP 应在 DIMSE 超时到期之前发送第一个响应。同样，每个下一个响应都应在 DIMSE 超时到期之前由 SCP 发送。

类似地，对于 CStore 操作，CStore SCU 发送请求，SCP 应在 DIMSE 超时到期之前做出响应。对于在该关联上发送的每个实例都应该发生这种情况。

我的理解正确吗？

如果是，那么对于需要很长时间（超过 DIMSE 超时设置）才能完全传输的大型实例，这如何工作？

例如，CStore SCU 正在推送一个实例（比如大尺寸多帧），需要 1000 毫秒才能完全传输。SCP 和 SCU 上的 DIMSE 超时均设置为 500 毫秒。这里的预期结果是什么？SCP或SCU会遇到DIMSE超时吗？

I have to convert some files which come by default as .dcm to .png, I've found some code samples to achieve that around here but the end results are too bright. Could anybody have a look at this, please?

 def convert_to_png(file):
    ds = pydicom.dcmread(file)

    shape = ds.pixel_array.shape

    # Convert to float to avoid overflow or underflow losses.
    image_2d = ds.pixel_array.astype(float)

    # Rescaling grey scale between 0-255
    image_2d_scaled = (np.maximum(image_2d,0) / image_2d.max()) * 255.0

    # Convert to uint
    image_2d_scaled = …

我正在使用 fo-dicom 库开发模态工作列表客户端。

我不清楚以下与[ Referenced SOP Instance UID (0008,1155)]相关的事情。

1. 什么是引用的 SOP 实例 UID？
2. 整个系列的参考 SOP 实例 UID 是否相同？
3. 我在一些示例图像中看到了 2 个引用的 SOP 类 UID；为什么？

场景一：

我正在尝试检索模态工作列表来为所请求的研究创建一些图像系列。我必须创建捕获的图像序列以将“已完成”通知发送到 MPPS 服务器。模态工作列表的 fo-dicom 示例在创建完整的图像序列以向 MPPS 发送“已竞争”通知时包括引用的 SOP 类/实例 UID。我的问题是这个引用的 SOP 类/实例 UID 是什么？

场景2：

除此之外，我还发现了一些示例 DICOM 文件系列，每个图像内容引用了 SOP 类/实例 UID 两次，并且与系列相同。

这些引用的 SOP 类/实例 UID 相同还是不同？

以下是 DICOM 文件内容示例 两次引用 SOP 类/实例 UID：