如何正确存储来自 MOVE 的 dicom 像素数据？答案

【问题标题】：How can i CSTORE pixel data of dicom from CMOVE properly?如何正确存储来自 MOVE 的 dicom 像素数据？
【发布时间】：2020-02-12 02:14:34
【问题描述】：

我有 1 个正在运行的服务器用于处理 C-Move，2 个正在运行的服务器用于处理 C-Store 和远程 pacs 服务器（GEPACS）

当我尝试从远程 pacs 到 C-Store 处理程序的 C-Move 命令时，1 个服务器（py-netdicom）已构建并正确保存文件，而 1 个服务器（go-netdicom）则没有。

所以在 go-netdicom 中有几个问题。我修复了代码可以处理十六进制。 go-netdicom 最初不支持它。这几乎解决了我的所有问题，但仍然无法正确存储像素数据。

例如，我从远程 pacs 的原始信号中获得了 9117252 字节，我自己保存了数据，但实际上它需要 18000000 字节（出错）。连CT图像都短了3次（得到了大约180000，但需要524288）

我认为引起的问题可能是像素数据的封装，但不确定。

有什么提示或帮助吗？

谢谢。

编辑 4：我知道了。link here

不知何故，C-STORE 命令有一种传输语法。此提供给 scp 类型（压缩或未压缩）的数据 scu 获取。但是我仍然不知道必须更改 go-netdicom 的哪个部分。我将删除“python”标签，因为这与 python 无关。

【问题讨论】：

对私有数据元素的引用与问题无关 - 最好删除 EDIT / EDIT2 / EDIT3 部分，因为它们只会混淆问题。关于 David Clunies 的帖子，您似乎走在了正确的轨道上 - 所有 DICOM 实体都必须协商他们都可以处理的传输语法，您可以在双方都进行配置。
MrBean// 多谢建议。我同意。转移语法将是这个问题的关键。但正如我所说，我真的不知道会改变哪一部分。我现在正在寻找“上下文管理器”。

标签： go compression dicom

【解决方案1】：

我找到了解决办法。

不知何故，GEPACS 发送特定的 JPEG 压缩传输语法。如果 go-netdicom 没有 TransferSyntaxUID 则选择 GEPAC 的第一个传输语法，它用于 JPEG 压缩。

当 transfersyntax 为空时，我只输入 bigendian 和 explicitvr（GEPACS 默认）。

它放在 contextmanager.go 第 101 行 AssociateRequest 的第 127 行

希望这个结果对某人有所帮助。

谢谢

【讨论】：

提示：BigEndian 传输语法已被弃用多年，我不会使用它。 Little Endian Explicit VR 应该几乎总是有效。
Implicit Little Endian 是 DICOM 的默认传输语法，所有符合 DICOM 的系统都必须支持（除了一些不太可能在这种情况下适用的例外情况）
@kritzel_sw: true - 虽然我还没有遇到任何不支持 Explicit Little Endian 的东西（因此“几乎总是”），并且 Explicit Little Endian 通常更容易处理（例如关于私有标签的VR），我通常更喜欢它。但你是对的......
谢谢评论。在我的情况下，默认的 TransferSyntaxUID 是“2.16.840.1.113709.1.2.2”，根据 GE 官员的说法，这是 ExplicitVRBigEndian。如果我错了，请告诉我。
显式 Big Endian 的传输语法 UID 为 1.2.840.10008.1.2.2。根据 GE 的 Centricity PACS 的 DICOM 一致性声明“2.16.840.1.113709.1.2.2”是一个名为“COMPRESS_EXPRESS”的私有 TS，并且“预计其他供应商的应用程序将忽略所有使用 COMPRESS_EXPRESS 传输语法提出的表示上下文。 ”。见这里：www3.gehealthcare.pl/~/media/documents/us-global/products/…

【解决方案2】：

这里的问题是 go-netdicom 使用 A_ASSOCIATE_RQ 中发送的第一个 PresentationContext（如您在最后一张图片中所见）。所以它接受“2.16.840.1.113709.1.2.2”，这是一种私有传输语法，它不在 DICOM 标准中，所以最后没有人可以管理 C-STORE。

如果您正在阅读此内容.. 可能您不使用 go-netdicom，但如果错误涉及传输语法“2.16.840.1.113709.1.2.2”，则问题可能相同，在 Centricity PAC 文档中说：“预计其他供应商的应用程序将忽略所有使用 GE Private Compress Express Transfer Syntax 提出的 Presentation Context"

这就是我们应该做的。我在 go-netdicom 中看到了 PR 列表，所以我认为它没有被维护，所以我将在此处发布 go-netdicom 的更改。我在 contextmanager.go 中进行了这些更改，效果非常好：

【讨论】：