[医疗信息化][DICOM教程]1.使用Java的DICOM基础-理解DICOM文件-DICOM Basics using Java - Making Sense of the DICOM File

时间:2022-07-22
本文章向大家介绍[医疗信息化][DICOM教程]1.使用Java的DICOM基础-理解DICOM文件-DICOM Basics using Java - Making Sense of the DICOM File，主要内容包括其使用实例、应用技巧、基本知识点总结和需要注意事项，具有一定的参考价值，需要的朋友可以参考一下。

[医疗信息化][DICOM教程]1.使用Java的DICOM基础-理解DICOM文件-DICOM Basics using Java - Making Sense of the DICOM File

使用Java的DICOM基础-理解DICOM文件

介绍

这是我有关DICOM标准的系列文章的一部分。在我们开始本教程之前，请快速浏览一下我之前的文章“ DICOM标准简介”，以简短，快速地介绍该标准。请注意，本教程假定您知道Java（或任何等效的面向对象的语言，如C＃或C ++）。

我以为我将以DICOM文件格式的非常高级的介绍开始有关DICOM的编程教程系列。请方便地使用此链接的官方DICOM标准文档，因为我在本教程中介绍的许多内容都在此处进行了详细说明。

正如您在我的入门DICOM教程中所回忆的那样，DICOM文件通常使用标签的概念（将在后面进行解释）像其他图像格式（例如TIFF）一样，在同一文件中包含图像数据和有关患者的数据。但是，以DICOM词典的形式存储在DICOM文件中的信息比其他标准结构化和多样化得多。该词典（请参阅本文档的第23页，以了解其全面程度），其中包含数千个标签，可帮助我们对信息进行编码，例如何时何地拍摄图像，其所属人物，转介医师甚至诊断信息以及核心图像数据。这样可以最大程度地减少将某些关键医疗信息分配给错误患者的风险。

大多数DICOM文件（有时带有'.dcm'扩展名-参见本文的脚注）通常包含图像数据，有时甚至可能包含多个图像（或在DICOM中通常称为“帧”）以启用以下功能：称为电影循环，使DICOM观看者可以将整个图像序列可视化为电影。但是，DICOM文件并不一定像大多数人所想的那样是关于图像的，它还可以用于存储其他信息，例如报告，ECG信号甚至音频（我们将在后面介绍）。

“写作是大自然的一种让您知道自己的想法多么草率的方式”〜理查德·金登（Richard Guindon）

在以下各节中，我们将首先了解DICOM文件的基本结构（和语法），该文件使可能在不同操作系统和设备上运行的应用程序可以轻松地相互交换图像和与图像有关的信息。然后，我们将使用免费提供但功能非常强大的DICOM工具箱，称为PixelMed Java DICOM工具箱。来解析实际的DICOM文件，并查看其中的内容与我们所涵盖的概念有关，从而有助于加深我们对所涵盖概念的理解。请注意，DICOM文件比我在这里讨论的要多得多，但是对于像我这样的大多数使用工具箱或库来处理DICOM文件的开发人员来说，本教程和后面的其他信息应包括足以快速启动并运行。但是，如果您有兴趣从头开始编写自己的DICOM解析器，则应详细阅读本文档。

DICOM文件内部的外观

每个DICOM文件都由三个主要部分组成，现在我们来看一下每个部分在整体方案中所扮演的角色。

第一部分，文件头，由128字节的文件前导码和4字节的前缀组成。这种方法在您可能已经看到/使用过的许多其他图像标准（例如TIFF）中非常普遍。4字节前缀由大写字符“ DICM”组成（注意，它不是“ DICOM”，而是“ DICM”）。该标准不关心前导码应如何构造以及应在其中存储什么。根据我的理解，使用文件序言是为了确保处理应用程序像处理其他几种现有图像文件格式一样处理DICOM文件的兼容性或一致性。该标准并不关心您在其中存储的内容或使用方式。因此，从理论上讲，如果您选择解析DICOM文件，则您的应用程序可以完全跳过此数据。

在查看DICOM文件的下一部分之前，需要先谈谈传输语法的概念及其在DICOM标准中的作用。如果您从我以前的教程中回想起，即使设备运行在不同的操作系统上，DICOM标准也使设备之间能够相互传输信息。不同的操作系统和设备在存储二进制数据时遵循不同的格式来存储数据，例如字节顺序。由于需要大量网络来交换由CT或MR等扫描方式生成的大图像，因此该标准还规定在必要时/在使用压缩时交换图像数据。在我的DICOM入门教程中，我们还了解了隐式和显式VR编码也是如此。必须首先理解并达成所有三个标准（VR编码的类型，字节排序的类型和所使用的压缩），以确保两个交换信息的DICOM系统在它们之间的任何通信期间都能相互理解。传输语法是一组编码规则，可通过使用UID来帮助指定此条件，我们在DICOM入门教程中也了解到。例如，隐式VR小端（由UID值1.2.840.10008.1.2表示），显式VR小端（值-1.2.840.10008.1.2.1），显式VR大端（值-1.2.840.10008 .1.2.2）和JPEG无损（值-1.2.840.10008.1.2.4.57）是DICOM处理可用的一些传输语法。在我的DICOM系列的后续教程中讨论图像像素数据处理时，我将更详细地介绍这些内容。

既然我们已经了解了传输语法的简要含义（还有更多内容，包括演示上下文，我将在以后的教程中介绍），让我们看一下文件的下一部分，即文件元信息标头。本节紧随文件头之后，由一个数据集组成，该数据集由一系列标记信息（称为“ Dicom元素”）组成，该序列指定诸如传输语法（如上所解释）之类的详细信息以及有关设备或实现的其他信息创建此文件的对象以及为谁创建此信息的对象（接收应用程序）。有关详细信息，请参见本文档的第32页。

本节之后的内容是DICOM文件的第三部分也是最后一部分，它是数据对象。DICOM文件的此部分也以数据集的形式指定，该数据集由一系列标签组成，这些标签又可以嵌套并自身携带其他子标签。这些标签有助于携带有关SOP实例的信息（请参阅我的入门教程对于SOP意味着什么），例如研究，系列，其所属的患者以及其他有关图像的细节，例如图像像素数据，扫描位置数据等。研究，系列和患者信息通常用于在大多数PACS系统中为图像建立索引，以便更快地检索数据。我的下面的插图有望提供整个文件结构的概要，还显示了各个DICOM元素（每个元素包括标签和相关信息）如何成为整个结构的一部分。

例如，在上面的插图中所示的数据对象部分中的三个DICOM元素的第一个中，“（0008，0070）”表示属于组号0008的标签，其属性号为0070，“ LO”表示数据类型或值表示（VR），DICOM称之为它（LO表示长字符串数据类型），“ PHILIPS”是标记的实际值，“＃8”有助于指定值8的长度（请注意，DICOM始终使用偶数个字符对文本进行编码，因此即使PHILIPS值只有7个字符长，也会使用一个额外的填充字符-稍后将对此进行详细说明，1表示值的多重性此处（可以重复一些数据），“制造商”是DICOM词典中指定的实际标签名称。组合的组和属性编号，VR，值，值多重性和标签名称称为DICOM元素。自DICOM字典以来（请参阅第23页及以后）隐式定义与每个标签关联的VR，VR是多余的，有时会被省略。尽管如此，一种常见的做法和建议是在将DICOM对象序列化为文件或在网络上交换DICOM信息时明确指定VR。当我在以后的教程中更详细地讨论传输语法时，将更详细地介绍隐式传输语法（省略VR）和显式传输语法（其中VR与标记一起指定）。现在，我们可以更好地了解什么是IOD（信息对象定义）。让我们继续。

这些术语在DICOM中到底意味着什么-SCU，SCP，SOP和IOD？

DICOM定义了服务和服务使用或对其进行操作的数据的概念。服务的示例可以是CT存储服务，它负责将从CT模态生成的图像存储到PACS服务器。服务分为两部分，服务的使用者也称为服务类用户或SCU，服务的提供者也称为服务类提供者或SCP。例如，在CT存储操作中，生成图像的模态用作C存储SCU并将要存储的数据传输到PACS服务器播放的C-Store SCP。在DICOM标准中，服务类和那些服务所涉及的对象的组合称为服务对象对或SOP。SOP的抽象定义称为SOP类，它们由唯一的标识符（称为UID）定义，我稍后将介绍（请参阅此链接以获取SOP列表）。因此，由1.2.840.10008.5.1.4.1.1.2的SOP类UID标识的SOP CT图像存储可帮助识别这是CT图像存储操作。在所涉及的机器之间进行此操作期间，会交换命令（称为DIMSE（我将在后面介绍）以及一些数据，其中包括图像像素信息以及其他识别信息，例如患者，研究，系列和设备信息。这些操作的具体细节一起被称为SOP实例。这些SOP实例中的每个实例也由唯一标识符标识，但由负责传输它们的应用程序生成。这些标识符称为SOP实例UID。此SOP涉及的实际数据由IOD（信息对象定义）定义，该IOD指定了要成功完成处理需要呈现哪些DICOM模块（模块本质上是DICOM元素组）。

IOD对象本身分为称为信息实体（缩写为IE）的子组，而信息实体又分为信息模块的小组。信息模块由我们已经看到的一系列DICOM元素组成。DICOM定义了有关强制性模块，有条件性模块和可选模块的规则。IOD本身分为归一化IOD和复合IOD。标准化IOD仅表示与一个实体有关的数据，而复合IOD表示来自彼此相关的各种实体的混合物的数据，如下图所示。总之，这本质上是DICOM信息模型的整体结构。综上所述，您现在将看到，到目前为止，我们处理的任何DICOM文件实际上都是IOD（信息的序列化版本）的实例，该IOD还在任何成像工作流程中在两台机器之间传输。在我们正在研究的情况下，该操作有助于将CT模态生成的图像存储到PACS服务器上。DICOM IOD和编码要比这里介绍的更多，但是在讨论创建DICOM文件和目录时，我们将处理这些领域。我不想让你无聊

PixelMed Java DICOM工具包-快速概述

为了说明我计划在本教程系列中涵盖的DICOM的许多方面，我将使用一个称为PixelMed Java DICOM Toolkit的免费可用且功能强大的DICOM工具包。这是一个完全独立的DICOM工具包，为DICOM文件和目录处理，图像查看以及与DICOM网络相关的操作提供功能。该工具包对于商业或非营利性用途都是完全免费的。它有充分的文档记录，还为用户提供了一个小型讨论论坛和一个邮件列表。该工具包中包含的功能列表非常全面。请记住，在我的教程中使用此工具包绝不表示我对实现生产应用程序的官方认可。每种情况都是独特的，只有您最终处于最佳位置才能做出决定。本文也不是该工具包的教程，我在这里的重点只是将DICOM理论与实际（尽管简单）的实现方式联系起来。因此，如果您的目标是学习如何使用PixelMed库，我鼓励您访问其网站或查看讨论论坛或StackOverflow讨论页面以寻求帮助。

在我们开始之前...

与之前的编程示例非常相似，我将使用最简单的最少代码和方法来帮助说明本教程中介绍的概念。这意味着我在这里编写的代码最适合于简单地显示我试图解释的概念，并且不一定是在现实生活中和生产应用程序中部署的最有效的代码。

首先，您需要在计算机上配置一些东西，包括Java开发环境以及PixelMed工具包，然后才能运行示例（如果您想自己尝试一下）。

  1. 从此处下载并安装Eclipse Java IDE （或使用您喜欢的任何其他IDE）
  2. 从此处下载PixelMed工具包库
  3. 确保Java项目的类路径中包含PixelMed.jar库（某些示例可能需要其他运行时依赖项，例如可以在PixelMed软件下载中找到的JAI Image IO工具。寻找一个名为pixelmedjavadicom_dependencyrelease.YYYYMMDD.tar的tar压缩文件。 .bz2或类似名称）
  4. 您可以在GitHub上找到本教程中使用的源代码
  5. 您可以下载更多的DICOM图像从这个网站，如果你想和

列出要控制台的DICOM文件的各种标签

使用PixelMed工具包读取和提取DICOM标签信息非常简单。此操作仅需要两个类，即AttributeList和Attribute。该AttributeList中的类提供了读取（和写入）整个DICOM对象从文件或流的属性列表的方法。此类的构造函数采用您要处理的DICOM文件的路径。另一方面，Attribute类负责读取和写入DICOM属性。下面显示了使用这些类来显示我们感兴趣的DICOM元素。

    package com.saravanansubramanian.dicom.pixelmedtutorial;

    import com.pixelmed.dicom.Attribute;
    import com.pixelmed.dicom.AttributeList;
    import com.pixelmed.dicom.AttributeTag;
    import com.pixelmed.dicom.TagFromName;

    public class DumpDicomTagsToConsole {

        private static AttributeList list = new AttributeList();

        public static void main(String[] args) {
            String dicomFile = "D:\JavaProjects\Sample Images\MR-MONO2-16-head";
            try {
                list.read(dicomFile);

                System.out.println("Study Instance UID:" + getTagInformation(TagFromName.StudyInstanceUID));
                System.out.println("Series Instance UID:" + getTagInformation(TagFromName.SeriesInstanceUID));
                System.out.println("SOP Class UID:" + getTagInformation(TagFromName.SOPClassUID));
                System.out.println("SOP Instance UID:" + getTagInformation(TagFromName.SOPInstanceUID));
                System.out.println("Transfer Syntax UID:" + getTagInformation(TagFromName.TransferSyntaxUID));

            } catch (Exception e) {
                e.printStackTrace(); //in real life, do something about this exception
            }
        }

        private static String getTagInformation(AttributeTag attrTag) {
            return Attribute.getDelimitedStringValuesOrEmptyString(list, attrTag);
        }

    }

运行以上代码的输出如下所示：

Study Instance UID:1.2.840.113619.2.1.3352.2053053415.834484316
Series Instance UID:1.2.840.113619.2.1.3352.1136944889.4.834485379
SOP Class UID:1.2.840.10008.5.1.4.1.1.4
SOP Instance UID:1.2.840.113619.2.1.3352.1015047400.4.3.834485381
Transfer Syntax UID:1.2.840.10008.1.2

将所有DICOM文件的标签列出到控制台

列出DICOM文件的全部属性很好，但是有时候，您只是想只显示DICOM文件中包含的特定标签，包括组和属性号，值表示（VR），值，值长度，值多重性和我在本教程前面介绍的标签名称信息。通过使用PixelMed库中包含的AttributeList类的toString方法，可以轻松实现此过程。该操作的代码说明如下所示。

    package com.saravanansubramanian.dicom.pixelmedtutorial;

    import com.pixelmed.dicom.AttributeList;

    public class DumpDicomFileContentsToConsole {

        public static void main(String[] args) {
            String dicomFile = "D:\JavaProjects\Sample Images\MR-MONO2-16-head";
            try {
                AttributeList list = new AttributeList();
                list.read(dicomFile);
                System.out.println(list.toString());

            } catch (Exception e) {
                e.printStackTrace();
            }
        }
    }

运行以上代码的输出如下所示：

(0x0002,0x0000) FileMetaInformationGroupLength VR=<UL> VL=<0x4> [0xba]
(0x0002,0x0001) FileMetaInformationVersion VR=<OB> VL=<0x2> []
(0x0002,0x0010) TransferSyntaxUID VR=<UI> VL=<0x12> <1.2.840.10008.1.2 >
(0x0002,0x0012) ImplementationClassUID VR=<UI> VL=<0x18> <1.2.276.0.7230010.3.1.2 >
(0x0002,0x0013) ImplementationVersionName VR=<SH> VL=<0x10> <OFFIS-DCMTK-301 >
(0x0008,0x0000) VR=<UN> VL=<0x4> [B@681a9515
(0x0008,0x0008) ImageType VR=<CS> VL=<0x10> <ORIGINALPRIMARY>
(0x0008,0x0016) SOPClassUID VR=<UI> VL=<0x1a> <1.2.840.10008.5.1.4.1.1.4 >
(0x0008,0x0018) SOPInstanceUID VR=<UI> VL=<0x30> <1.2.840.113619.2.1.3352.1015047400.4.3.834485381>
(0x0008,0x0020) StudyDate VR=<DA> VL=<0xa> <1996.06.11>
(0x0008,0x0021) SeriesDate VR=<DA> VL=<0xa> <1996.06.11>
(0x0008,0x0023) ContentDate VR=<DA> VL=<0xa> <1996.06.11>
(0x0008,0x0030) StudyTime VR=<TM> VL=<0x8> <09:11:56>
(0x0008,0x0031) SeriesTime VR=<TM> VL=<0x8> <09:29:39>
(0x0008,0x0033) ContentTime VR=<TM> VL=<0x8> <09:29:41>
(0x0008,0x0060) Modality VR=<CS> VL=<0x2> <MR>
(0x0008,0x0070) Manufacturer VR=<LO> VL=<0x12> <GE MEDICAL SYSTEMS>
(0x0008,0x0080) InstitutionName VR=<LO> VL=<0x20> <PALO ALTO MEDICAL FOUNDATION MRI>
(0x0008,0x0090) ReferringPhysicianName VR=<PN> VL=<0xa> <Anonymized>
(0x0008,0x1010) StationName VR=<SH> VL=<0x8> <MROCOC0 >
(0x0008,0x1030) StudyDescription VR=<LO> VL=<0x4> <HEAD>
(0x0008,0x103e) SeriesDescription VR=<LO> VL=<0x6> <FLAIR >
(0x0008,0x1060) NameOfPhysiciansReadingStudy VR=<PN> VL=<0xa> <Anonymized>
(0x0008,0x1070) OperatorsName VR=<PN> VL=<0xa> <Anonymized>
(0x0008,0x1090) ManufacturerModelName VR=<LO> VL=<0xe> <GENESIS_SIGNA >
(0x0010,0x0000) VR=<UN> VL=<0x4> [B@681a9515
(0x0010,0x0010) PatientName VR=<PN> VL=<0xa> <Anonymized>
(0x0018,0x0000) VR=<UN> VL=<0x4> [B@681a9515
(0x0018,0x0010) ContrastBolusAgent VR=<LO> VL=<0x4> <NONE>
(0x0018,0x0020) ScanningSequence VR=<CS> VL=<0x2> <RM>
(0x0018,0x0021) SequenceVariant VR=<CS> VL=<0x4> <NONE>
(0x0018,0x0022) ScanOptions VR=<CS> VL=<0x16> <GRAPH_GEMSFCEDR_GEMS>
(0x0018,0x0023) MRAcquisitionType VR=<CS> VL=<0x2> <2D>
(0x0018,0x0024) SequenceName VR=<SH> VL=<0x6> <flair >
(0x0018,0x0025) AngioFlag VR=<CS> VL=<0x2> <Y >
(0x0018,0x0050) SliceThickness VR=<DS> VL=<0x8> <5.000000>
(0x0018,0x0080) RepetitionTime VR=<DS> VL=<0xc> <10002.000000>
(0x0018,0x0081) EchoTime VR=<DS> VL=<0xa> <159.500000>
(0x0018,0x0083) NumberOfAverages VR=<DS> VL=<0x8> <1.000000>
(0x0018,0x0084) ImagingFrequency VR=<DS> VL=<0xe> <63.8609400000 >
(0x0018,0x0085) ImagedNucleus VR=<SH> VL=<0x2> <H1>
(0x0018,0x0086) EchoNumbers VR=<IS> VL=<0x2> <1 >
(0x0018,0x0087) MagneticFieldStrength VR=<DS> VL=<0x6> <15000 >
(0x0018,0x0088) SpacingBetweenSlices VR=<DS> VL=<0x8> <6.000000>
(0x0018,0x0091) EchoTrainLength VR=<IS> VL=<0x2> <0 >
(0x0018,0x0093) PercentSampling VR=<DS> VL=<0xa> <100.000000>
(0x0018,0x0094) PercentPhaseFieldOfView VR=<DS> VL=<0xa> <100.000000>
(0x0018,0x0095) PixelBandwidth VR=<DS> VL=<0xa> <167.187500>
(0x0018,0x1020) SoftwareVersions VR=<LO> VL=<0x2> <04>
(0x0018,0x1050) SpatialResolution VR=<DS> VL=<0x12> <1.145833.859375 >
(0x0018,0x1088) HeartRate VR=<IS> VL=<0x2> <0 >
(0x0018,0x1090) CardiacNumberOfImages VR=<IS> VL=<0x2> <0 >
(0x0018,0x1094) TriggerWindow VR=<IS> VL=<0x2> <0 >
(0x0018,0x1100) ReconstructionDiameter VR=<DS> VL=<0xe> <220.0000000000>
(0x0018,0x1250) ReceiveCoilName VR=<SH> VL=<0x4> <HEAD>
(0x0018,0x1251) TransmitCoilName VR=<SH> VL=<0x4> <HEAD>
(0x0018,0x1312) InPlanePhaseEncodingDirection VR=<CS> VL=<0x4> <COL >
(0x0018,0x1314) FlipAngle VR=<DS> VL=<0x2> <90>
(0x0018,0x1315) VariableFlipAngleFlag VR=<CS> VL=<0x2> <N >
(0x0018,0x1316) SAR VR=<DS> VL=<0x8> <0.015446>
(0x0018,0x5100) PatientPosition VR=<CS> VL=<0x4> <HFS >
(0x0020,0x0000) VR=<UN> VL=<0x4> [B@681a9515
(0x0020,0x000d) StudyInstanceUID VR=<UI> VL=<0x2c> <1.2.840.113619.2.1.3352.2053053415.834484316>
(0x0020,0x000e) SeriesInstanceUID VR=<UI> VL=<0x2e> <1.2.840.113619.2.1.3352.1136944889.4.834485379>
(0x0020,0x0011) SeriesNumber VR=<IS> VL=<0x2> <4 >
(0x0020,0x0012) AcquisitionNumber VR=<IS> VL=<0x2> <1 >
(0x0020,0x0013) InstanceNumber VR=<IS> VL=<0x2> <3 >
(0x0020,0x0032) ImagePositionPatient VR=<DS> VL=<0x24> <-110.000000 -109.800003-47.500000 >
(0x0020,0x1040) PositionReferenceIndicator VR=<LO> VL=<0x2> <NA>
(0x0020,0x1041) SliceLocation VR=<DS> VL=<0xe> <-47.5000000000>
(0x0028,0x0000) VR=<UN> VL=<0x4> [B@681a9515
(0x0028,0x0002) SamplesPerPixel VR=<US> VL=<0x2> [0x1]
(0x0028,0x0004) PhotometricInterpretation VR=<CS> VL=<0xc> <MONOCHROME2 >
(0x0028,0x0010) Rows VR=<US> VL=<0x2> [0x100]
(0x0028,0x0011) Columns VR=<US> VL=<0x2> [0x100]
(0x0028,0x0030) PixelSpacing VR=<DS> VL=<0x12> <0.859375.859375 >
(0x0028,0x0100) BitsAllocated VR=<US> VL=<0x2> [0x10]
(0x0028,0x0101) BitsStored VR=<US> VL=<0x2> [0x10]
(0x0028,0x0102) HighBit VR=<US> VL=<0x2> [0xf]
(0x0028,0x0103) PixelRepresentation VR=<US> VL=<0x2> [0x1]
(0x7fe0,0x0000) VR=<UN> VL=<0x4> [B@681a9515
(0x7fe0,0x0010) PixelData VR=<OW> VL=<0x20000>

使用DICOM测试工具

如果您想深入研究这一领域，可以使用许多有用的DICOM测试工具之一。我过去使用过并喜欢的一个是DCMTK。该工具包附带许多独立的测试实用程序，可帮助您通过命令行界面测试与DICOM处理相关的各个方面。在示例DICOM文件上运行dcmdump命令将导致输出，如下所示。

c:DicomTestingToolsDCMTK-3.6.3-Win64-Dynamicbin>dcmdump.exe sampledicomfile.dcm

# Dicom-File-Format

# Dicom-Meta-Information-Header
# Used TransferSyntax: Little Endian Explicit
(0002,0000) UL 184                                      #   4, 1 FileMetaInformationGroupLength
(0002,0001) OB 001                                    #   2, 1 FileMetaInformationVersion
(0002,0002) UI =OphthalmicPhotography8BitImageStorage   #  32, 1 MediaStorageSOPClassUID
(0002,0003) UI [2.25.101703809854595919801950834747690813074] #  44, 1 MediaStorageSOPInstanceUID
(0002,0010) UI =LittleEndianExplicit                    #  20, 1 TransferSyntaxUID
(0002,0012) UI [1.3.6.1.4.1.30071.8]                    #  20, 1 ImplementationClassUID
(0002,0013) SH [fo-dicom 4.0.1]                         #  14, 1 ImplementationVersionName

# Dicom-Data-Set
# Used TransferSyntax: Little Endian Explicit
(0008,0008) CS [ORIGINALPRIMARY]                       #  16, 2 ImageType
(0008,0016) UI =OphthalmicPhotography8BitImageStorage   #  32, 1 SOPClassUID
(0008,0018) UI [2.25.101703809854595919801950834747690813074] #  44, 1 SOPInstanceUID
(0008,0020) DA [20200501]                               #   8, 1 StudyDate
(0008,002a) DT [20200501071652]                         #  14, 1 AcquisitionDateTime
(0008,0030) TM [071652]                                 #   6, 1 StudyTime
(0008,0050) SH [125]                                    #   4, 1 AccessionNumber
(0008,0060) CS [US]                                     #   2, 1 Modality
(0008,0061) CS [OP]                                     #   2, 1 ModalitiesInStudy
(0008,0070) LO [Medicolle]                              #  10, 1 Manufacturer
(0008,0080) LO [Test Hospital]                          #  14, 1 InstitutionName
(0008,0081) ST (no value available)                     #   0, 0 InstitutionAddress
(0008,0090) PN [Fergusson^^^Dr]                         #  14, 1 ReferringPhysicianName
(0008,1010) SH [AdvancedCapture]                        #  16, 1 StationName
(0008,1030) LO (no value available)                     #   0, 0 StudyDescription
(0008,1090) LO [AdvancedCapture]                        #  16, 1 ManufacturerModelName
(0010,0010) PN [Bowen^William^^Dr]                      #  18, 1 PatientName
(0010,0020) LO [PAT004]                                 #   6, 1 PatientID
(0010,0030) DA [19560807]                               #   8, 1 PatientBirthDate
(0010,0040) CS [M]                                      #   2, 1 PatientSex
(0010,1030) DS (no value available)                     #   0, 0 PatientWeight
(0018,1000) LO (no value available)                     #   0, 0 DeviceSerialNumber
(0018,1020) LO [AdvancedCapture 3.0.7425.23917]         #  30, 1 SoftwareVersions
(0018,106a) CS [NO TRIGGER]                             #  10, 1 SynchronizationTrigger
(0018,1800) CS [N]                                      #   2, 1 AcquisitionTimeSynchronized
(0020,000d) UI [1.2.826.0.1.3680043.11.106]             #  26, 1 StudyInstanceUID
(0020,000e) UI [2.25.103253814587692535336175589446854494919] #  44, 1 SeriesInstanceUID
(0020,0010) SH [1]                                      #   2, 1 StudyID
(0020,0011) IS [1]                                      #   2, 1 SeriesNumber
(0020,0013) IS [1]                                      #   2, 1 InstanceNumber
(0020,0020) CS [FA]                                    #   4, 2 PatientOrientation
(0020,0062) CS [R]                                      #   2, 1 ImageLaterality
(0020,0200) UI =UniversalCoordinatedTimeSynchronizationFrameOfReference #  20, 1 SynchronizationFrameOfReferenceUID
(0020,1206) IS [1]                                      #   2, 1 NumberOfStudyRelatedSeries
(0020,1208) IS [1]                                      #   2, 1 NumberOfStudyRelatedInstances
(0020,1209) IS [1]                                      #   2, 1 NumberOfSeriesRelatedInstances
(0022,000a) FL 0                                        #   4, 1 EmmetropicMagnification
(0022,000c) FL 0                                        #   4, 1 HorizontalFieldOfView
(0022,000e) FL 0                                        #   4, 1 DegreeOfDilation
(0022,0015) SQ (Sequence with undefined length #=1)     # u/l, 1 AcquisitionDeviceTypeCodeSequence
  (fffe,e000) na (Item with undefined length #=1)         # u/l, 1 Item
    (0008,0104) LO (no value available)                     #   0, 0 CodeMeaning
  (fffe,e00d) na (ItemDelimitationItem)                   #   0, 0 ItemDelimitationItem
(fffe,e0dd) na (SequenceDelimitationItem)               #   0, 0 SequenceDelimitationItem
(0022,0016) SQ (Sequence with undefined length #=1)     # u/l, 1 IlluminationTypeCodeSequence
  (fffe,e000) na (Item with undefined length #=0)         # u/l, 1 Item
  (fffe,e00d) na (ItemDelimitationItem)                   #   0, 0 ItemDelimitationItem
(fffe,e0dd) na (SequenceDelimitationItem)               #   0, 0 SequenceDelimitationItem
(0022,0019) SQ (Sequence with undefined length #=1)     # u/l, 1 LensesCodeSequence
  (fffe,e000) na (Item with undefined length #=0)         # u/l, 1 Item
  (fffe,e00d) na (ItemDelimitationItem)                   #   0, 0 ItemDelimitationItem
(fffe,e0dd) na (SequenceDelimitationItem)               #   0, 0 SequenceDelimitationItem
(0028,0002) US 3                                        #   2, 1 SamplesPerPixel
(0028,0004) CS [RGB]                                    #   4, 1 PhotometricInterpretation
(0028,0006) US 0                                        #   2, 1 PlanarConfiguration
(0028,0008) IS [1]                                      #   2, 1 NumberOfFrames
(0028,0010) US 1920                                     #   2, 1 Rows
(0028,0011) US 1920                                     #   2, 1 Columns
(0028,0100) US 8                                        #   2, 1 BitsAllocated
(0028,0101) US 8                                        #   2, 1 BitsStored
(0028,0102) US 7                                        #   2, 1 HighBit
(0028,0103) US 0                                        #   2, 1 PixelRepresentation
(0040,0555) SQ (Sequence with undefined length #=1)     # u/l, 1 AcquisitionContextSequence
  (fffe,e000) na (Item with undefined length #=0)         # u/l, 1 Item
  (fffe,e00d) na (ItemDelimitationItem)                   #   0, 0 ItemDelimitationItem
(fffe,e0dd) na (SequenceDelimitationItem)               #   0, 0 SequenceDelimitationItem
(7fe0,0010) OB 00000000000000000000000... # 11059200, 1 PixelData

c:DicomTestingToolsDCMTK-3.6.3-Win64-Dynamicbin>

结论

这就对了。这就是对DICOM文件进行一些基本处理的全部。希望本入门教程可以帮助您了解DICOM文件中包含的内容。我没有涉及如何提取存储在我们处理过的DICOM文件中的图像像素数据。我希望在不久的将来在单独的教程中进行介绍。但是，在我的下一个DICOM教程中，我将向您展示如何使用图像以及一些相关信息从头开始编码/创建DICOM文件。如果您对本教程有任何疑问或意见，请随时给我发送电子邮件。请注意，由于工作和其他承诺，我可能不会立即与您联系。

脚注： DICOM标准将包含在其中的文件名/标识符限制为8个字符（仅大写字母字符和数字），以符合传统/历史要求。它还指出，不得从这些名称推断/提取任何信息。当文件名存储为CD或DVD等媒体的一部分时，文件扩展名通常没有.dcm扩展名。我使用更长的名称来防止这些细节现在分散注意力，但是我仍然想提及标准在这里声明的内容，以免造成混淆。

随机文章
java知识点必读
最近更新