我想创建一个应用程序来读写 DICOM 文件,而不使用任何第三方软件

发布于 2024-08-20 17:47:59 字数 63 浏览 3 评论 0原文

我想创建一个应用程序来读写 DICOM 文件,而不使用任何第三方软件 我怎样才能做到这一点? 有人可以帮助我吗?

I want to create an application to read and write DICOM files without using any third party software
How can I do that?
Can any one help me?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

二智少女猫性小仙女 2024-08-27 17:47:59

“在我的项目中,我只需要更新像素数据。所以处理起来并不太难。我只是解析 DICOM 文件直到达到像素数据,然后用我自己的数据替换它。结果就成功了。 ”

尽管有相当多的研究应用程序与您所做的事情相同,但它恰恰是The Wrong Thing To Do(TM)。为什么这是一个不好的做法? DICOM 图像应该由其 SOP 实例 UID 唯一标识。当您获取现有 DICOM 图像并替换像素数据,同时保持原始标头信息不变时,您将创建两个共享相同主键的数据对象。

考虑一下如果您拍摄此图像并将其发送到已经拥有原始图像副本的 DICOM 存储 SCP,会发生什么情况。存储 SCP 必须调用冲突解决程序,因为它不能有两个具有相同 UID 的 SOP 实例。收到新映像后,存储 SCP 检测到新映像与现有映像具有相同的 UID,并且 SCP 所需的行为未明确定义。存储 SCP 可以将您的新图像视为原始图像的重新传输并忽略您的新图像,也可以将其视为原始图像的校正版本并用新图像替换原始图像,或者它可以放弃并承认它完全不知道如何处理这个新图像,并将其扔进等待区域,并要求人类与应用程序交互来决定如何处理这两个图像。作为新图像的创建者,您无法知道或控制存储 SCP 收到您的新图像时的行为。

创建新映像时,您至少需要生成新的有效 SOP 实例 UID。您的图像类型也应该是 DERIVED\SECONDARY 类型之一,因为它是后处理图像,而不是由模态生成的主要采集。您还应该查看原始标头中存在的其他 DICOM 标签,并认真考虑它们是否准确地描述了您创建的新图像。

"I my project, I need only to update pixel data. So it was not too tough to handle. I just parsde the DICOM file till I reach pixel data, and then I replaced the same with my own data. and It become success."

Even though there are quite a few research applications that do the same thing that you've done, it is precisely The Wrong Thing To Do(TM). Why is this such a bad practice? DICOM images are supposed to be uniquely identified by their SOP Instance UIDs. When you take an existing DICOM image and replace the pixel data, leaving the original header information unaltered, you are creating two data objects that share the same primary key.

Consider what will happen if you take this image and send it to a DICOM Storage SCP that already has a copy of the original image. The Storage SCP has to invoke a conflict resolution procedure because it can't have two SOP Instances with the same UID. Upon receipt of your new image, the Storage SCP detects that the new image has the same UID as an existing image and the required behavior of the SCP is not well defined. The Storage SCP can treat your new image as if it is just a retransmission of the original image and ignore your new image, or it can treat it as if it is a corrected version of the original image and replace the original image with your new image, or it can give up and admit that it has absolutely no idea what to do with this new image and throw it into a holding area and require a human being to interact with the application to decide what to do with the two images. You, the creator of the new image, have no way of knowing or controlling what the behavior of the Storage SCP will be when it receives your new image.

At a minimum, you need to generate a new valid SOP Instance UID when you create a new image. Your image type should also be one of the DERIVED\SECONDARY types because it is a post-processed image, not a primary acquisition generated by the modality. You should also look at the other DICOM tags present in the original header and seriously consider whether they accurately describe the new image that you've created.

山色无中 2024-08-27 17:47:59

这几乎意味着从DICOM 标准开始并编写大量代码。

That would pretty much mean starting from the DICOM standard and writing a lot of code.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文