jpg和jpeg是有损压缩
bmp是位图
gif是无损压缩，一般用于动画
BMP位图格式（文件扩展名为BMP）
它是用于WINDOWS和OS／2的位图（BITMAP）格式，文件几乎不压缩，占用磁盘空间较大，它的颜色存储格式有1位、4位、8位及24位。开发WINDO－WS环境下的软件时，BMP格式是最不容易出问题的格式，并且DOS与WINDO－WS环境下的图象处理软件都支持该格式，因此，该格式是当今应用比较广泛的一种格式。但缺点是该格式文件比较大，所以只能应用在单机上，不受网络欢迎。
COMPUSERVE GIF格式（文件扩展名为GIF）
这种格式是由COMPUSERVER公司设计的，GIF是GRAPHICS INTER CHA－NGE FORMAT的缩写，分为87a及89a两种版本，存储格式由1位到8位。GIF格式是经过压缩的格式，磁盘空间占用较少。由于它是制作2D动画软件Animator早期支持的文件格式，所以该格式曾被广泛使用。但由于8位存储格式的限制，使其不能存储超过256色的图象。虽然如此，但该图形格式却在Internet上被广泛地应用，原因主要有两个：1、256种颜色已经较能满足Internet上的主页图形需要。2、该格式生成的文件比较地小，适合像Internet这样的网络环境传输和使用。
意思相同，就像htm和html是同一意思一样，
JPEG＝JPG是Joint Photographic Experts Group(联合图像专家组)的缩写，文件后辍名为"．jpg"或"．jpeg"，是最常用的图像文件格式，由一个软件开发联合会组织制定，是一种有损压缩格式，能够将图像压缩在很小的储存空间，图像中重复或不重要的资料会被丢失，因此容易造成图像数据的损伤。尤其是使用过高的压缩比例，将使最终解压缩后恢复的图像质量明显降低，如果追求高品质图像，不宜采用过高压缩比例。但是JPEG压缩技术十分先进，它用有损压缩方式去除冗余的图像数据，在获得极高的压缩率的同时能展现十分丰富生动的图像，换句话说，就是可以用最少的磁盘空间得到较好的图像品质。而且 JPEG是一种很灵活的格式，具有调节图像质量的功能，允许用不同的压缩比例对文件进行压缩，支持多种压缩级别，压缩比率通常在10：1到40：1之间，压缩比越大，品质就越低；相反地，压缩比越小，品质就越好。比如可以把1．37Mb的BMP位图文件压缩至20．3KB。当然也可以在图像质量和文件尺寸之间找到平衡点。JPEG格式压缩的主要是高频信息，对色彩的信息保留较好，适合应用于互联网，可减少图像的传输时间，可以支持24bit真彩色，也普遍应用于需要连续色调的图像。
JPEG格式是目前网络上最流行的图像格式，是可以把文件压缩到最小的格式，在 Photoshop软件中以JPEG格式储存时，提供11级压缩级别，以0—10级表示。其中0级压缩比最高，图像品质最差。即使采用细节几乎无损的10 级质量保存时，压缩比也可达 5：1。以BMP格式保存时得到4．28MB图像文件，在采用JPG格式保存时，其文件仅为178KB，压缩比达到24：1。经过多次比较，采用第8级压缩为存储空间与图像质量兼得的最佳比例。
PNG是20世纪90年代中期开始开发的图像文件存储格式，其目的是企图替代GIF和TIFF文件格式，同时增加一些GIF文件格式所不具备的特性。流式网络图形格式(Portable Network Graphic Format，PNG)名称来源于非官方的“PNG's Not GIF”，是一种位图文件(bitmap file)存储格式，读成“ping”。PNG用来存储灰度图像时，灰度图像的深度可多到16位，存储彩色图像时，彩色图像的深度可多到48位，并且还可存储多到16位的α通道数据。PNG使用从LZ77派生的无损数据压缩算法。
PNG图片文件一般应用于JAVA程序中，或网页或S60程序中是因为它压缩比高，生成文件容量小。
----
DIB位图文件dib
DIB，全称Device Independent Bitmap，设备无关位图文件，这是一种文件格式，其目的是为了保证用某个应用程序创建的位图图形可以被其它应用程序装载或显示一样。
DIB(Device-indepentent bitmap)的与设备无关性主要体现在以下两个方面：
DIB的颜色模式与设备无关。例如，一个256色的DIB即可以在真彩色显示模式下使用，也可以在16色模式下使用。
256色以下(包括256色)的DIB拥有自己的颜色表，像素的颜色独立于系统调色板。
由于DIB不依赖于具体设备，因此可以用来永久性地保存图象。DIB一般是以*.BMP文件的形式保存在磁盘中的，有时也会保存在*.DIB文件中。运行在不同输出设备下的应用程序可以通过DIB来交换图象。
DIB还可以用一种RLE算法来压缩图像数据，但一般来说DIB是不压缩的。
DIB的结构
与Borland C++下的框架类库OWL不同，MFC未提供现成的类来封装DIB。尽管Microsoft列出了一些理由，但没有DIB类确实给MFC用户带来很多不便。用户要想使用DIB，首先应该了解DIB的结构。
在内存中，一个完整的DIB由两部分组成：一个BITMAPINFO结构和一个存储像素阵列的数组。BITMAPINFO描述了位图的大小，颜色模式和调色板等各种属性，其定义为
typedef struct tagBITMAPINFO {
BITMAPINFOHEADER bmiHeader;
RGBQUAD bmiColors[1]; //颜色表
} BITMAPINFO;
RGBQUAD结构用来描述颜色，其定义为
typedef struct tagRGBQUAD {
BYTE rgbBlue; //蓝色的强度
BYTE rgbGreen; //绿色的强度
BYTE rgbRed; //红色的强度
BYTE rgbReserved; //保留字节，为0
} RGBQUAD;
注意，RGBQUAD结构中的颜色顺序是BGR，而不是平常的RGB。
BITMAPINFOHEADER结构包含了DIB的各种信息，其定义为
typedef struct tagBITMAPINFOHEADER{
DWORD biSize; //该结构的大小
LONG biWidth; //位图的宽度(以像素为单位)
LONG biHeight; //位图的高度(以像素为单位)
WORD biPlanes; //必须为1
WORD biBitCount //每个像素的位数(1、4、8、16、24或32)
DWORD biCompression; //压缩方式，一般为0或BI_RGB (未压缩)
DWORD biSizeImage; //以字节为单位的图象大小(仅用于压缩位图)
LONG biXPelsPerMeter; //以目标设备每米的像素数来说明位图的水平分辨率
LONG biYPelsPerMeter; //以目标设备每米的像素数来说明位图的垂直分辨率
DWORD biClrUsed; /*颜色表的颜色数，若为0则位图使用由biBitCount指定的最大颜色数*/
DWORD biClrImportant; //重要颜色的数目，若该值为0则所有颜色都重要
} BITMAPINFOHEADER;
与DDB不同，DIB的字节数组是从图象的最下面一行开始的逐行向上存储的，也即等于把图象倒过来然后在逐行扫描。另外，字节数组中每个扫描行的字节数必需是4的倍数，如果不足要用0补齐
DIB可以存储在*.BMP或*.DIB文件中。DIB文件是以BITMAPFILEHEADER结构开头的，该结构的定义为
typedef struct tagBITMAPFILEHEADER {
WORD bfType; //文件类型，必须为"BM"
DWORD bfSize; //文件的大小
WORD bfReserved1; //为0
WORD bfReserved2; //为0
DWORD bfOffBits; //存储的像素阵列相对于文件头的偏移量
} BITMAPFILEHEADER;
紧随该结构的是一个BITMAPINFOHEADER结构，然后是RGBQUAD结构组成的颜色表(如果有的话)，文件最后存储的是DIB的像素阵列。
DIB的颜色信息储存在自己的颜色表中，程序一般要根据颜色表为DIB创建逻辑调色板。在输出
一幅DIB之前，程序应该将其逻辑调色板选入到相关的设备上下文中并实现到系统调色板中，然后再调用相关的GDI函数
(如::SetDIBitsToDevice或::StretchDIBits)输出DIB。在输出过程中，GDI函数会把DIB转换成DDB，这项工作
主要包括以下两步：
将DIB的颜色格式转换成与输出设备相同的颜色格式。例如，在真彩色的显示模式下要显示一个256色的DIB，则应该将其转换成24位的颜色格式。
将DIB像素的逻辑颜色索引转换成系统调色板索引。
编写DIB类
由于MFC未提供DIB类，用户在使用DIB时将面临繁重的Windows
API编程任务。幸运的是，Visual
C++提供了一个较高层次的API，简化了DIB的使用。这些API函数实际上是由MFC的DibLook例程提供的，它们位于DibLook目录下的
dibapi.cpp、myfile.cpp和dibapi.h文件中，主要包括：
ReadDIBFile //把DIB文件读入内存
SaveDIB //把DIB保存到文件中
CreateDIBPalette //从DIB中创建一个逻辑调色板
PaintDIB //显示DIB
DIBWidth //返回DIB的宽度
DIBHeight //返回DIB的高度
DIB区块
DIB区块
DIB能拥有几种色彩组织中的一种，DDB必须是单色的或是与真实输出设备相同的格式。DIB
是一个档案或记忆体块；DDB是GDI点阵图物件并由点阵图代号表示。DIB能被显示或转换为DDB并转换回DIB，但是这里包含了装置无关位元和设备相
关位元之间的转换程序。
现在您将遇到一个函式，它打破了这些规则。该函式在32位元Windows版本中发表，称为CreateDIBSection，语法为：
hBitmap = CreateDIBSection (
hdc, // device context handle
pInfo, // pointer to DIB information
fClrUse, // color use flag
ppBits, // pointer to pointer variable
hSection, // file-mapping object handle
dwOffset) ; // offset to bits in file-mapping object
CreateDIBSection是Windows API中最重要的函式之一（至少在使用点阵图时），然而您会发现它很深奥并难以理解。
让我们从它的名称开始，我们知道DIB是什么，但「DIB
section」到底是什么呢？当您第一次检查CreateDIBSection时，可能会寻找该函式与DIB区块工作的方式。这是正确
的，CreateDIBSection所做的就是建立了DIB的一部分（点阵图图素位元的记忆体块）。
现在我们看一下传回值，它是GDI点阵图物件的代号，这个传回值可能是该函式呼叫最会拐人的部
分。传回值似乎暗示著CreateDIBSection在功能上与CreateDIBitmap相同。事实上，它只是相似但完全不同。实际上，从
CreateDIBSection传回的点阵图代号与我们在本章和上一章遇到的所有点阵图建立函式传回的点阵图代号在本质上不同。
一旦理解了CreateDIBSection的真实特性，您可能觉得奇怪为什么不把传回值定义
得有所区别。您也可能得出结论：CreateDIBSection应该称之为CreateDIBitmap，并且如同我前面所指出的
CreateDIBitmap应该称之为CreateDDBitmap。
首先让我们检查一下如何简化CreateDIBSection，并正确地使用它。首先，把最後
两个参数hSection和dwOffset，分别设定为NULL和0，我将在本章最後讨论这些参数的用法。第二，仅在fColorUse参数设定为
DIB_
PAL_COLORS时，才使用hdc参数，如果fColorUse为DIB_RGB_COLORS（或0），hdc将被忽略（这与
CreateDIBitmap不同，hdc参数用於取得与DDB相容的设备的色彩格式）。
因此，CreateDIBSection最简单的形式仅需要第二和第四个参数。第二个参数是指向BITMAPINFO结构的指标，我们以前曾使用过。我希望指向第四个参数的指标定义的指标不会使您困惑，它实际上很简单。
假设要建立每图素24位元的384×256位元DIB，24位元格式不需要色彩对照表，因此它是最简单的，所以我们可以为BITMAPINFO参数使用BITMAPINFOHEADER结构。
您需要定义三个变数：BITMAPINFOHEADER结构、BYTE指标和点阵图代号：
BITMAPINFOHEADER bmih ;
BYTE * pBits ;
HBITMAP hBitmap ;
现在初始化BITMAPINFOHEADER结构的栏位
bmih->biSize = sizeof (BITMAPINFOHEADER) ;
bmih->biWidth = 384 ;
bmih->biHeight = 256 ;
bmih->biPlanes = 1 ;
bmih->biBitCount = 24 ;
bmih->biCompression = BI_RGB ;
bmih->biSizeImage = 0 ;
bmih->biXPelsPerMeter = 0 ;
bmih->biYPelsPerMeter = 0 ;
bmih->biClrUsed = 0 ;
bmih->biClrImportant = 0 ;
在基本准备後，我们呼叫该函式：
hBitmap = CreateDIBSection (NULL, (BITMAPINFO *) &bmih, 0, &pBits, NULL, 0) ;
注意，我们为第二个参数赋予BITMAPINFOHEADER结构的位址。这是常见的，但一个BYIE指标pBits的位址，就不常见了。这样，第四个参数是函式需要的指向指标的指标。
这是函式呼叫所做的：CreateDIBSection检查BITMAPINFOHEADER
结构并配置足够的记忆体块来载入DIB图素位元。（在这个例子里，记忆体块的大小为384×256×3位元组。）它在您提供的pBits参数中储存了指向
此记忆体块的指标。函式传回点阵图代号，正如我说的，它与CreateDIBitmap和其他点阵图建立函式传回的代号不一样。
然而，我们还没有做完，点阵图图素是未初始化的。如果正在读取DIB档案，可以简单地把pBits参数传递给ReadFile函式并读取它们。或者可以使用一些程式码「人工」设定。
-----
Tiff图像文件
标签图像文件格式 文件扩展名: .tiff, .tif
开发者: Aldus
格式类型: 图像文件格式
标签图像文件格式(Tagged Image File Format，简写为TIFF) 是一种主要用来存储包括照片和艺术图在内的图像的文件格式。它最初由 Aldus公司与微软公司一起为PostScript打印开发。TIFF与JPEG和PNG一起成为流行的高位彩色图像格式。 TIFF格式在业界得到了广泛的支持，如Adobe公司的Photoshop、Jasc的GIMP、Ulead PhotoImpact和Paint Shop Pro等图像处理应用、QuarkXPress和Adobe InDesign这样的桌面印刷和页面排版应用，扫描、传真、文字处理、光学字符识别和其它一些应用等都支持这种格式。从 Aldus 获得了 PageMaker 印刷应用程序的 Adobe 公司现在控制着 TIFF 规范。
术语“Tagged Image File Format”或者“Tag Image File Format”在一些早期的TIFF规范中是作为副标题存在的。目前的TIFF规范TIFF 6.0不再使用这些术语，现在的名字仅仅叫做“TIFF”。
TIFF最初的设计目的是为了1980年代中期桌面扫描仪厂商达成一个公用的扫描图像文件格式，而不是每个厂商使用自己专有的格式。在刚开始的时候， TIFF只是一个二值图像格式，因为当时的桌面扫描仪只能处理这种格式。随着扫描仪的功能越来越强大，并且桌面计算机的磁盘空间越来越大，TIFF逐渐支持灰阶图像和彩色图像。
灵活的选项
TIFF 是一个灵活适应性强的文件格式。通过在文件头中包含“标签”它能够在一个文件中处理多幅图像和数据。标签能够标明图像的如图像大小这样的基本几何尺寸或者 定义图像数据是如何排列的并且是否使用了各种各样的图像压缩选项。例如，TIFF可以包含JPEG和行程长度编码压缩的图像。TIFF文件也可以包含基于 矢量的裁剪区域（剪切或者构成主体图像的轮廓）。使用无损格式存储图像的能力使TIFF文件成为图像存档的有效方法。与JPEG不同，TIFF文件可以编 辑然后重新存储而不会有压缩损失。其它的一些TIFF文件选项包括多层或者多页。
尽管现今它是一种被广泛接受的标准格式，当TIFF最初出现的时候，它的可扩展性带来了很多兼 容问题。程序员可以随意定义新的标签和选项，但是并不是所有的实现程序都能支持这些所有这些创造出的标签。作为结果，它的一个最小特性集成为了“这 个”TIFF，即使是在今天大量的TIFF文件和读取它们的代码都是基于简单的32位非压缩图像。
TIFF有一个使用LZW压缩的选项，这是一种减小文件大小的无损技术，但是这项技术在不同的 司法权限内为几个专利所涵盖。到了2005年，除了一个之外这些专利都已经到期，其中包括Unisys所拥有的广为人知又有很多争议的专利。另外一个著名 的专利是IBM拥有的将在2006年8月11日到期的专利，IBM也没有要加强它的意思（who has shown no interest to date in enforcing it）。
每个TIFF文件都是从指示字节顺序的两个字节开始的。“II”表示小字节在先、“MM”表示 大字节在先字节顺序。后面的两个字节表示数字42。数字42是“为了它的deep philosophical significance"而选择的。 42的读法取决于头两个字节所表示的字节顺序。整个文件根据所指出的字节顺序进行读取。
字节顺序在Apple Macintosh和微软视窗程序之间可能产生兼容性的问题，它们通常为TIFF文件使用不同的字节顺序。一些程序提供了保存为Mac或者是Windows字节顺序的选项以使文件能在交叉平台使用。
文档图像中的TIFF
TIFF格式是文档图像和文档管理系统中的标准格式。在这种环境中它通常使用支持黑白（也称为二值或者单色）图像的CCITT Group IV 2D压缩。在大量生产的环境中，文档通常扫描成黑白图像（而不是彩色或者灰阶图像）以节约存储空间。A4大小200dpi（每英寸点数分辨率）扫描结果平 均大小是30KB，而300dpi的扫描结果是50KB。300dpi比200dpi更加常用。
由于TIFF格式支持多页，多页文件能够存在一个TIFF文件中而不是让每个扫描页存在一系列的文件中。