DICOM医学图像格式转换

内蒙古科技大学本科生毕业设计说明书〔毕业论文〕题目:DICOM格式医学图像格式解析学生姓名:刘雪霞学号:2003054417专业:电子信息工程班级:信息2003-4班指导教师:吕晓琪教授摘要DICOM3.0是医学影像存储和传输的国际标准，它标准了医学图像及各种数字信息在异构系统和设备之间存储、传送时的文件格式和语义描述。解读DICOM3.0的医学图像文件格式以及解决其显示问题是医学图像处理的根底，对医学影像技术的研究具有重要的意义。本文分析了DICOM医学图像的格式，在此根底上把DICOM图像转换为常用的BMP图像格式，这种转换是有意义的，可便于许多常用图像处理工具进行DICOM图像的显示。针对DICOM图像文件存储的格式编制的程序，实现了DICOM图像文件的读取显示。由于设计时间短暂，本人水平有限，在设计完成的程序中难免有许多缺乏之处，敬请老师批评指正。关键词:DICOM，BMP，转换，显示AbstractDICOM3.0istheinternationalstandardofmedicalimagesarchivingandcommunication.Itdefinestherulesofpixeldataandotherdigitalinformationwhentheyaretransferredorstoredbetweendeviceswithdifferentoperatingsystemsorofdifferentmanufacturers.AnalysisonthestorageformatofDICOM3.0medicalimagefilesanddisplayingthemisthebasisofmedicalimageprocessing.Itisveryimportantformedicalimagetechnologystudy.FirstlythisarticleanalysestheformofDICOMmedicineimages,andinthisfoundation,transformstheDICOMimageintotheBMPimageformcommonlyused.ThetransformationissignificantbecauseitiseasytodisplaytheDICOMimagesonmanycommonlyusedimagerytools.Wealsocomparedourresultswiththoseofothersoftware.ThesoftwareofthisarticlerealizedthereadinganddisplayingofDICOMimages.DuetothelimitationofthedesigntimeandtheknowledgeofI,inthedesign,theprocedurerealizedaswellasthepapermusthavegotsomemistakesandshortcomingsInstructionsaswellasadvicearewelcome.Keywords:DICOM，BMP，TRANSFORMS，DISPLAY目录摘要………….………IAbstract……………..…II第一章绪论………………………..…11.1引言………….11.2课题背景…………………….11.3VisualC++6.0………………..1第二章DICOM标准………………..32.1DICOM标准概述……………32.1.1DICOM标准产生背景……………….32.1.2DICOM标准开展应用……………….42.2DICOM标准内容……………62.2.1DICOM标准词汇及概念…………….62.2.2DICOM标准的组成………………….7第三章格式转换……………………113.1DICOM格式………………..113.1.1DICOM文件头……………………...113.1.2DICOM数据元素…………………...123.1.3像素数据元…………153.2BMP格式…………………...163.2.1文件头………………173.2.2位图信息头…………183.2.3位图表项……………193.2.4位图数据……………193.3格式转换…………………...213.3.1转换思路……………….……………213.3.2转换类的定义……………….………223.3.3转换算法……………24第四章图像显示……………………314.1位图原理…………………...314.1.1DDB位图……………314.1.2DIB位图……………..324.2位图的显示方法…………...324.3显示实现…………………...34结论…………………38参考文献……………39附录…………………40致谢…………………44第一章绪论1.1引言随着医学信息学的开展，数字化医院成为一个趋势。数字化医院主要解决两个方面的问题：一是医院无胶片化，由PACS系统实现；二是无纸化，由HIS和RIS实现。DICOM就是解决数字化医院的一个重要标准。20世纪80年代以来，为了利用网络在不同的设备和医疗诊断系统之间交换图像数据和诊断信息，由美国放射学会ACR和美国电器制造商协会〔NEMA〕联合制定DICOM标准，经过不断的开展，今天已经成为医学信息领域的国际标准，被生产医疗仪器和医学诊断系统的厂家所接受，在国外得到了广泛的应用。然而，在我国，由于大多数医学图像设备和系统在引进前期未考虑图像和相关医学信息的存储和通信功能，只是配置一部打印机或用Ｘ线胶片做图像记录，造成了目前医院特别是中小医院DICOM设备与非DICOM设备并存的现象，同时也为PACS系统的开展造成了障碍。因而，在DICOM设备与非DICOM设备之间研究二者的互联、进行非DICOM与DICOM图像的转换具有重要的意义。1.2课题背景DICOM〔DigitalImagingandCommunicationofMedicine，简称DICOM〕是用于医学图像和通信的国际标准[1]，它标准了医学图像及各种数字信息的格式，支持TCP/IP网络。在DICOM的支持下，可以进行不同厂家生产的设备的互连，将图像从一个厂家的设备发送到另一个厂家的工作站上显示。这些工作站主要基于UNIX的系统，很多厂家只提供UNIX平台下的图像显示软件。随着PC机功能越来越强，网络速度越来越快，医生迫切希望在办公室或家里都可以通过PC机检索和查阅病人的图像资料，为此需要实现DICOM图像在Windows平台下的显示。本文在分析DICOM文件格式根底上，研究了DICOM文件格式和BMP文件格式的转换以及显示。1.3VisualC++6.0VisualC++是Microsoft公司推出的开发Win32环境程序，是面向对象的可视化集成编程系统。它不但具有程序框架自动生成、灵活方便的类管理、代码编写和界面设计集成交互操作、可开发多种程序〔应用程序、动态链接库、ActiveX控件等〕等优点，而且通过简单的设置就可使其生成的程序框架支持数据库接口、OLE2、WinSock网络、3D控制界面。另外，VisualC++还提供了很多向导。MFC封装了Win32API，OLEAPI，ODBCAPI等底层函数的功能，并提供更高一层的接口，简化了Windows编程。同时，MFC支持对底层API的直接调用。用户可以利用VisualC++以两种方式编写Win32应用程序，一种方式是基于WindowsAPI的C编程方式，另一种是基于MFC的C＋＋编程方式。C编程方式是传统的、久经考验的编程方式，代码的效率较高，但开发难度与开发的工作量大。C＋＋编程方式代码运行效率相对较低，但开发难度小、开发工作量小、源代码效率高。由于VisualC++本身就是一个图形的开发界面，它提供了丰富的关于位图操作的函数，为开发图像处理系统提供了极大的方便。本文是基于C＋＋编程方式进行编程的。第二章DICOM标准2.1DICOM标准概述DICOM标准产生背景DICOM是DigitalImagingandCommunicationofMedicine的缩写，是美国放射学会(AmericanCollegeofRadiology，ACR)和美国电器制造商协会(National

Electrical

Manufacturers

Association，NEMA)组织制定的专门用于医学图像的存储和传输的标准名称[2]。经过十多年的开展，该标准已经被医疗设备生产商和医疗界广泛接受，在医疗仪器中得到普及和应用，带有DICOM接口的计算机断层扫描(CT)、核磁共振(MR)、心血管造影和超声成像设备大量出现，在医疗信息系统数字网络化中起了重要的作用。下列图为DICOM标准各版本发布时间表。图2.1DICOM标准各版本发布时间表DICOM是随着图像化、计算机化的医疗设备的普及和医院管理信息系统，特别是图像存档和通信系统(PictureArchivingandCommunicationSystem，PACS)和远程医疗系统的开展应运而生的。当CT和MR等设备生成高质量的、形象直观的图像在医疗诊断中广泛使用时，由于不同的生产商不同型号的设备产生的图像各自采用了不同的格式，使得不同的设备之间的信息资源难以互相使用，医院PACS系统的实施具有很大的困难。医疗信息系统随之带来许多新的问题：如何存储数据量极大的图像并能有效地管理？不同生产商的设备能否直接连接？如何能够在不同的生产商设备之间能够共享信息资源？等等。很明显这些问题的解决方法就是采用统一的标准。为此，美国放射学会和美国电器制造商协会在1983年成立了专门委员会，制定用于医学图像存储和通信的标准，提供与制造商无关的数字图像及其相关的通信和存储功能的统一格式，以促进PACS的开展，并提供广泛的分布式的诊断和查询功能。ACR-NEMA1.0版本于1985年推出，随后增加了新的数据元素并对局部内容进行修改，形成2.0版本。由于认识到标准对网络支持的缺乏和标准本身存在的结构性问题，ACR-NEMA结合当时的技术条件和方法对标准作了彻底的重新制定，在1993年正式公布了新的版本，命名为DICOM3.0。与原版本相比，3.0版本采用了面向对象的分析方法，定义了医学图像在存储和通信过程中的各种实体和关系，提供了对ISO-OSI(Inter-nationalStandardOrganization-OpenSystemInterconnection)和TCP/IP(TransmissionControlProtocol/InternetProtocol)的支持，使得在医学图像应用层上可以与其它通信协议栈直接通信而不需要重新编写程序。考虑到技术的开展，标准采用了多局部的文档结构，对可能变化或扩充的局部以附录的形式提供，这样标准在更新时涉及面可以尽量小。下列图为PACS系统框图。图2.2PACS系统框图DICOM标准开展应用毫无疑问，DICOM是医学图像信息系统领域中的核心，它主要涉及到信息系统中最主要也是最困难的医学图像的存储和通信，可直接应用在放射学信息系统(RIS)和图像存档与通信系统(PACS)中。DICOM也是研究和开发具有网络连接功能，实现信息资源共享的新型医疗仪器的技术根底。医疗仪器在朝着自动化、智能化开展的同时，也在向着具有通信能力的遥控遥测和信息远程获取的网络功能开展，医疗仪器既是医疗信息系统中的信息源，又是系统中的信息使用者，是信息系统中的一个主要环节，网络化的医疗仪器对医学信息系统的重要性是不言而喻的。DICOM标准的另一个特点是它定义在网络通信协议的最上层，不涉及到具体的硬件实现而直接应用网络协议，因此与网络技术的开展保持相对独立，可以随着网络性能的提高而使DICOM系统的性能立即得到改善。DICOM尽管提供了OSI的网络模型，但现在实际上网络绝大局部都是在TCP/IP协议下构成的，网络硬件采用的形式可以多种多样，如100M的双绞线100Base-T，光纤FDDI，综合业务数字网ISDN，T1线路等，还有速度较低的10兆网10Base-T和线路。只要设备具有支持TCP/IP协议的网络接口，在软件的支持下，就可以做到像PC机一样实现“即插即用〞，非常方便地参加到医学信息系统的网络中。在这样的意义下，用DICOM实现的医疗信息系统，无论是RIS还是PACS，都具有类似的结构。在采用DICOM标准的信息网络系统中，所有DICOM设备之间都可以按照DICOM的网络上层协议进行互相连接和操作。临床医生可以在办公室查看B超设备的图像和结果，可以在CT机上调用核磁共振图像进行图像的叠加融合，也可以通过网络调用存储在其它医院的图像结果。无论是本院、本地还是相距很远的外地，DICOM设备都可以通过网络相互联系，交换信息。由于提供了统一的存储格式和通信方式，普及DICOM标准，可以简化医疗信息系统设计，防止许多重复性的工作，加快信息系统的开发速度。对于实现无纸化、无胶片化的医院和远程医疗系统的实施将会起极其重要的作用。下列图为DICOM的应用范畴。图2.3DICOM的应用范畴2.2DICOM标准内容DICOM标准词汇及概念DICOM标准涉及到医学图像、数据通信、管理信息系统等领域，在标准中又采用了面向对象的描述方法和E-R(Entity-Relation)模型，从而引入了大量的各专业方面的术语，给标准的阅读和理解带来困难。下面简要地将标准中涉及的常用的技术词汇和缩略语给予解释。1.实体(Entity)：表示一个或一类有相同特性个体的应用对象。在计算机系统分析中，但凡可以区别并被人们识别的事、物、概念等，都可以被抽象为实体。实体一般具有假设干特征，称为属性。如：患者是一个实体，具有姓名、性别、年龄等属性。图像也是一个实体，它有图像尺寸、图像数据等属性。2.联系(Relation)：表示实体之间的相互关系。如患者实体与分析实体之间存在着引用联系，打印机实体和胶片实体之间存在着打印的联系。3.E-R模型：描述现实世界的一种信息模型。通过定义实体以及实体间的联系，表现系统的需求和功能。通常以E-R图的方式表示。在DICOM中，用方框表示实体，菱形表示联系，用带箭头或不带箭头的线段将实体(方框)与联系(菱形)连接表示它们之间存在联系。这是面向对象的分析方法所采用的主要表示方法，是对客观世界的一种抽象。4.对象(Object)：外部世界事物在计算机内部的表示，是事物属性值和处理方法的集合。对象具有封装和继承的特征。封装是指对象将属性和方法集合在一起，一般情况下只提供应自己和派生对象使用。继承是指当一个对象是由另一个对象(父对象)派生出时，它就自动具有父对象所具有的属性和方法。面向对象的方法就是以对象技术为中心，分析系统中各种信息之间的关系，抽象出系统各层次的对象模型，给出准确的系统描述，并在计算机系统中给予实现。应用面向对象的方法，可以提高开发效率，实现软件复用。5.信息对象定义(InformationObjectDefinition，IOD)：信息实体的抽象，是DICOM命令的作用受体。一个信息对象定义〔IOD〕是一个面向对象的抽象数据模式，用来指定关于现实世界对象的信息。一个IOD提供了带有用来交换的信息的通常考虑的通讯应用实体。一个IOD不代表一个特定的现实世界对象的实体，但相当一个共享相同属性的现实世界对象类。一个用来代表单一的现实世界对象类IOD由一个规格化的信息对象调用。一个包括相关的现实世界对象信息的IOD由复合信息对象调用。6.效劳(Service)：某对象为其它对象或程序提供的功能。当要求使用此功能时称申请效劳，申请效劳的对象称效劳用户，而能完成该功能的对象是效劳的提供者。7.效劳对象对(ServiceObjectPair，SOP)：DICOM信息传递的根本功能单位。包括一个信息对象和一组DICOM消息效劳元素。一个效劳类说明定义了一组一个或更多的与一个特定的功能〔由通讯应用实体实现〕相关的SOP类。一个效劳类说明也定义了允许实现规定一些预定义级别的到一个或更多的SOP类的遵从性。应用可以遵从SOP类，作为一个效劳类用户〔SCU〕或效劳类提供者〔SCP〕。8.协议：计算机网络中为保证能正确地传输数据而必须共同遵守的通信规那么和格式。9.ISO-OSI：国际标准化组织(ISO)所定义的开放系统互联(OSI)的七层网络参考模型。作为一个严格的网络模型，对于计算机网络的研究和开展起了重要的作用，但是由于种种原因在实际中并未得到广泛的普及使用。DICOM标准在制定时，OSI正是开展的高潮，因此也作为DICOM中主要的网络参考模型。10.TCP/IP：是传输控制协议/互联网协议，它首先在UNIX系统中使用，随后成为计算机网络中不同种类计算机之间通信的主要通信协议，是互联网的根底。DICOM标准的组成DICOM标准是经历了一个从无到有、从简单到复杂的开展过程。在标准的制定过程中不断听取工业界、学术界、医疗界等各方面的意见和建议，注意标准的可扩充性和扩展性，经历了ACR-NEMA1.0和2.0的版本到目前的DICOM3.0版本，标准的组成也在不断地加以补充，目前标准共有以下18个根本局部和扩充局部组成[3][4][5]。1.引言与概述〔IntroductionandOverview〕：简要地概述DICOM标准涉及到的范围和框架，指出标准起草的背景和标准的目的和意义，并对其他局部的内容做了简介。2.遵从性声明〔Conformance〕：详细说明DICOM的兼容性目的和架构，说明了标准是一个可以参考遵循的多层次的专业标准，同时阐述了参考遵从标准的产品应该发布的遵从性声明。3.信息对象定义〔InformationObjectDefinitions〕：详细给出了标准从医疗现实中抽象出来的信息对象的组成、概念和内涵。同时定义了可以使用DICOM进行通信的类别，它是标准研究的重要内容。4.效劳类细那么〔ServiceClassSpecifications〕：标准将图像通讯中可能涉及到的通讯类型分成假设干详尽的对等的类别，将其定义为DICOM进行通信的效劳类，并对这些类分别做了标准和界定，给出用于数字化交流的操作行为的抽象定义。5.数据结构与编码〔DataStructuresandEncoding〕：这一章对标准用到的数据结构进行了说明。对标准规定的专用的医学图像文件格式做了具体的规定。并且对可能关联到的数据、字符进行了编码。6.数据字典〔DataDictionary〕：包括了标准中所有的数据元的编码代号和编码说明。标准采用了在所有的国际标准中都是唯一的标识符UID，从而减少了实现的冲突。7.消息交换〔MessageExchange〕：定义了DICOM进行信息交换通讯的医学图像应用软件所用到的效劳和协议。描述了建立和终止通讯连接的规那么：管理“请求及响应〞命令的交换规那么；构造命令和消息所必须的编码规那么；同时也定义了DICOM应用实体间的协议握手方式。8.支持网络通信的消息交换〔NetworkCommunicationSupportforMessageExchange〕：这一局部标准了通讯协议和交换信息格式，描述了如何在TCP/IP网络中使用网络通讯进行信息交换，并且定义了在网络环境下的通讯效劳和DICOM应用进行信息交换的必要的上层协议。9.点对点通信支持的信息交换〔Point-to-PointCommunicationSupportforMessageExchange〕：已放弃。10.介质交换的介质存储要求及文件格式标准〔MediaStorageandFileFormatforDataInterchange〕：它提供了一个用于不同类型医学图像间数据交换及不同物理介质相关信息交换的框架。DICOM文件格式提供了一种封装文件中数据集的方法。数据集代表了一个与DICOMIOD相关的SOP实例。11.介质存储应用概述〔MediaStorageApplicationProfiles〕：说明将医学影象信息存储于可移动介质的模式。12.数据交换的媒介格式和物理媒介〔MediaFormatsandPhysicalMediaforDataInterchange〕：介绍存储过程中数据和目录的格式以及管理标准要求。13.支持点对点通信的打印管理〔PointManagementPoint-to-PointCommunicationSupport〕：已放弃。14.灰度图像标准显示函数〔GrayscaleStandardDisplayFunction〕：详细标准了显示灰度函数，它提供了一些例如方法，说明如何调整灰度图像与显示系统。这对显示参数包括胶片打印及其各种图像显示设备的标准，有着非常重要的依据，并且直接影响到临床诊断的准确性。15.平安概要〔SecurityProfiles〕：DICOM标准医疗图像中包含了病人非常详细的个人资料，因此为了保障在存储传输过程中数据的平安性，有必要对信息实施加密传输。16.内容映射资源〔ContentMappingResource〕：定制了一些结构化报告模板的信息对象，设置了在信息对象中用到的编码化词汇，维护了标准中使用到的短语。17.解释性信息〔ExplanatoryInformation〕：制定了一组信息化和标准化的包含解释性信息的附件。18.通过互联网访问DICOM持久型对象〔WebAccesstoDICOMPersistentObject〕：此局部定义了通过使用URL/URI请求来访问DICOM对象的方式以及返回结果的格式。DICOM是一个开放的系统，标准采用相对独立的多文档结构，便于对单独局部进行扩充而不需要大幅更改整个标准，增强了它的健壮性和扩展性。同时各局部也是紧密相关的，因此它的复杂性要求标准研究者对DICOM体系结构有全面的认知。第三章格式转换3.1DICOM格式DICOM格式[6]图像文件是指按照DICOM标准而存储的文件。DICOM文件一般由DICOM文件头和DICOM数据集合组成，如图3.1。DICOM数据集合由DICOM数据元素(DataElement)按一定顺序排列组成，而DICOM数据元素那么是DICOM文件最根本的构成单元。数据元…..数据元数据元前缀前同步数据元…..数据元数据元前缀前同步文件头数据集图3.1DICOM文件总体结构DICOM文件头DICOM文件头(DICOMFileMetaInformation)中包含了标识数据集合的相关信息。文件头的最开始是文件前言(Preamble)，它由128个00H字节组成，紧接着就是长度为4个字节的字符串“DICM〞，严格地讲，每个DICOM文件都必须包括该文件头，并且可以根据该字符串值来判断一个文件是否是DICOM格式文件。然而，在实际工程开发过程中所遇到的情况并非如此，图3.2是富士公司设备产生的人体脑部CT图像，通过二进制方式查看该DICOM图像文件发现其文件头局部根本没有字符“DICM〞，其它如Picker公司、Philips公司等的设备产生的DICOM图像也有类似情形。上述情况可以说明一个问题，即并非所有影像设备制造商都严格遵守DICOM3.0标准，充其量是局部遵守了这个标准，原因可能是多方面的，但多多少少有保护自身商业利益的意味。DICOM文件头局部还包括其它一些非常有用的信息，如文件的传输格式、生成该文件的应用程序等等。关于文件头有几点说明：1.除了128字节的文件前同步码和4字节的DICM前缀外，所有其它的文件头数据元都必须采用上面介绍的显式格式编码，各个数据元按照标签值从小到大的顺序编码。2.每个文件头元素的长度必须为偶数，否那么按照规定补充一个字节。3.所有〔0002，****〕类的标签都为DICOM所保存。为了兼容后续版本，如果发现文件中有目前尚未规定的〔0002，****〕类标签，那么忽略它。图3.2DICOM数据元素数据元素(DataElement)是DICOM格式图像文件最根本的构成单元。它由四个局部组成:标签(Tag)、数据描述VR(ValueRepresentation)、数据长度VL(ValueLength)以及实际数据值Value，如图3.3所示。1.标签是一个4字节的无符号整数，DICOM中所有数据元素都可用标签来唯一表示，标签由两个局部组成:组号(高位2字节)和元素号(低位2字节)，在DICOM标准的数据字典中，所有元素都是用“(组号，元素号)〞这种表示方式一一对应的。2.数据描述VR指明数据元素中数据的类型，为2字节的字符串。例如，假设VR为“DA〞那么表示该数据元素存储日期型数据，VR是可选的，取决于事先商定的数据传输句法(TransferSyntaxUID)，它包含在标签为(0002，0010)的数据元素中。数据传输句法(TransferSyntaxUID)后面作详细介绍。VR分为显式(ExplicitVR)和隐式(ImplicitVR)两种。数据在显式传输时VR必须存在，而隐式传输时VR为空。数据长度VL指明数据元素的数据域中数据的长度(字节数)。数据域中包含了数据元素的数值。数据集合传输次序数据元素数据元素数据元素…数据元素数据元素标签数据描述数据长度实际数据值可选项，取决于传输UID图3.3DICOM文件数据元素的组成下面以标签为(0010，0010)表示病人姓名的数据元素为例对上述介绍做一比拟形象的说明。①显式〔ExplicitVR〕传输时： 4字节2字节2字节C字节〔16进制〕/12字节0010，0010PNOCHarisonFordExplicitTagVRVLValueFieldPN:PersonName.表示数据类型②隐式〔ImplicitVR〕传输时：4字节4字节C字节〔16进制〕/12字节0010，0010OOOCHarisonFordImplicitTagVLValueFile由此可见，显式时VR中存放数据类型，隐式时VR不存在。VL表示数值长度，如上例中的“HarisonFord〞占12个字节长。组号为0002的数据元素都是显式的。标签为(0002，0010)的数据元素存放的是数据传输协议标识(TransferSyntaxUID)其具体内容如表3.1所示。UID形式上是一个字符串，用于唯一标识DICOM标准中各种不同的信息对象，在DICOM文件中有很多UID，如诊断UID、字符格式UID图像存储UID、传输协议UID等等，这些UID有些可以套用现成的，有些必须要自己确定，特别是UID中的厂商信息、医院信息以及图像的分类序列号等等。表3.1：传输协议UIDTransferSyntaxUIDDefinitionRawdataImplicitVRLittleEndian.XRawdataImplicitVRX=1:LittleEndianX=2:BigEndian.4.XJPEGCompressionXX=50-64:LossyJPEGXX=65-70:LosslessJPEG.5LosslessRunLengthEncoding每个UID由两局部组成，一个根(orgroot)和一个后缀(suffix)，其格式为：<orgroot>.<suffix>.<suffix>由所指示的机构分配，并且必须在<orgroot>范围保证唯一性。如“1.2.840.10008”专门保存给DICOM所定义的术语(如传输语法)使用，其中，“1〞表示国际标准化组织ISO，“2〞表示ISO下属的一个成员机构，这里指美国国家标准组织ANSI，“840〞表示成员机构所在的国家或地区代码，这里指美国，“10008〞在这里指NEMA。表3.1中“.4.XX〞表示DICOM图像是以JPEG压缩方式传输和存储的，XX为50至64之间的数值时表示有损压缩，XX介于65和70之间表示无损压缩。“000”表示采用无损行程编码压缩算法RLE(RunLengthEncoding)压缩。表3.1中的“LittleEndian〞和“BigEndian〞表示字节存放次序。其中，对“LittleEndian〞而言，最重要的字节置右，最不重要的字节置左。而“BigEndian〞那么正相反，最重要的字节置左，最不重要的字节置右。如两个字节中存放的二进制数值为“1111111100000000〞，对“LittleEndian〞而言表示十进制数255，而对“BigEndian〞而言那么表示十进制数65280。传输协议UID中缺省字节存放次序为传输语法是由一个UID标识的。DICOM默认的传输语法是隐式小端字节序传输语法，并采用无损方式的JPEG压缩算法。传输语法定义了三个方面的内容：数值表示法如何指定；多字节数在存储或传输时的字节顺序，是低位字节先存储或发送，还是高位字节先存储或发送；封装情况下的压缩格式，是采用JPEG还是RLE的压缩算法，是有损方式还是无损方式等。3.值域长度指明该数据元的数据域中数据的长度〔字节数〕。4.数据域中包含了该数据元的数值。DICOM中所有的数据都是以数据元素的形式出现的〔除文件头中128字节的文件前言〕。5.SQ数据元和嵌套数据集的格式，表示值为SQ的数据元，其值域可以包含一个或多个数据元，这些数据元称为项。每个项中又可以包含其它项，从而形成多级嵌套结构。SQ数据元中有三个特殊的数据元，即项〔FFFE，E000〕、项定界数据元〔FFFE，E00D〕、系列定界数据元〔FFFE，E0DD〕。不管传输语法所规定的表示值编码规那么是什么，这三个数据元都必须采用隐含表示值编码方式。3.1.3像素数据元像素数据元〔7EF0，0010〕是DICOM文件中最重要的一个数据单元，该数据元包含了医学图像的显示所必须的数据。与像素数据元有密切关系的其他数据元是：〔0028，0008〕图像帧数〔0028，0010〕图像行数〔0028，0011〕图像列数〔0028，0100〕分配位数〔0028，0101〕存储位数〔0028，0102〕最高位数像素数据的编码由分配、存储和最高位数决定，分配位数一定是大于存储位数的。根据分配、存储和最高位数的不同，像素数据编码有如图3.4几种情况DICOM图像的像素数据一般为16bits或12bits两种。假设数据为16bits时，那么每像素二字节，如图3.4中前两种情况；假设数据为12bits时，那么每像素字节分配情况就较为复杂，需要通过类别〔0028，0010〕，〔0028，0101〕，〔0028，0102〕的值来决定每像素分配位数、存储位数和像素的最高位情况。当每像素分配的位数为16、存储位数为12、最高位为11时，每像素占用二个字节位，每像素仅利用了二个字节中的低12bits。当每像素分配的位数为16、存储位数12、最高位为15时，每像素占用二个字节位，每像素仅利用了二个字节中的高12bits。当每像素分配的位数为12、存储位数为12、最高位为11时，每二个像素占用三个字节位，中间一个字节的内容一分为二，分别属于其前后二个字节，所以每像素有12bits，如图3.4第三种情况。1BitsAllocated=1615110BitBitsStored=12HightBit=11BitsAllocated=1615110bitBitsstored=12HighBit=11BitsAllocated=1223110bitBitsstored=12HighBit=11BitsAllocated=87530bitBitsstored=6HighBit=5图3.4像素数据编码像素数据可以是压缩的，也可以是未压缩的。以压缩格式来传送数据时，表示值VR为OB；以未压缩格式传送数据时，表示值VR为OW。对于未压缩像素数据，通常按照从上到下、从左到右的顺序，作为连续的位流进行编码和存储。对于压缩的像素数据，可以分段存放，由系列定界项表示结束，从而支持长度预先未知的图像压缩过程。3.2BMP格式BMP文件格式[7]是微软Windows操作系统支持的几种图像文件格式之一。BMP是Windows与生俱来的位图格式，实际上可以用与存储任何位图数据。在微软Windows下运行的大多数图像和图像应用程序都支持BMP文件的创立和显示。BMP位图文件的总体结构如图3.5：BITMAPFILEHEADER文件头BITMAPINFOHEADER信息头PALETTE调色板〔颜色表项〕DIBPIXELS图像数据图3.5BMP文件总体结构文件头BMP文件头数据结构含有BMP文件的类型、大小和打印格式等信息。其数据结构定义如下：TypedefstrcttagBITMAPFILEHEADER{WORDbfType;DWORDbfSize;WOEDbfReserved1;WORDbfReserved2;DWORDbfOffBits;}BITMAPEILEHEADER;该结构的长度是固定的，为14个字节〔WORD为无符号16位整数，DWORD为无符号32为整数〕；各个域的说明如下：1.bfType：指定文件类型，必须是0x424D，即字符串“BM〞，也就是说所有“.bmp〞。文件头的头两个字节都是“BM〞；bfSize：指定文件大小，包括14个字节；bfReserved1，bfReserved2：为保存字，无须考虑；bfOffBits：为从文件头到实际的位图数据的偏移字节数。位图信息头位图信息头BITMAPINFOHEADER数据结构含有位图文件的尺寸和颜色等信息。其数据结构定义如下：TypedefstructtagBITMAPINFOHEADER{DWORDbiSize;WORDbiWidth;DWORDbiHeight;WORDbiplanes;WORDbiBitCount;DWORDbiCompression;DWORDbiSizeImage;DWORDbiXPelsPerMeter;DWORDbiYPelsPerMeter;DWORDbiClrUsed;DWORDbiClrImportant;}BITMAPINFOHEADER;该结构的长度也是固定的，为40个字节〔LONG为32位二进制整数〕。各个域说明如下：bfSize：指定该结构的长度，为40个字节；biWidth：指定图像的宽度，单位为像素；biHight：指定图像的高度，单位为像素；biplanes：必须为1，不用考虑；biBitCount：指定表示颜色时要用到的位数，常用的值为1〔黑白二色图〕、4〔16色图〕、8〔256色〕、24〔真彩色〕，最新的“.bmp〞格式支持32位色；biCompression：指定位图是否压缩。必须是0〔不压缩〕，1〔BI_RLE8压缩类型〕或2〔BI_RLE4压缩类型〕之一；biSizeImage：指定实际的位图占用的字节数；biXPelsPerMeter：指定目标设备的水平分辨率，单位是像素/米；biXPelsPerMeter：指定目标设备的垂直分辨率，单位是像素/米；biClrUsed:指定图像实际用到的颜色数；biClrImportant：指定本图像中重要的颜色数，如该值为0，那么所有的颜色都重要。位图表项有些位图需要颜色表，有些位图，如真彩色图，不需要颜色表，它们的BITMAPINFOHEADER后面直接就是位图数据。颜色表实际上是一个数组，共有biClrUsed个元素〔如果该值为0，那么有2的biClrUsed幂个元素〕。数组中每个元素的类型是一个RGBQUAD结构，占4个字节，其定义如下：TypedefstructtagRGBQUAD{BYTErgbBlue;BYTErgbGreen;BYTErgbRed;BYTErgbReserved;}RGBQUAD;其中：rgbBlue：蓝色分量；rgbGreen：绿色分量；rgbRed：红色分量；rgbReserved：保存值。位图数据位图数据是实际的图像数据，对于用到调色板的位图，图像数据就是该像素颜色在调色板中的索引值，对于真彩色图像，图像数据就是实际的R、G、B值。对于2色位图，用1位就可以表示该像素的颜色〔一般0表示黑，1表示白〕，所以一个字节可以表示8个像素。对于16色位图，用4位可以表示一个像素的颜色，所以一个字节可以表示2个像素。对于256色位图，一个字节刚好可以表示1个像素。位图阵列记录了位图的每一个像素值。在生成位图文件时，Windows从位图的左下角开始逐行扫描位图，将位图的像素值一一记录下来。这些记录像素值的字节组成了位图阵列。位图阵列有压缩和非压缩两种存储格式。通常，位图采用的是非压缩格式。在非压缩格式中，位图的每一个点的像素值一一对应于位图阵列的假设干位，位图阵列的大小由位图的宽度、高度及位图的颜色数决定。1.位图扫描行与位图阵列的关系设记录一个扫描行的像素值需要n个字节，那么：位图阵列的0至n-1个字节记录了位图第一个扫描行的像素值；位图阵列的n至2n-1个字节记录了位图第二个扫描行的像素值；依次类推，位图阵列的〔m-1〕*n至m*n-1个字节记录了位图的第m个扫描行的像素值。位图阵列的大小为n*biHeight。当〔biWidth*biBitCount〕mod32=0时：n=(biWidth*biBitCount)/8当(biWidth*biBitCount)mod32!=0时：n=(biWidth*biBitCount)/8+4位图的每一个扫描行的字节数必须为4的倍数，上式中加4的原因是为了使一个扫描行的像素值占用位图阵列的字节数为4的倍数，缺乏的位用0来填充。2.位图像素值与位图阵列的关系设记录第m个扫描行的像素值的n个字节为：a0，a1...a(n-1)那么：当biBitCount=1时，a0字节记录了第m个扫描行的第1至第8个像素点，每个像素只占1位。当biBitCount=4时，a0字节记录了第m个扫描行的第1至第2个像素点，每个像素只占4位。当biBitCount=8时，a0字节记录了第m个扫描行的第1个像素点，一个像素只占一个字节。当biBitCount=24时，a0a1a2三个字节记录了第m个扫描行的第1个像素点，每个像当biBitCount=32时，a0a1a2a3四个字节记录了第m个扫描行的第1个像3.颜色表与位图阵列的关系通过上面的分析可知，对于biBitCount<=8位的位图，都需要有一个颜色表项来记录位图数据的颜色分量值。对于biBitCount=24或32的位图来说，那么不需要颜色表。在8位或8位以下的位图中，位图阵列记录的值实际上是每个像素点在颜色表中的索引值。该索引值与颜色表的联系：以256色位图为例，256色位图具有256个颜色表项。设取得位图阵列中一像素的值为28，即该像素的颜色值是颜色表项中索引值为28所对应的颜色。取值过程为：①确定索引值28在文件中位置，即54+28*4=166。②取值。以文件开头为起始，从第166个字节开始连续读取3个字节，这三个字节就是该像素点在位图阵列中的颜色RGB值。3.3格式转换通过前面的介绍，我们已经知道，设备厂商提供的DICOM图像的显示软件都是基于UNIX系统的。要在Windows平台下显示DICOM图像，需要将DICOM图像格式转换成Windows操作系统所支持的图像格式，如BMP、JPG、GIF等。因此，我们可以把DICOM图像显示的问题转化为DICOM格式和BMP、JPG和GIF格式的转化问题。一般转换原理根本相同，本文只研究DICOM格式转换为BMP格式[8][9][10]。转换思路1.格式转换的总体思路：首先，定义一些存储图像参数的变量，并将变量初始化；其次，按照传输语法格式要求，对DICOM文件的各相关数据元进行遍历，提取出0002组、0028组和7EF0组有用的数据元的内容，分别存入先前定义的变量，关闭DICOM文件；再将12位或16位的图像数据转换为8位灰度数据；最后，翻开一空白文件，按照BMP文件格式的要求，将从DICOM文件里提取出的数据写入新文件，格式转换完毕。对于上述数据元的读取，由于所需操作的数据元不多，我们采用双层Switch多分支选择结构分别对组号和单元号进行读取。外层Switch结构对数据组进行选择操作，内层Switch结构对数据单元进行操作。2.格式转换应注意的问题①获取图像信息，实际上是对DICOM文件中各数据元的遍历。数据元排列的顺序是按照标签的数值从小到大编码的，在遍历数据元时，有些数据元中所包含的信息与图像是无关的，为提高程序遍历的速度，只读取有用的数据元。②读取数据元〔0002，****〕时，该组的所有数据元的表示值VR都是显式表示的，即ExplicitVREndian。由于是小端字节序，首先应交换字节顺序。然后再按照VR的属性读取数据元值域的值。此外，要特别注意数据元〔0002，0010〕，该数据元的值确定了文件的传输语法，后面各组数据元的编码都是由传输语法来决定的。③由于要经常进行数据元值的读取，可以设计一些VR值读取函数，方便函数的调用。如VR为US、DS，那么读取函数为readUS()，readDs()。④像素数据元〔7FE0，0010〕里的像素数据一般都是16位或者12位的，可以通过斜率变换和窗口变换将原始数据转换成8位灰度数据。变量定义及初始化翻开一个DICOM文件按ExplicitLittleEndian读取数据元〔0002，0010〕，确定后续数据元传输语法按上一步骤确定的传输语法读取数据元，并将数据存入先前定义的变量，然后关闭文件将〔7EF0，0010〕的图像数据转换为8位灰度翻开一空白文件，按BMP格式将8位灰度数据连同文件头、信息头和颜色表写入空白文件DICOM到BMP格式转换完毕图3.5DICOM与BMP格式转换流程3.3.2转换类的定义在图像处理系统的开发过程中，设计了一个实现DICOM到BMP格式转换的类CDicomToBMP。该类对图像操作中的一些数据和方法进行了封装。ClassCDicomBMPDlg:publicCDialog{//ConstructionPublic: CDicomBMPDlg(CWnd*pParent=NULL); //standardconstructor//DialogData//{{AFX_DATA(CDicomBMPDlg)enum{IDD=IDD_DICOMBMP_DIALOG};int m_nConvertMode;//}}AFX_DATA//ClassWizardgeneratedvirtualfunctionoverrides//{{AFX_VIRTUAL(CDicomBMPDlg)protected:virtualvoidDoDataExchange(CDataExchange*pDX); //DDX/DDVsupport//}}AFX_VIRTUALpublic: //ReusableDICOMfilereadingmethods. //Purposefullymadestatic，withoutdependencyonmembervariables.staticvoidremoveTailingSpace(char*pszStr);//去除空格；staticvoidSwapWord(char*pArray，intnWords);//交换字节；staticvoidSwapDWord(char*pArray，intnDWords);//交换双字节；staticintreadUS(FILE*fp，DATA_ENDIANnDataEndian);//读无符号16位整数；staticlongintreadLength(FILE*fp，BOOLbImplicitVR，DATA_ENDIANnDataEndian);//读取值域长度；staticintreadIS(FILE*fp，BOOLbImplicitVR，DATA_ENDIANnDataEndian);//读取十进制整数字符；staticintreadString(FILE*fp，char*pszStr，BOOLbImplicitVR，DATA_ENDIANnDataEndian);//读取字符串；staticfloatreadDS(FILE*fp，BOOLbImplicitVR，DATA_ENDIANnDataEndian);//读取固定小数和浮点数字字符串；staticchar*convertTo8Bit(char*pData，longintnNumPixels，BOOLbSigned，shortnHighBit，floatfRescaleSlope，floatfRescaleIntercept，floatfWindowCenter，floatfWindowWidth);//将图像数据转换为8位数据；//Implementationprotected: HICONm_hIcon;intm_nFileFormat; CStringm_strFileName; CStringm_strFileDir;voidConvertDicomToBMP();intWriteBMPFile(char*pData，intnFrameSize，shortnCols，shortnRows，intnBytesP，char*pszPhotometric，intnFrameNum=0);在上面类的定义中，类CDicomBMP派生于基类Cobject，在VC++中，只有派生于Cobject基类的才有动态创立的功能。类的保护成员变量m_pFile存放格式转换后所得的BMP文件的文件头指针，以实现BMP文件的显示。m_pData、m_nRows、m_nCols存放图像的根本参数，它们对于外界上是不可见的。成员函数ConvertDicomBMP()将实现类的主要功能，是该类中最重要的函数之一。在读取DICOM文件时，经常会遇到字节顺序的调换，所以设计了两个函数SwapWord()和SwapDWord()来方便函数的调用。为了方便各类数据元值的读取，设计了如readUS()，readLength()等函数。另外，convertTo8Bit()函数将把16位或12位的图像数据转换成8位灰度数据。WriteBMPFile()函数把转换为8位的图像数据和位图文件头、信息头、颜色表一起写入BMP文件。转换算法下面给出函数ConvertDicomToBMP〔〕的算法和一些具体代码。函数的算法为：①变量定义及初始化；②翻开文件，假设成功，转③，假设失败，那么退出；③定位文件指针，从当前指针开始往后读取2个字节，判断是否为大端字节序列，假设是，那么交换字节，假设为小端字节，那么转4；④选择数据元组号，假设gTag=0002，转⑤，gTag=0028，转⑥，gTag=7EF0，转⑦，gTag为其它，那么返回③；⑤判断0002组是否已处理完，假设未处理完，那么从当前指针开始往后读取2个字节存入元素号变量，假设元素号为0010，那么读取该数据元值，确定传输语法，并设已处理完标志，返回③，假设元素号为其它，直接返回③；⑥判断0028组是否已处理完，假设未处理完，那么从当前指针开始往后读取2个字节存入元素号变量，判断元素号的值，进入各元素号的分支，读取数据存入相应变量，在将1053号读取完后，设已处理完标志。从每一分支退出后，均返回③；⑦判断7EF0组是否已处理完，假设未处理完，那么从当前指针开始往后读取2个字节存入元素号变量，假设元素号为0010，那么读取〔7EF0，0010〕像素数据元，返回③，假设元素号为其它，直接返回③；⑧关闭原文件。将上一步中读取的像素数据转换成8位灰度数据；⑨创立一空文件，按位图格式将文件头、信息头、颜色表项和上一步骤得到的8位数据写入空文件。函数实现的代码：voidCDicomBMPDlg::ConvertDicomToBMP(){shortintnCols=0，nRows=0;//图像的行数和列数；shortintnBitsAllocated；//图像数据的分配位数；shortintnSamplesPerPixel=1;//每个像素的采样次数； shortintnHighBit=0;//图像数据的高位； floatfWindowWidth=0，fWindowCenter=0，fRescaleSlope=1，fRescaleIntercept=0;//窗位特征； BOOLbIsSigned=FALSE; BOOLbGroup2Done=FALSE，bGroup28Done=FALSE，bPixelDataDone=FALSE;intnBytesP=0;//每像素所占的字节数； intnFrameSize=0;//每帧图像的大小； longintnLength;//图像总字节数； constchar*pszFileName=m_strFileName.GetBuffer(3); charszPhotometric[32]=""，szTemp[32]=""，szTransferSyntaxUID[80]="";//存储传输语法的字符数组；BOOLbImplicitVR=TRUE;//是否为隐式表示值； COMPRESSION_MODEnCompressionMode=COMPRESS_NONE;//压缩模式； DATA_ENDIANnDataEndian=LITTLE_ENDIAN;//初始值为小端字节序； inti; intnBytes;FILE*fp;//原文件指针；char*pData=0;//指向图像数据的指针；shortintgTag，eTag;//标签的组号和元素号；intnNumFrames=1;//帧数，初始值为1；函数的开始定义了一些变量，用于存储图像根本参数和图像数据。fp=fopen(pszFileName，"rb");//翻开文件；if(!fp)//判断是否翻开；{AfxMessageBox("Failedtoopenfileforread.");return;}while(fread(&gTag，sizeof(short)，1，fp)==1){ if(nDataEndian==BIG_ENDIAN)//判断字节顺序； SwapWord((char*)&gTag,1);switch(gTag)//实现组号判断；{ case0x0002://Metaheader. if(bGroup2Done) break; fread(&eTag,sizeof(short),1,fp);…… bGroup2Done=TRUE;//处理标志； break; } break;上述为文件的读取。程序采用了循环结构和多支选择结构。首先，翻开文件，如失败那么返回失败信息；接着，用一个whiledo结构反复的读取文件，在循环体内，先用条件语句判断字节顺序，假设为大端字节序，那么交换。然后进入嵌套的多支选择结构，外层switch结构实现组号判别，内层结构实现元素号判别。上面的程序对数据元〔0002，0010〕进行判别来确定该文件采用的什么传输语法。变量bGroup2Done作为处理标志，假设bGroup2Done=TRUE，程序将直接跳出switch结构，进入下一次循环。case0x0008://特征参数组fread(&eTag，sizeof(short)，1，fp); if(nDataEndian==BIG_ENDIAN) SwapWord((char*)&eTag，1);if((eTag==0x0005)||(eTag==0x0008)) bGroup2Done=TRUE; break;0008组作为特征参数组，与图像信息没有联系。case0x0028://图像信息参数组fread(&eTag，sizeof(short)，1，fp);if(bGroup28Done) break;if(nDataEndian==BIG_ENDIAN) SwapWord((char*)&eTag，1);switch(eTag){……}break;上述是图像信息参数组的读取。图像信息参数组的相关图像信息已读取到内存变量中了，这里有一些关于数据元值读取的函数：//读取无符号16位整数intCDicomBMPDlg::readUS(FILE*fp，DATA_ENDIANnDataEndian){……return(int)nVal;}//读取值域长度longintCDicomBMPDlg::readLength(FILE*fp，BOOLbImplicitVR，DATA_ENDIANnDataEndian){…… returnnValLength;}//读取十进制整数字符intCDicomBMPDlg::readIS(FILE*fp，BOOLbImplicitVR，DATA_ENDIANnDataEndian){…… returnnVal;}//读取固定小数和浮点数字符串floatCDicomBMPDlg::readDS(FILE*fp，BOOLbImplicitVR，DATA_ENDIANnDataEndian){…… returnfVal;}//读取字符串intCDicomBMPDlg::readString(FILE*fp，char*pszStr，BOOLbImplicitVR，DATA_ENDIANnDataEndian){…… return0;}下面程序为图像数据的读取。case0x7fe0:fread(&eTag，sizeof(short)，1，fp); if(bPixelDataDone) break; if(nDataEndian==BIG_ENDIAN) SwapWord((char*)&eTag，1);if(eTag==0x0010){…… } if(pData) break;//Wearedone.}fclose(fp);到此为止，图像数据已经被读取到字符指针pData所指向的内存里。图像数据有不同的编码格式，如自然格式、RLE压缩格式、JPEGLOSSY压缩格式等。本文只给出了自然格式的图像数据读取。数据读取完毕，关闭文件。DICOM图像数据一般是12位或16位的，要转换成BMP位图，还应进行移位、截取、窗位变换等。成员函数convertTo8Bit()将指针pData指向的图像是数据转换成8位灰度图像数据，该成员函数的参数已从0028组的数据元里读取。函数定义和实现的程序如下：char*CDicomBMPDlg::convertTo8Bit(char*pData，longintnNumPixels，BOOLbIsSigned，shortnHighBit， floatfRescaleSlope，floatfRescaleIntercept， floatfWindowCenter，floatfWindowWidth){…… } return(char*)pNewData;接下来是将转换后的8位灰度图像数据写入BMP位图文件。int CDicomBMPDlg::WriteBMPFile(char*pData，intnFrameSize，shortnCols，shortnRows，intnBytesP，char*pszPhotometric，intnFrameNum){BITMAPFILEHEADERbf;//文件头； BITMAPINFOHEADERbi;//文件信息头； intnPaletteSize=sizeof(RGBQUAD)*256;//调色板；char/*szBMPFileName[512]，*/*cc; FILE*fp;…… } fclose(fp);return0;}以上列出的函数简要描述了从DICOM图像数据到BMP数据的转换过程。该转换过程大致分为三个局部 ：文件读取，包括图像根本参数信息、图像数据的读取；图像数据的变换：12或16位DICOM图像数据转换为8位灰度数据；将变换后的8位图像数据连同位图文件头、信息头、颜色表一起写入BMP位图文件。第四章图像显示经过前面的格式转换后，DICOM图像的显示问题也就转换为BMP位图的显示问题，BMP位图在Windows环境下的显示非常简单，但其显示技术是数字图像编程的根底，下面介绍一下位图在Windows环境下的显示原理及方法。4.1位图原理4.1.1DDB位图DDB位图即设备相关位图，又称GDI位图。它依赖于设备与MFC中的Cbitmap类相对应，它们在内存中的结构和位置依赖于管理它的设备驱动程序。DDB不包含颜色信息，显示图像依赖于系统硬件，它的优点是显示简单、迅速，但也因为依赖于设备，使得这种位图不能通过磁盘或其它媒介与其它计算机实现文件共享，限制了它的应用。结构BITMAP定义了DDB位图的类型、宽度、高度、颜色格式和像素位置。该结构在Windows中定义如下[11]：TypedefstructtagBITMAP{IntbmType;//位图类型，必须设置为0；IntbmWidth;//位图高度；IntbmHeight;//位图宽度；IntbmWidthBytes;//位图中每一扫描行中的字节数；BYTEbmPlanes;//颜色层数；BYTEbmBitsPixel;//每一像素所占的位数；VoidFAR*bmBits;//存放像素值内存块的地址；}BITMAP;图形设备接口GDI，组成了Windows操作系统的核心局部。GDI管理Windows程序的所有图形输出。也就是说GDI提供高层绘图函数，这些函数无论根底硬件如何，都能够生成相同结果。将图形函数和硬件分开，能够使程序员无须考虑硬件支持，就能生成有趣的图形。设备上下文DC，是由GDI创立的用来代表设备连接的数据结构。Windows的设备无关性使我们无法直接对硬件进行操作，因此必须借助它来连接应用程序和设备驱动程序，以便实现诸如访问内存等功能。4.1.2DIB位图DIB位图是一种与设备无关的位图。它可以在不同的机器或系统中显示位图所固有的图像。与DDB相比，DIB是一种外部的位图格式，DIB之所以独立于设备，是因为它包含了一个名为RGBQUAD的结构，描述了DIB位图对应的逻辑调色板的颜色表，其像素值是该调色板中的颜色索引值。当一幅DIB位图传输到另一台计算机时，该计算机显示它时只需要根据这幅DIB的颜色表“按图索骥〞就行了，而不必关心是否与当前的硬件配置相吻合。经常存储为以BMP为后缀的位图文件〔有时也以DIB为后缀〕。DIB位图还支持图像数据的压缩。4.2位图的显示方法方法一：把位图作为一种资源包含在可执行模块中这是一种最简单的方法，也是最不灵活的方法，在编程阶段就已经把要处理的位图给固定下来，程序运行时没有动态选择能力，简单表现为屏蔽掉了文件格式信息，只要把位图文件作为资源插入到工程中，以后的处理都只跟资源ID有关。如果在程序中需要的是假设干固定的位图，资源方式包含在可执行模块中是一种很好的选择，它减少了文件个数，表达了整体性。显示实现的具体步骤：1.创立位图对象HBITMAPhBmp=::LoadBitmap()2.获得位图描述结构BITMAPbitmap;GetObject()3.选入内存设备上下文HDChdc=::GetDC()HDChMeDC=::CreateCompati