1.3 图像文件的存储格式
数字图像在计算机中是以数据文件的形式存储的,存储格式多种多样,目前较常用的存储格式包括BMP、GIF、JPG、TIFF、PCX等,此外,医学影像存储时还有专用的格式DICOM、IMG等。不同的图像格式,其对数据和图像信息的存储与表达方式均不相同,每种格式通常由不同的开发商支持。每一种格式的图像文件均有一个文件头,在文件头之后才是图像数据。文件头的内容由该图像文件的创建者决定,一般包括文件类型、文件创建人信息、创建时间、版本号、文件大小、压缩方式、存储效率等内容。目前已有不少图像格式转换工具软件,实现不同格式间相互转换的目的。随着信息技术的发展和图像技术应用领域的不断拓宽,未来出现新的图像文件存储格式是完全可能的。
要进行图像处理,必须先了解图像文件存储格式的数据构成。这里以BMP和DICOM为例简要讨论图像文件的格式及其数据结构。
1.3.1 BMP格式
BMP格式也称位图(bitmap)格式,BMP文件也称位图文件,其文件扩展名为*.BMP,可以存储单色、16色、256色、真彩色等几种图像数据,是美国微软公司为其Windows操作系统开发的标准图像格式,可在Windows环境中通用,是一种与硬件设备无关的位图(device independent bitmap)文件格式。在Windows下,其他格式的图片文件都要转化为位图才能显示出来,并在位图格式的基础上采用不同的压缩算法生成。与该格式的图像文件配套,Windows操作系统同时含有一系列支持该图像操作的应用程序接口(application programming interface,API)函数。
BMP格式下的位图有两种形式,分别是自底向上型(bottom-up)和自顶向下型(top-down)。bottom-up型的原点(origin)定义在图像的左下角,而top-down型的原点定义在图像的左上角。
BMP文件的结构主要包括4个部分,即位图文件头BITMAPFILEHEADER、位图信息头BITMAPINFOHEADER、位图颜色表RGBQUAD和位图图像数据ImageData。
1.位图文件头BITMAPFILEHEADER
位图文件头BITMAPFILEHEADER中包含有BMP文件的类型、文件大小和位图起始位置等信息。其具体内容参见表1.1。
表1.1 位图文件头BITMAPFILEHEADER的数据结构
位图文件头BITMAPFILEHEADER的数据结构在windows.h中的定义如下:
typedef struct tagBITMAPFILEHEADER { WORD bfType; //位图文件的类型,规定必须为“BM”,占0~1字节 DWORD bfSize; //位图文件的大小,以字节为单位,占2~5字节 WORD bfReservedl; //位图文件保留字,必须为0,占6~7字节 WORD bfReserved2; //位图文件保留字,必须为0,占8~9字节 DWORD bfOffBits; //位图数据的起始位置,以相对于位图文件头的偏移量表示,以字节为单位占10~13字节
}BITMAPFILEHEADER;
这里的WORD和DWORD均为Windows定义的数据类型,WORD为2字节的无符号二进制整数,DWORD为4字节的无符号二进制整数。上述位图文件头结构的长度是固定的,为14个字节。
2.位图信息头BITMAPINFOHEADER
位图信息头BITMAPINFOHEADER用于说明位图的大小、压缩方式、颜色定义等信息,其具体内容参见表1.2。
表1.2 位图信息头BITMAPINFOHEADER的数据结构
位图信息头BITMAPINFOHEADER的数据结构在windows.h中的定义如下:
typedef struct tagBITMAPINFOHEADER { DWORD biSize; //本结构所占用的总字节数,固定设置为40,字段占14~17字节 LONG biWidth; //以像素为单位给出BMP文件所描述图像的宽度,占18~21字节 LONG biHeight; //以像素为单位给出BMP文件所描述图像的宽度,占22~25字节 WORD biPlanes; //目标设备的级别,必须为1,本字段占26~27字节 WORD biBitCount; //每个像素所需的位数,必须是1、4、8或24之一,本字段占28~29字节 DWORD biCompression; //位图压缩类型,必须是0、1或2三者之一,本字段占30~33字节 DWORD biSizelmage; //位图的大小,以字节为单位,本字段占34~37字节 LONG biXPelsPerMeter; //位图水平分辨率,以每米像素数为单位,本字段占38~41字节 LONG biYPelsPerMeter; //位图垂直分辨率,以每米像素数为单位,本字段占42~45字节 DWORD biClrUsed; //位图实际使用的颜色表中的颜色数,本字段占46~49字节 DWORD biClrlmportant; //位图显示过程中重要的颜色数,如果置为0,表示都重要,占50~53字节
}BITMAPINFOHEADER;
该定义中的LONG也是Windows定义的数据类型,代表4个字节长的二进制整数。上述位图信息数据块文件结构的长度也是固定的,为40个字节。下面对上述定义做出进一步的说明:
(1)biWidth与biHeight分别以像素为单位,给出该BMP文件所描述位图的宽度与高度。若biHeight取值为正数,则表明位图为bottom-up型,位图原点处于左下角;若biHeight取值为负数,则表明位图为top-down型,位图原点处于左上角。一般位图定义中,这两个字段的取值通常为正数。
(2)biBitCount确定每个像素所需要的位数。当图像为单色时,该字段的取值为1;当图像为16色时,该字段的取值为4;当图像为256色时,该字段的取值为8;当图像为真彩色时,该字段的取值为24。
(3)因top-down型位图不能进行压缩处理,字段biCompression仅代表bottom-up型位图的压缩方式,其可能取值分别为BI_RGB、BI_RLE8、BI_RLE4和BI_BITFIELDS,这都是一些Windows定义好的常量。这些取值的含义分别为:字段BI_RGB表示文件内的图像数据没有经过压缩处理;字段BI_RLE8表示所压缩的图像数据是256色,采用的压缩方法是RLE8;字段BI_RLE4表示所压缩的图像数据是16色,采用的压缩方法是RLE4;字段BI_BITFIELDS表明图像文件内的数据没有经过压缩处理,而且颜色表由分别表示每个像素点的红、绿、蓝三原色的双字组成。
事实上,由于RLE4和RLE8的压缩格式用得很少,在大多数情况下,biCompression的有效值为BI_RGB,即不压缩的情况。
3.位图颜色表RGBQUAD
位图颜色表RGBQUAD用于说明位图中的颜色,其中的数据段长度是可变的,具体长度由位图信息头中biBitCount的取值来确定。同时,颜色表中的表项数也由biBitCount的取值来确定,每一个表项是一个RGBQUAD类型的结构,定义一种颜色。位图信息头中biBitCount的取值与颜色表中表项数的关系如表1.3所示,位图颜色表RGBQUAD的数据结构如表1.4所示。
表1.3 位图信息头中biBitCount的取值与颜色表中表项数的关系
表1.4 位图颜色表RGBQUAD的数据结构
位图颜色表RGBQUAD是对那些需要颜色表的位图文件而言的。真彩色图像是不需要颜色表的,BITMAPINFOHEADER后直接是位图数据。颜色表实际上是一个数组,共有biClrUsed个元素(如果该值为零,则有2的biBitCount次方个元素)。数组中每个元素的类型是一个RGBQUAD结构,占4个字节,在windows.h中位图颜色表RGBQUAD的数据结构定义如下:
typedef struct tagRGBQUAD { BYTE rgbBlue; // 该像素颜色中蓝色的亮度分量(取值范围为0~255) BYTE rgbGreen; // 该像素颜色中绿色的亮度分量(取值范围为0~255) BYTE rgbRed; // 该像素颜色中红色的亮度分量(取值范围为0~255) BYTE rgbReserved; // 保留,单必须设置为0 } RGBQUAD;
这里的BYTE也是Windows定义的数据类型,代表一个字节长的无符号二进制整数。依上述设定,若位图中某个像素点的颜色描述为“00H,00H,FFH,00H”,表示该点的颜色为红色。
4.位图图像数据ImageData
位图图像数据记录了位图中每一个像素的值,在扫描行内记录顺序是从左至右,扫描行之间是从下至上。也就是说,从文件中最先读到的是图像最下面一行的左边第一个像素,然后是左边第二个像素,接下来是倒数第二行左边第一个像素,左边第二个像素。以此类推,最后得到的是最上面一行的最右边的一个像素。
位图图像的一个像素值所占的字节数为:
对biBitCount=1时的2色位图,用一位就可以表示该像素的颜色(一般0表示黑,1表示白),所以一个字节可以表示8个像素;
对biBitCount=4时的16色位图,用4位可以表示一个像素的颜色,所以一个字节可以表示两个像素;
对biBitCount=8时256色位图,一个字节刚好可以表示一个像素;
对biBitCount=24时的真彩色位图,一个像素则需占3个字节。
位图数据也是可变长的,取决于图像尺寸、像素位深和压缩方式。另外,Windows规定一个扫描行所占的字节数必须是4的倍数(即以long为单位),不足的以0填充。
1.3.2 DICOM格式
20世纪70年代随着计算机断层成像技术及其他数字医学成像技术的飞速发展,一大批数字医学成像设备相继应用于临床。由于生产这些设备的制造商分布在全球的不同国家,各制造商都制定了各自不同的医学图像存储格式,由此导致的图像标准、传输方式都不可能相同,因而来自不同制造商的成像设备产生的医学影像根本不可能互换交流。
1982年下半年,美国放射学会(American College of Radiology,ACR)与美国电器制造商协会(National Electrical Manufacturers Association,NEMA)联手成立数字图像通信标准委员会,除相关领域专家外,委员会的成员还包括医学影像设备用户代表和制造商代表,共同致力于制定数字影像设备接口的相关标准。委员会的主要目标是:
(1)提供独立于各医疗设备制造商的数字图像及其相关信息的通信标准,结合计算机与网络技术的最新发展促进数字图像的网络化;
(2)为图像归档与通信系统(picture archiving and communication system,PACS)的发展奠定基础,并扩展PACS与HIS(hospital information system)、RIS(radiology information system)等其他医学信息系统的通信;
(3)为形成一个广泛的、分布式的诊断信息数据库建立基本标准,以便于处理地理上分散的不同设备间的诊断、查询请求。
在Agfa、Kodak、GE、Philips、Siemens、Sony等公司的参与下,该委员会分别于1985年、1988年发布了ACR-NEMA标准的两个版本:ACR-NEMA1.0、ACR-NEMA2.0。1993年,ACR-NEMA在北美放射学会上展示了上述标准的第三个版本,该版本被正式命名为DICOM(digital imaging & communication in medicine,医学数字成像与通信)协议标准,确定版本为DICOM 3.0,旨在解决医学成像设备的互连、统一图像格式和传输通信等问题。
目前,DICOM标准已经被医疗设备生产商和医疗界广泛接受,成为世界新型医学成像设备的标准影像接口。带有DICOM接口的计算机断层成像(CT)、磁共振(MRI)、正电子发射断层成像(PET)、单光子发射计算机断层成像(SPECT)、心血管造影和数字超声成像设备大量出现。DICOM标准在医疗信息系统数字网络化中起了重要的作用。
1.DICOM标准的内容
目前的DICOM标准全文共有一千多页,内就涉及概括介绍、一致性声明、信息对象定义、服务类定义、数据结构及编码规则、数据字典,以及利用TCP/IP协议进行协议数据单元、消息的交换,同时还包括与图像存储、显示、组织等相关的内容。不断的补充和完善仍在进行,并朝着放射治疗计划和病理学等领域拓展。每年ACR-NEMA都推出DICOM的修订版。
(1)简介(Overview):包括DICOM各部分的介绍,描述了标准的设计原则,定义了大量标准中会使用到的术语。
(2)兼容性(Conformance):兼容性是指一个符合DICOM标准的设备对DICOM标准的支持程度。标准要求制造商必须精确地描述其产品的DICOM兼容性。因为每台设备通常只是实现了DICOM标准定义的功能的一个子集,所以每台DICOM设备都应该附带一个DICOM兼容性声明,包括选择了什么样的信息对象、服务类、数据编码方法等。
(3)信息对象(Information Object)定义:利用面向对象的方法定义了两类信息对象类:普通性、复合型。对每一个信息对象,规定了描述该对象所必需的信息、各部分的属性。
(4)服务类(Service Class):服务类是对医学信息间的传递和通信的抽象概括,包括作用于信息对象的命令及结果。服务类详细论述了作用与信息对象上的命令及其产生的结果。所有DICOM应用都通过使用服务类的功能来实现。DICOM的服务类主要有:查询/检索服务类、存储服务类、研究内容信息服务类、患者管理服务类、检查(Study)服务类、结果管理服务类、打印管理服务类等。
(5)数据结构和编码(Data Structure and Semantics):在进行网络通信前,必须把信息对象和服务类型的信息进行编码,打包成消息。这部分描述的问题有:使用什么字符集、数据集(data set)的结构和使用、数据元素的使用和元素间的关系、如何唯一标志信息、压缩采用什么编码、编码采用什么规则,等等。
(6)数据字典(Data Dictionary):描述了所有信息对象是由数据元素组成的,数据元素是对属性值的编码。
(7)消息交换(Message Exchange):消息是两个符合DICOM标准的应用实体(Application Entity)之间进行通信的基本单元。消息交换功能定义了与DICOM进行信息通信的医学图像应用软件所用到的服务和协议;描述了建立和终止通信连接的规则,管理“请求及响应”命令的交换规则;构造命令流和消息所必需的编码规则。
(8)网络支持(Network Support):支持DICOM消息交换的网络通信,定义了在网络环境下的通信服务和进行信息交换所必需的上层协议。目前的DICOM支持TCP/IP协议和ISO/OSI协议。
(9)支持点对点(Point to Point)消息通信:早期的ACR-NEMA 2.0版本定义了一种50针的并行数据接口,支持消息交换的点对点通信,说明了与ACR-NEMA 2.0兼容的点对点通信的服务和协议,这在一些老式设备中仍在使用。为了保持向前兼容,后续的DICOM版本仍然保留了这种点对点连接协议。
(10)定义了DICOM文件的存储方式,包括存储介质的规范和数据交换的格式,存储介质运用方法描述,数据交换的存储功能等;描述了DICOM打印用户和打印提供者点对点连接的建立所需的服务和协议;介绍了灰度图像的标准显示控制,保证图像像素与实际显示流明(luminance)程度一致;提供了特定显示系统特征曲线的测量方法,最后还定义了DICOM安全模型。
图1.6给出了DICOM标准主要组成部分及之间的关系。
图1.6 DICOM标准各组成部分关系图(引自参考文献[4])
2.DICOM格式图像文件的结构
DICOM格式的图像文件是指按照DICOM标准而存储的文件。DICOM格式的图像文件一般由DICOM文件头和DICOM数据集合组成,下面分别讨论。
DICOM文件头(DICOM file meta information)中包含了标志数据集合的相关信息。文件头的起始是文件导言(preamble),可以用于应用协议或特定的操作定义,是为了使在DICOM文件中提供的图像和其他数据更易于被访问处理。如果厂商不想在导言中表达信息,这128字节可用十六进制的00H来填充。紧接导言的就是长度为4个字节的字符串“DICM”,用以标识一个DICOM格式的文件。DICOM文件头部分还包括其他一些有用信息,如文件的传输格式、生成该文件的应用程序等。
与一般图像文件不同的是,DICOM文件里不仅包含医学影像数据,还包含许多与图像有关的信息,如患者姓名、出生日期、检查日期、病人编号、检查部位等,有简短的字符信息,也有数字信息。为了合理表达这些信息,DICOM标准定义了大量的数据元素(data element),DICOM数据集合就是由这些数据元素按一定顺序排列组成的。
DICOM数据元素是DICOM文件最基本的构成单元,具体描述了信息对象的某一属性,如患者的名字、检查的部位、成像设备的种类等。数据元素主要包括4个组成部分:标签(data element tag)、数据描述(value representation,VR)、数据长度(value length,VL)和数据域(value field)。DICOM数据元素的结构如图1.7所示。
图1.7 DICOM数据元素的结构示意图
标签是一个4字节的无符号整数。标签由两个部分组成:高位两个字节称为“组号(group tag)”,低位两个字节是“元素号(element tag)”。在DICOM标准的数据字典中,所有数据元素都是用(组号,元素号)这种表示方式一一给出,且在DICOM中所有数据元素都有一个唯一的标签。组号为偶数的称为标准标签(standard tag),均在DICOM标准的数据字典中定义;用户也可以定义自己的数据元素,称为私有数据元素(private data element),此时的组号为奇数。DICOM标准对用户如何定义数据元素有详细的规则说明。
标签为(0002,0010)的数据元素存放的是数据传输协议标志(transfer syntax UID)。其具体内容如表1.5所示。UID形式上是一个字符串,用于唯一标志DICOM标准中各种不同的信息对象。这些信息对象可以是诊断信息、字符格式、图像存储或传输协议等。这里对表1.5中的字符的具体含义不给出解释,有兴趣的读者查阅相关资料。
表1.5 数据传输协议标识的定义
数据描述(VR)说明该数据元素中的数据是哪种类型的,由两个字节长的字符串表示,这些字符串是DICOM标准中默认的字符集。已经存在的VR字符串在DICOM标准中都有详细的定义,如“PN”为姓名类型、“AS”为年龄类型、“DA”为日期类型、“FL”表示该数据元素中的数据为浮点型数据。
数据描述(VR)在DICOM文件中是可选的,具体取决于事先商定的标签为(0002,0010)的数据传输协议标识,参见表1.5。VR分为显式(explicit)和隐式(implicit)两种。数据在显式传输时VR必须存在,而隐式传输时则需要省略这一项。
数据长度(VL)指明数据元素的数据域中数据的字节长度(不包括标签、VR、数据本身这3项的长度)。根据不同的VR类型,VL可为两个字节或者4字节的无符号整数。数据域长度为偶数字节,包含了数据元素的数值,承载着数据元素的具体内容。
依数据描述(VR)与数据长度(VL)字段的组合,数据元素存在三种结构形式:
(1)显式数据元素结构
以显式方式传输的DICOM文件,需有VR这一项。前面有128字节、其值为“00H”的文件导言,紧接着是文件识别标志“DICM”;如果VR字段的值是OB、OW或SQ,则VR域占32位字长,其中前两个字节为有效值,随后的两个字节为DICOM标准的后续版本保留,且被设置为0000H。数据长度(VL)域被指定为32位无符号整数。对数据域中的内容进行解析时,应将VR与VL结合分析。
(2)数据域长度可变的显式VR的元素结构
当VR取其他值时,VL域是跟在两个字符长的VR域后的16位无符号整数,即VR域与VL域各占16位。对数据域中的内容进行解析时,应将VR与VL结合分析。
(3)隐式数据元素结构。
以隐式方式传输的DICOM文件,没有VR这一项,这时的数据元素由3个连续的域构成:标签、数据长度(VL)和数据域。如果数据域有确定的长度,那么数据域字段应包含相当于其长度的值。如果要知道文件中元素的数据类型,只有根据标签的组号和元素号,查询该设备的DICOM说明文件,或者查询DICOM标准的数据字典。
3.DICOM的特点与应用
现在广泛使用的DICOM标准具有以下特点:
(1)以DICOM为基础的PACS可以实现影像设备数据的数字化存储与传输,实现网络化和无胶片化管理,既保持数据的原始性,又调用方便,节省存储空间,节约成本,并可实现远程传输和远程医疗。DICOM的早期版本只适用于点到点的数据传送,从DICOM3.0版本起支持基于TCP/IP协议和ISO/OSI协议等通用工业标准的网络环境,从而为远程医疗创造了条件。
(2)引入了广义的信息对象(information object)概念,便于在网络中明确各信息对象间的关系。信息对象不仅包括图形和图像,还包括检查(study)、报告(report)等广义上的各种信息对象。另外,早期版本如ACR-NEMA1.0、ACR-NEMA2.0只局限于数据传送,而DICOM3.0利用服务类(service class)的概念具体规定了有关指令及数据的语义。
(3)建立多文档结构,便于标准的阅读和扩展。早期版本只规定了医疗设备遵循DICOM规范标准的最低要求,DICOM3.0则明确描述了为达到特定级别而必需的规范声明。例如,各种符合DICOM的设备生产厂家都应该提供该设备的DICOM说明文件(DICOM conformance statement),文件中对此设备的DICOM图像文件中的数据元素都有说明,以明示该设备的DICOM文件具有哪些元素和内容。
(4)所有医学成像设备都使用DICOM标准。因此,可以有效地利用各种设备的影像资源,并且可以在计算机中处理,而不必去研究每一台设备的图像存储结构。但也有不方便的地方就是,DICOM格式仅应用于医学影像领域,日常使用的通用图像处理软件大多不能接受这个存储格式,应用时必须对DICOM图像进行适当的格式转换。
(5)虽然在DICOM标准的说明中要求DICOM格式的图像文件必须包含文件头,但事实上,出于多种原因,多数厂家并没有严格遵守这个要求,在文件中没有包含文件头或在文件头中缺少某些信息。即使这样,这种文件通常也能被DICOM应用软件所识别。
(6)确定了信息对象的唯一性标志,这对在网络环境下清晰地定义信息对象之间的关系具有关键意义。DICOM3.0标准的制定使得医学图像及各种数字信息在计算机间的传送有了一个统一的标准。
(7)采用面向对象设计,引入服务类的概念,封装命令及其操作数据;确定了DICOM兼容的程度。
从目前的发展来看,DICOM已经成为普遍适用的标准,即大部分医学图像设备及PACS系统都使用DICOM作为其互连标准。美国、欧洲、日本的医学影像设备的主要制造商都已经支持DICOM标准,基于DICOM标准的图像分析和图像处理及PACS在临床诊断、远程医疗以及医学教学中发挥着越来越重要的作用,具体如下:
(1)DICOM可作为不同厂家医学成像设备之间的接口。目前DICOM涉及的医学应用包括CT、MRI、CR、X线血管造影、X线透视、B超、核医学成像、放射治疗,X线数字摄影,X线数字乳腺摄影等。DICOM通信接口非常重要的功能之一,是解决了不同厂商的各种符合DICOM标准的医疗设备之间的通信问题。大中型医院在购置新的CT、MRI等医疗设备时,将能否提供符合DICOM标准的接口看作是一个重要的选型指标。不同厂商生产的符合DICOM的医疗设备可以方便地进行互连,也可用于两台医疗设备之间的图像通信,或作为医学成像设备(如CT、MRI等)与图像工作站之间的通信接口。
(2)DICOM可作为小型PACS(mini PACS)或部分型PACS(partial PACS)的通信标准。PACS是近年来随着数字图像处理技术、计算机和网络技术的进步而迅速发展起来的,旨在全面解决医学图像的获取、显示、存储、传输,以及管理的综合系统,其技术关键点主要包括医学图像数据获取、海量数据存储管理、图像处理和显示、数据库管理,以及用于图像数据传输的局域或广域网络等多个方面。而保证PACS成为全开放式系统的重要网络标准和通信协议就是DICOM。只要遵照DICOM这个标准就可以通过PACS沟通不同厂家生产的不同种类的医学数字成像设备。
(3)DICOM作为远程医学影像信息系统的图像通信标准。因为远程医疗一般是在不同单位之间进行,设备也分布在不同地区,所以一般情况下,进行远程医疗的设备多是不同厂家生产。这样,这些设备必须遵守同一标准才能通信。目前,国际上的远程医疗系统基本上采用DICOM标准作为其图像通信的标准。
(4)DICOM作为综合的医学信息系统中的图像通信标准。由于在DICOM标准的制定过程中参考了其他医学信息系统中的相关标准,DICOM非常适合于将PACS信息系统联结到其他医学信息系统,特别是联结到RIS或HIS。由于DICOM标准保证了PACS的通信标准与HIS/RIS通信标准的相互兼容,大大简化了两种系统相连的兼容问题。
关于DICOM格式的进一步讨论,还可参见本书第8章的相关内容。