dicom格式文件讲解（二）

DcmPixelData Class Reference

Detailed Description

The class DcmPixelData stores
different pixel representations identified by a type (the transfer syntax) and some representation parameters The three unencapsulated transfer syntaxes belong to the same pixel representation.
A type (or transfer syntax) conforms to a representation if thetypeand therepresentation type are equal or both are
unencapsulated. If this is valid for the representation read or set by choose Representation then this representation is the conforming representation. else a representation with the default parameter set defined in the codec is the conforming representation.

conforming

生词本



去背诵

英 [kən'fɔ:mɪŋ]美 [kən'fɔ:mɪŋ]

v.遵守( conform的现在分词 )； 顺应； 相一致； 相符合

different-pixel-representations

不同的像素表示

representations

生词本



去背诵

英 [reprɪzen'teɪʃnz]美 [reprɪzen'teɪʃnz]

n.陈述，投诉，抗议； 表现( representation的名词复数 )； 陈述； 表现…的事物； 有代理人

unencapsulated

生词本

英 ['ʌnɪn'kæpsjʊleɪtɪd]


美 ['ʌnɪn'kæpsjʊleɪtɪd]

adj.未密封的，未用塑料袋装的

1.virtual OFCondition DcmOtherByteOtherWord::setVR

(

DcmEVR

vr

)

[virtual]

set/change the current value representation

Parameters:

vr

new value representation to be set. All VRs except for OW (Other Word String) are treated as 8 bit data (OB).This is particularily useful for unknown (UN)or unsupported VRs.

Returns:status status, EC_Normal if successful, an error code otherwise

Reimplemented from DcmObject.

Reimplemented in DcmPixelData.

2.OFCondition DcmItem::putAndInsertString	(	const DcmTag &	tag,
		const char *	value,
		const OFBool	replaceOld = OFTrue
	)

create a new element, put specified value to it and insert the element into the dataset/item.
Applicable to the following VRs: AE, AS, AT, CS, DA, DS, DT, FL, FD, IS, LO, LT, OB, OF, OW, PN, SH, SL, SS, ST, TM, UI, UL, US, UT

Parameters:

	tag	DICOM tag specifying the attribute to be created
	value	value to be set for the new element (might be empty or NULL)
	replaceOld	flag indicating whether to replace an existing element or not

Returns:EC_Normal upon success, an error code otherwise.

3，

virtual DcmElement* DcmItem::remove

(

const DcmTagKey &

tag

)

[virtual]

remove element from list.

If found, the element is not deleted but returned to the caller who is responsible for further management of the DcmElement object.

Parameters:

tag

attribute tag of element to be removed

Returns:pointer to DcmElement if found, NULL otherwiseDICOM文件的组成要想解析一个文件，虽然可能会有各种各样的类库去做，但还是很有必要去了解下最起码文件的结构，这样在使用类库的时候思路也会更清晰一些。总体来说，DICOM的文件格式还是很清晰的，简单看其实可以分为三部分：第一部分是文件开始固定的128字节为DICOM文件的引言(Preamble)，不过由于可以不写，所以基本上所有的DICOM文件前128字节均为置0;第二部分为跟在之后的4字节文件标识，即“DICM”四个字节，如果不是则表示不是DICOM文件;第三部分为数据集(DataSet)，数据集中包含若干个数据元素(DataElement)，数据集中包含了文件的元数据(File Meta Data Element)、患者及检查的数据、私有数据(Private
Data Element)以及图像、覆盖层等数据(Encoding of Pixel, Overlay and Waveform Data)。对于每一个数据元素，其又包含如下图所示的四部分：数据元素标识 Tag(2字节UInt16分组号和2字节UInt16元素号);数据表现类型 Value Representation(2个单字节Char，有些情况之后会预留两字节的置0，如上图的0x20 0x00
0x01 0x00);数据长度 Value Length(2字节UInt16，有些情况是4字节UInt32，如上图的0x20 0x00 0x01 0x00);数据内容 Value Field(长度为Value Length，如果VL=0xFFFFFFFF，则需要一直读到截止符)。



数据内容的存储与表现格式与VR是关联的(参见标准第五部分第24页)，但比较恶心的是，VR不是一定存在，也就是可能有隐式的情况(需要根据元素标识进行判断)，此外VR的属性还可能是UN(Unknown)等等等等。当然除非你要自己写解析，否则了解到这就可以了。dicom文件中的全体数据必须具有相同的数据结构。

typedef struct DicomElem
{
short int group_tag,
short int element_tag,
char VR[4],
int length,
char data[128]
} DicomElem;

0002组描述设备通讯，0008组描述特征参数，0010组描述患者信息，0028组描述图像信息参数

*DICOM
文件包含的四级属性，patient(病人），study（检查），series（序列），SOP（影像）。
*每一级别需要具有能够唯一标识这个等级属性的键值，类似关系数据库中的主键。病人对应的为Patient
id, 检查 study instance UID,序列 Series
Instanceuid,影像SOP Instance UID.
*标签：（组号，元素号）

所有双数组编号提供DICOM数据字典的供标准 数据使用，所有单数组编号供私用数据使用。

*VR：表示该数据元素中的数据是什么形式的，可查 阅DICOM标准第五部分的24页。VR是可选的，取决于协商的传输数据格式
*数据长度：所有DICOM数据元素都应该为偶数长度，若为奇数，追加空格或空NULL
图像存档和通信系统(Picture Archiving and Communication System, PACS)

ISO-OSI(Inter-national Standard Organization-Open System Interconnection)和TCP/IP (Transmission Control Protocol / Internet Protocol)

信息对象定义(Information Ob-ject Definition，IOD)

服务对象对(Service Object Pair，SOP)

TCP/IP: 是传输控制协议/互联网协议

在DICOM标准的制定中，主要采用了在实际中广泛使用的TCP/IP协议和影响较大的OSI网络

协议，作为对DICOM网络支持的基础。在这两个协议之上分别定义了DICOM自己的基于消息

的信息交换的上层协议DIMSE (Dicom Message Service Element)。

以上参考：http://blog.163.com/yeruining@126/blog/static/83484469201246113948679/

以上定义见文档File2P16

Meta
Element Group Length (0002,0000) 1 UL

File Meta Information Version (0002,0001) 1 OB

Media Storage SOP Class UID (0002,0002) 1 UI

Media Storage SOP Instance UID (0002,0003) 1 UI

Transfer Syntax UID (0002,0010) 1 UI

Implementation Class UID (0002,0012) 1 UI

Implementation Version Name (0002,0013) 1 SH

Source Applica... Entity Title (0002,0016) 1 AE

dicom格式文件 界定标识符的处理

讲怎样去处理文件里一种特殊的数据元素：那就是VR为SQ类型的元素
还有delimited 也就是界定标识符。
http://www.th7.cn/Program/net/201305/137023.shtml
DICOM文件格式与编程
http://hi.baidu.com/diqiucun666/item/c2079909046f1f6cd55a1157
dicom文件 tag值读取·

/article/6019808.html

Dicom格式文件解析器

/article/6019808.html#2929863

普通tag的读取方式
little字节序还是big字节序 隐式VR还是显示VR。由它的值决定 。 这块内容好好看看！！！！

dicom数据结构和编码

http://write.blog.csdn.net/postedit/23919401
个人感觉这篇文章不错。



（1）
VR即Value Representation 翻译过来的意思就是值的表达方式，其实就类似于软件的数据类型，如int，string类型。它是由2个单字节字符表示，如'AE'表示这是AE Title类型的数据。VR在实际存储编码中不一定会有，这取决于采用的transfer
syntax(传输语法)，采用implicit little endian的语法时，VR是没有的，这就需要软件系统自己有套字典可以根据（2）Tag去查找VR 。Value Length:
就是Value Field的长度，以字节为单位。Value Field:
值域，字节长度必须为偶数。

BIG/LITTLE Endian影响的是多字节类型数据的字节编码顺序Little Endian: 最低字节先编码。Big Endian: 最高字节先编码

 2-byte US, SS, OW，AT  4-byte OF, UL, SL, FL  8 byte FD

例如: 8-byte FD的数据6789ABCD, 对于单字节类型的数据，如字符串或者其他字节型数据没有影响，以下VR类型的受影响:在little endian编码下是CDAB8967, 在BIG endian编码下是6789ABCD.这个区别非常重要，尤其在实现dicom数据编解码功能时，一定要注意判断，通过字节交换统一为一样的数据格式，否则同样的数据在不同的平台下会得出不同的结果。
http://bbs.hc3i.cn/thread-5526-1-1.html
http://bbs.hc3i.cn/tag-DCMTK.html