天天看點
傳回

常見圖檔格式詳解

做了幾年有關圖形、圖像的工作，對圖檔格式算是小有經驗，在此寫成一文章總結下。雖然一開始并不想講很理論的東西，但寫完後發現幾乎全是理論，細想一下關于圖檔格式的知識本身就是理論的東西，囧~~ 那就力求用最簡單的方式将這些“理論”講清楚吧。

常見的圖檔格式有bmp, jpg(jpeg), png, gif, webp等。

圖像基本資料結構

 要講圖檔格式還先得從圖像的基本資料結構說起。在計算機中, 圖像是由一個個像素點組成，像素點就是顔色點，而顔色最簡單的方式就是用RGB或RGBA表示, 如圖所示

常見圖檔格式詳解

(圖1)

常見圖檔格式詳解

(圖2)

如果有A通道就表明這個圖像可以有透明效果。

R,G,B每個分量一般是用一個位元組(8位)來表示，是以圖(1)中每個像素大小就是3*8=24位圖, 而圖(2)中每個像素大小是4*8=32位。

這裡有三點需要說明:

一、圖像y方向正立或倒立

圖像是二維資料，資料在記憶體中隻能一維存儲，二維轉一維有不同的對應方式。比較常見的隻有兩種方式: 按像素“行排列”從上往下或者從下往上。

常見圖檔格式詳解

如圖所示的圖像有9個像素點，如果從上往下排列成一維資料是(123456789)， 如果是從下往上排列則為(789456123)。

隻是以會有這種差別是因為，前一種是以計算機圖形學的螢幕坐标系為參考(右上為原點,y軸向下 )，而另後一種是以标準的數學坐标系為參考(右下為原點,y軸向上)。這兩個坐标系隻是y值不一樣，互相轉換的公式為:

y2 = height-1-y1

y1,y2分别為像素在兩個坐标系中的y坐标，height為圖像的高度。

不過好像隻有bmp圖檔格式以及windows下的GDI，GDI+是從下往上排列，其它比如DirectX,OpenGL,Cocoa(NSImage, UIImage),OpenCV等都是從上往下排列。

二、RGB排列順序

不同圖形庫中每個像素點中RGBA的排序順序可能不一樣。上面說過像素一般會有RGB,或RGBA四個分量，那麼在記憶體中RGB的排列就有6種情況，如下:

  • RGB
  • RBG
  • GRB
  • GBR
  • BGR
  • BRG

RGBA的排列有24種情況，這裡就不全部列出來了。

不過一般隻會有RGB,BGR, RGBA, RGBA, BGRA這幾種排列據。 絕大多數圖形庫或環境是BGR/BGRA排列，cocoa中的NSImage或UIImage是RGBA排列。

三、像素32位對齊

如果是RGB24位圖，會存在一個32位對齊的問題——

在x86體系下，cpu一次處理32整數倍的資料會更快，圖像進行中經常會按行為機關來處理像素。24位圖，寬度不是4的倍數時，其行位元組數将不是32整數倍。這時可以采取在行尾添加備援資料的方式，使其行位元組數為32的倍數。

比如，如果圖像寬為5像素，不做32位對齊的話，其行位數為24*5=120，120不是32的倍數。是32整數倍并且剛好比120大的數是128，也就隻需要在其行尾添加1位元組(8位)的備援資料即可。(一個以空間換時間的例子)

有個公式可以輕松計算出32位對齊後每行應該占的位元組數

byteNum = ((width * 24 + 31) & ~31)>>3;

注意結果是位元組數，如果想知道位數，還得x8

圖檔格式的必要性

如果将圖像原始格式直接存儲到檔案中将會非常大，比如一個5000*5000 24位圖，所占檔案大小為5000*5000*3位元組=71.5MB, 其大小非常可觀。

如果用zip或rar之類的通用算法來壓縮像素資料，得到的壓縮比例通常不會太高，因為這些壓縮算法沒有針對圖像資料結構進行特殊處理。

于是就有了jpeg,png等格式，同樣是圖像壓縮算法jpeg和png也有不同的适用場景，具體在下文再闡述。

常見圖檔格式詳解

是以可以總結如下: jpeg,png檔案之于圖像，就相當于zip,rar格式之于普通檔案(用zip,rar格式對普通檔案進行壓縮)。

BMP格式

bmp格式沒有壓縮像素格式，存儲在檔案中時先有檔案頭、再圖像頭、後面就都是像素資料了，上下颠倒存儲。

用windows自帶的mspaint工具儲存bmp格式時，可以發現有四種bmp可供選擇：

單色: 一個像素隻占一位，要麼是0，要麼是1，是以隻能存儲黑白資訊

16色位圖: 一個像素4位，有16種顔色可選

256色位圖: 一個像素8位，有256種顔色可選

24位位圖: 就是圖(1)所示的位圖，顔色可有2^24種可選，對于人眼來說完全足夠了。

這裡為了簡單起見，隻詳細讨論最常見的24位圖的bmp格式。

現在來看其檔案頭和圖檔格式頭的結構:

 　　　　　　　　　　　　　　　　　　　　　　

檔案頭資訊
字段 大小(位元組) 描述
bfType 2 一定為19778，其轉化為十六進制為0x4d42，對應的字元串為BM
bfSize 4 檔案大小
 bfReserved1 2  一般為0 
 bfReserved2
 bfOffBits  4  從檔案開始處到像素資料的偏移，也就是這兩個結構體大小之和
bmp圖檔結構頭
 字段 大小(位元組)  描述 
 biSize 此結構體的大小 
 biWidth  圖像的寬
biHeight  圖像的高 
biPlanes   2 圖像的幀數，一般為1 
biBitCount  一像素所占的位數，一般是24
biCompression 
biSizeImage  像素資料所占大小，即上面結構體中檔案大小減去偏移(bfSize-bfOffBits) 
biXPelsPerMeter   一般為0
  一般為0
biClrUsed 
biClrImportant 

本來在windows平台下wingdi.h檔案中已經有這些結構的定義，不過為了不依賴與windows，實作為跨平台，本人将wingdi.h中的這兩個結構“偷用”出來了。代碼如下：

常見圖檔格式詳解

Bmp結構體

由于bmp格式比較簡單，本人已實作了一份簡單的c++代碼，具有讀取、儲存bmp圖檔的功能，隻支援24位的bmp格式。

代碼在  的“常見圖檔格式詳解/ImageDemo/BmpDemo”檔案夾中。

雖然這裡隻建立了vs2008項目，但代碼在linux, mac平台下都可以編譯通過。

需要說明的是為了統一處理，将bmp讀取到LBitmap::m_pixel中時就将其轉化為32位從上往下排列的圖像格式了。并且會有y坐标的轉化。

是以在讀取的時候會有一個temp_line先存儲檔案中的24位資料，再轉化為32位資料。在儲存時也是先将32位資料轉化到temp_line的24位資料上，然後再寫入檔案。(如果僅僅是處理bmp，那麼這麼多的一個A通道是備援資料，但後面處理png圖檔時就會用到這個A通道)

如果用上面的代碼來讀取如圖所示的圖檔(放大8倍後的顯示圖):

常見圖檔格式詳解

右上角像素為RGB(255, 128, 0)

1 ln::LBitmap bmp;
2 bmp.ReadBmp(L"one.bmp");
3 unsigned char *p = bmp.Pixel(0, 0);
4 printf("%d, %d, %d\n", p[0], p[1], p[2]); //顯示左上角的像素值
5 bmp.WriteBmp(L"out.bmp");                 //儲存到檔案，可以測試是否能正确讀取和儲存bmp

運作的結果為: 0,128,255

可以看出像素分布為BGR

ps:

  • bmp格式也是可以壓縮.

  • bmp格式也可以有顔色闆。顔色闆就是一個顔色的索引，上面說過bmp格式一個像素可以隻有2個,16個或256個取值。就拿單色位圖來說明，預設為0對應RGB(0,0,0) 1,對應RGB(255, 255, 255)

    如果顔色闆這樣定義: 

    0對應 RGB(255,0, 0)紅

    1對應 RGB(0, 255, 0)綠

    這樣黑白圖就成了紅綠圖

JPEG格式

  1. jpeg是有損壓縮格式, 将像素資訊用jpeg儲存成檔案再讀取出來，其中某些像素值會有少許變化。在儲存時有個品質參數可在[0,100]之間選擇，參數越大圖檔就越保真，但圖檔的體積也就越大。一般情況下選擇70或80就足夠了。
  2. jpeg沒有透明資訊。
  3. jpeg比較适合用來存儲相機拍出來的照片，這類圖像用jpeg壓縮後的體積比較小。其使用的具體算法核心是離散餘弦變換、Huffman編碼、算術編碼等技術，有興趣的同學可以在網上找一大堆資料，本文就不詳細介紹了。

接下來要介紹一個有關jpeg非常實用的技術——

jpeg格式支援不完全讀取整張圖檔，即可以選擇讀取原圖、1/2、1/4、1/8大小的圖檔

比如5000*5000的一張大圖，可以隻讀取将其縮小成1/8後即625*625大小的圖檔。 這樣比先完全讀取5000*5000的圖像，再用算法縮小成625*625大小不知快多少倍。

如果應用需求隻需要一張小圖時，這種讀取方式就可以大顯身手了。

在c代碼中讀取jpeg一般是使用libjpeg, 這個庫提供了不完全讀取圖檔的功能。

給ln::LBitmap添加有關jpeg的接口，如下ReadJpeg()第三個參數fraction可取值為1,2,4,8，分别對應1/1,1/2,1/4,1/8

常見圖檔格式詳解

JpegAPI

具體的實作在JpegDemo

用上面的函數進行jpeg的讀取和儲存的測試

常見圖檔格式詳解
```
ln::LBitmap bmp;
bmp.ReadBmp(L"one.bmp");
unsigned char *p = bmp.Pixel(0, 0);
printf("%d, %d, %d\n", p[0], p[1], p[2]);
bmp.WriteJpeg(L"one.jpg", 90);
```
常見圖檔格式詳解

讀取one.bmp圖檔，然後儲存成jpeg格式，one.jpg放大後顯示如下

常見圖檔格式詳解

發現左上角的顔色發生了變化，并且也影響到周圍的像素，就算将上面WriteJpeg()第二個參數換成100，也還是這種效果，這是Jpeg格式無法避免的問題

但如果讀取一張風景照，再儲存成Jpeg，就幾乎看不出有什麼差别了。

android平台下實作jpeg預讀

常見圖檔格式詳解
BitmapFactory.Options opt = new BitmapFactory.Options();
opt.inJustDecodeBounds = true;
BitmapFactory.decodeFile(info.fullPath, opt); //這裡僅僅隻讀取jpeg的大小
opt.inJustDecodeBounds = false;
if (opt.outWidth > opt.outHeight) {
    opt.inSampleSize = opt.outWidth / phSize;//hpSize是允許的圖檔寬高的最大值
} else {
    opt.inSampleSize = opt.outHeight / phSize;
}
Bitmap b = BitmapFactory.decodeFile(info.fullPath, opt);
常見圖檔格式詳解

 将BitmapFactory.Options的inJustDecodeBounds 設定為true後，就隻會讀取Jpeg的大小，而不會去解析像素資料。然後再設定inSampleSize後，就可以根據這個值來讀取适當大小的圖檔，研究android的源碼後可以發現底層也是調用的libjpeg庫來實作。

ios,mac

本人還沒有在ios/mac中發現如何預讀jpeg的官方API。Apple對圖形、圖像、多媒體領域提供了豐富接口，如果這個功能真沒實作就太令我驚訝了! 不過ObjectC完全相容C，可以調用libjpeg庫來實作這個功能。

.NET下僅讀取jpeg的大小

下面是用c#僅僅讀取jpeg寬高(沒有解析像素資料), 直接用C#讀取1/2,1/4,1/8還不知道如何實作

FileStream stream = new FileStream(path, FileMode.Open);
Image img = Image.FromStream(stream, false, false);  //關鍵是将第三個參數設定為false
Console.WriteLine("size: {0},{1}", img.Width, img.Height);

jpeg批量轉化工具

用相機拍出來的原始jpeg圖檔是高保真品質, 所占檔案體積非常大,本人寫了一個批量轉化的工具,可以将jpeg的品質都轉化成80, 圖像的寬高不變, 這時人眼幾乎看不出有什麼差别, 但其體積隻有原來的1/3. 如果有大量的照片需要儲存時, 節約的空間就很客觀了。實作原理很簡單, 就是讀取jpeg檔案, 然後再儲存.

用c#實作的，代碼量非常少，在此貼出全部源碼

常見圖檔格式詳解

JpegBatchConvert

Exif資訊

另外jpeg檔案一般有一個附屬的exif資訊，這個資訊中有圖像大小，拍攝時間，拍攝的相關參數，照片方向，圖像縮略圖等資訊。

用相機拍出來的jpeg都會有這個資訊。如果照片方向不是正立的話，在讀取到像素取後，還得按exif所指明的方向将圖像旋轉下。mspaint程式就沒有做這個處理，有些圖檔用picasa檢視和用mspaint檢視方向就不一樣。當然為了簡單起見，上面的LBitmap中也自動忽略了exif資訊及其圖像拍攝時的方向。

如果不用讀取1/2,1/4,1/8的方法，也可以從exif中來讀取縮略圖，但這個縮略圖一般很小。

說到exif，不得不說一款用perl實作的指令行工具:exiftool。幾乎所有的多媒體檔案(圖像、音樂、視訊)都可以用這個工具來檢視其有關資訊，當然如果不是jpeg檔案就是指廣義上的"exif"。在git中有已經編譯好可執行檔案exiftool.exe。使用方法是将這個檔案放到系統路徑下，然後在想檢視的檔案路徑下執行 exiftool filename

在實作BatchJpeg工具時如果僅僅用上面實作的LBitmap來讀取,儲存, 将會失去exif資訊, 而相片的拍攝時間等資訊又很重要, 是以還得用另一個庫exiv2來讀取寫入exif。如果用c#, 用上面的代碼exif資訊會自動保留下來。默默地向c#緻敬。

intelJpeg庫

如果在win32環境下對jpeg IO速度有很高的要求，可以使用interlJpeg庫，不開源，但提供有*.h,*.lib檔案。這個庫可以大大提高jpg讀取、儲存速度。

當時分别用c#和c實作了jpeg批量轉化工具， 在處理大量圖檔時發現c#用時居然隻有c的一半。太奇怪了，按理說，c的速度比c#應該快才對啊， 而實事是c慢了這麼多。 最後發現問題就在libjpeg上，用了intetJpeg後速度就和c#差不多了(猜想.NET内部也是用intelJpeg來處理jpeg)。

PNG格式

  1. png是一種無損壓縮格式， 壓縮大概是用行程編碼算法。
  2. png可以有透明效果。
  3. png比較适合适量圖,幾何圖。 比如本文中出現的這些圖都是用png儲存，比用joeg儲存體積要小。

再強調一下: jpeg比較适合存儲色彩“雜亂”的拍攝圖檔，png比較适合存儲幾何特征強的圖形類圖檔。

png可能有24位圖和32位圖之分。32位圖就是帶有alpha通道的圖檔。

将圖檔a繪制到另一幅圖檔b上，如果圖檔a沒有alpha通道，那麼就會完全将b圖檔的像素給替換掉。而如果有alpha通道，那麼最後覆寫的結果值将是c = a*alpha + b*(1-alpha)

再對LBitmap添加png的支援。

添加接口如下:

static bool ReadPngSize(const wchar_t *path, int *width, int *height);
static bool IsPngFile(const wchar_t *filename);
bool ReadPng(const wchar_t *filename);
bool WritePng(const wchar_t *filename);

具體實作在PngDemo中。有調用libpng庫，并且libpng庫依賴zlib庫(由此可以看出png算法有用到正常的壓縮算法)。

GIF格式

上面提到的bmp,jpeg,png圖檔都隻有一幀，而gif可以儲存多幀圖像，如圖所示

常見圖檔格式詳解

libgif庫可以用來讀取gif圖檔。gif中有個參數可以控制圖檔變化的快慢。在程式中可以使用這個參數，也可以自己定義一個參數，這就是為什麼gif圖檔，在不同程式中檢視時其變化速度不一樣。

webp

google開發的一種有損、透明圖檔格式，相當于jpeg和png的合體，google聲稱其可以把圖檔大小減少40%。

一個強大的格式庫,CxImage

CxImage幾乎可以讀取任何圖檔格式

下面是其頭檔案中的宏定義:

常見圖檔格式詳解
#define CXIMAGE_SUPPORT_WINDOWS 1
#define CXIMAGE_SUPPORT_EXIF    1
#define CXIMAGE_SUPPORT_BMP 1
#define CXIMAGE_SUPPORT_GIF 1
#define CXIMAGE_SUPPORT_JPG 1
#define CXIMAGE_SUPPORT_PNG 1
#define CXIMAGE_SUPPORT_ICO 1
#define CXIMAGE_SUPPORT_TIF 1
#define CXIMAGE_SUPPORT_TGA 1
#define CXIMAGE_SUPPORT_PCX 1
#define CXIMAGE_SUPPORT_WBMP 1
#define CXIMAGE_SUPPORT_WMF 1

#define CXIMAGE_SUPPORT_JP2 1
#define CXIMAGE_SUPPORT_JPC 1
#define CXIMAGE_SUPPORT_PGX 1
#define CXIMAGE_SUPPORT_PNM 1
#define CXIMAGE_SUPPORT_RAS 1

#define CXIMAGE_SUPPORT_MNG 1
#define CXIMAGE_SUPPORT_SKA 1
#define CXIMAGE_SUPPORT_RAW 1
#define CXIMAGE_SUPPORT_PSD 1
常見圖檔格式詳解
#define 資料 位圖 圖檔格式 c#
上一篇: C# 圖檔格式轉換
下一篇: 關于AI，程式員需要了解這些！

繼續閱讀