做了幾年有關(guān)圖形,、圖像的工作,,對圖片格式算是小有經(jīng)驗(yàn),在此寫成一文章總結(jié)下,。雖然一開始并不想講很理論的東西,,但寫完后發(fā)現(xiàn)幾乎全是理論,細(xì)想一下關(guān)于圖片格式的知識本身就是理論的東西,,囧~~ 那就力求用最簡單的方式將這些“理論”講清楚吧,。 常見的圖片格式有bmp, jpg(jpeg), png, gif, webp等,。 圖像基本數(shù)據(jù)結(jié)構(gòu)要講圖片格式還先得從圖像的基本數(shù)據(jù)結(jié)構(gòu)說起,。在計(jì)算機(jī)中, 圖像是由一個(gè)個(gè)像素點(diǎn)組成,像素點(diǎn)就是顏色點(diǎn),,而顏色最簡單的方式就是用RGB或RGBA表示, 如圖所示 (圖1) (圖2) 如果有A通道就表明這個(gè)圖像可以有透明效果,。 R,G,B每個(gè)分量一般是用一個(gè)字節(jié)(8位)來表示,所以圖(1)中每個(gè)像素大小就是3*8=24位圖, 而圖(2)中每個(gè)像素大小是4*8=32位,。 這里有三點(diǎn)需要說明: 一,、圖像y方向正立或倒立圖像是二維數(shù)據(jù),數(shù)據(jù)在內(nèi)存中只能一維存儲,,二維轉(zhuǎn)一維有不同的對應(yīng)方式,。比較常見的只有兩種方式: 按像素“行排列”從上往下或者從下往上。如圖所示的圖像有9個(gè)像素點(diǎn),,如果從上往下排列成一維數(shù)據(jù)是(123456789),, 如果是從下往上排列則為(789456123)。 只所以會(huì)有這種區(qū)別是因?yàn)?,前一種是以計(jì)算機(jī)圖形學(xué)的屏幕坐標(biāo)系為參考(右上為原點(diǎn),y軸向下 ),,而另后一種是以標(biāo)準(zhǔn)的數(shù)學(xué)坐標(biāo)系為參考(右下為原點(diǎn),y軸向上)。這兩個(gè)坐標(biāo)系只是y值不一樣,,互相轉(zhuǎn)換的公式為: y2 = height-1-y1 y1,y2分別為像素在兩個(gè)坐標(biāo)系中的y坐標(biāo),,height為圖像的高度。 不過好像只有bmp圖片格式以及windows下的GDI,,GDI+是從下往上排列,,其它比如DirectX,OpenGL,Cocoa(NSImage, UIImage),OpenCV等都是從上往下排列。 二,、RGB排列順序不同圖形庫中每個(gè)像素點(diǎn)中RGBA的排序順序可能不一樣,。上面說過像素一般會(huì)有RGB,或RGBA四個(gè)分量,,那么在內(nèi)存中RGB的排列就有6種情況,如下: RGBA的排列有24種情況,,這里就不全部列出來了,。不過一般只會(huì)有RGB,BGR, RGBA, RGBA, BGRA這幾種排列據(jù)。 絕大多數(shù)圖形庫或環(huán)境是BGR/BGRA排列,,cocoa中的NSImage或UIImage是RGBA排列,。 三、像素32位對齊如果是RGB24位圖,,會(huì)存在一個(gè)32位對齊的問題—— 在x86體系下,,cpu一次處理32整數(shù)倍的數(shù)據(jù)會(huì)更快,圖像處理中經(jīng)常會(huì)按行為單位來處理像素,。24位圖,,寬度不是4的倍數(shù)時(shí),其行字節(jié)數(shù)將不是32整數(shù)倍,。這時(shí)可以采取在行尾添加冗余數(shù)據(jù)的方式,,使其行字節(jié)數(shù)為32的倍數(shù)。 比如,,如果圖像寬為5像素,,不做32位對齊的話,其行字節(jié)數(shù)為24*5=120,,120不是32的倍數(shù),。是32整數(shù)倍并且剛好比120大的數(shù)是128,也就只需要在其行尾添加1字節(jié)(8位)的冗余數(shù)據(jù)即可,。(一個(gè)以空間換時(shí)間的例子) 有個(gè)公式可以輕松計(jì)算出32位對齊后每行應(yīng)該占的字節(jié)數(shù) byteNum = ((width * 24 + 31) & ~31)>>3; 注意結(jié)果是字節(jié)數(shù),,如果想知道位數(shù),還得x8 圖片格式的必要性如果將圖像原始格式直接存儲到文件中將會(huì)非常大,,比如一個(gè)5000*5000 24位圖,,所占文件大小為5000*5000*3字節(jié)=71.5MB, 其大小非常可觀,。 如果用zip或rar之類的通用算法來壓縮像素?cái)?shù)據(jù),,得到的壓縮比例通常不會(huì)太高,因?yàn)檫@些壓縮算法沒有針對圖像數(shù)據(jù)結(jié)構(gòu)進(jìn)行特殊處理,。 于是就有了jpeg,png等格式,,同樣是圖像壓縮算法jpeg和png也有不同的適用場景,具體在下文再闡述,。 所以可以總結(jié)如下: jpeg,png文件之于圖像,,就相當(dāng)于zip,rar格式之于普通文件(用zip,rar格式對普通文件進(jìn)行壓縮)。 BMP格式bmp格式?jīng)]有壓縮像素格式,,存儲在文件中時(shí)先有文件頭,、再圖像頭,、后面就都是像素?cái)?shù)據(jù)了,上下顛倒存儲,。 用windows自帶的mspaint工具保存bmp格式時(shí),,可以發(fā)現(xiàn)有四種bmp可供選擇: 單色: 一個(gè)像素只占一位,要么是0,,要么是1,,所以只能存儲黑白信息 16色位圖: 一個(gè)像素4位,有16種顏色可選 256色位圖: 一個(gè)像素8位,,有256種顏色可選 24位位圖: 就是圖(1)所示的位圖,,顏色可有2^24種可選,對于人眼來說完全足夠了,。 這里為了簡單起見,,只詳細(xì)討論最常見的24位圖的bmp格式。 現(xiàn)在來看其文件頭和圖片格式頭的結(jié)構(gòu):
本來在windows平臺下wingdi.h文件中已經(jīng)有這些結(jié)構(gòu)的定義,,不過為了不依賴與windows,實(shí)現(xiàn)為跨平臺,,本人將wingdi.h中的這兩個(gè)結(jié)構(gòu)“偷用”出來了,。代碼如下: 1 //bmp文件頭2 #pragma pack(push)3 #pragma pack(2)4 typedef struct tagBITMAPFILEHEADER {5 unsigned short bfType; // 19778,必須是BM字符串,,對應(yīng)的十六進(jìn)制為0x4d42,十進(jìn)制為197786 unsigned int bfSize; // 文件大小7 unsigned short bfReserved1; // 08 unsigned short bfReserved2; // 09 unsigned int bfOffBits; // 從文件頭到像素?cái)?shù)據(jù)的偏移,,也就是這兩個(gè)結(jié)構(gòu)體的大小之和10 } BITMAPFILEHEADER;11 #pragma pack(pop)1213 //bmp圖像頭14 typedef struct tagBITMAPINFOHEADER {15 unsigned int biSize; // 此結(jié)構(gòu)體的大小16 int biWidth; // 圖像的寬17 int biHeight; // 圖像的高18 unsigned short biPlanes; // 119 unsigned short biBitCount; // 2420 unsigned int biCompression; // 021 unsigned int biSizeImage; // 像素?cái)?shù)據(jù)所占大小, 這個(gè)值應(yīng)該等于上面文件頭結(jié)構(gòu)中bfSize-bfOffBits22 int biXPelsPerMeter; // 023 int biYPelsPerMeter; // 024 unsigned int biClrUsed; // 025 unsigned int biClrImportant;// 026 } BITMAPINFOHEADER; Bmp結(jié)構(gòu)體 由于bmp格式比較簡單,本人已實(shí)現(xiàn)了一份簡單的c++代碼,,具有讀取,、保存bmp圖片的功能,只支持24位的bmp格式,。 代碼在 http://git.oschina.net/xiangism/blogData 的“常見圖片格式詳解/ImageDemo/BmpDemo”文件夾中,。 雖然這里只建立了vs2008項(xiàng)目,但代碼在linux, mac平臺下都可以編譯通過,。 需要說明的是為了統(tǒng)一處理,,將bmp讀取到LBitmap::m_pixel中時(shí)就將其轉(zhuǎn)化為32位從上往下排列的圖像格式了。并且會(huì)有y坐標(biāo)的轉(zhuǎn)化,。所以在讀取的時(shí)候會(huì)有一個(gè)temp_line先存儲文件中的24位數(shù)據(jù),,再轉(zhuǎn)化為32位數(shù)據(jù),。在保存時(shí)也是先將32位數(shù)據(jù)轉(zhuǎn)化到temp_line的24位數(shù)據(jù)上,然后再寫入文件,。(如果僅僅是處理bmp,,那么這么多的一個(gè)A通道是冗余數(shù)據(jù),但后面處理png圖片時(shí)就會(huì)用到這個(gè)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 運(yùn)行的結(jié)果為: 0,128,255可以看出像素分布為BGR ps:
接下來要介紹一個(gè)有關(guān)jpeg非常實(shí)用的技術(shù)—— jpeg格式支持不完全讀取整張圖片,,即可以選擇讀取原圖、1/2,、1/4,、1/8大小的圖片 比如5000*5000的一張大圖,可以只讀取將其縮小成1/8后即625*625大小的圖片,。 這樣比先完全讀取5000*5000的圖像,,再用算法縮小成625*625大小不知快多少倍。 如果應(yīng)用需求只需要一張小圖時(shí),,這種讀取方式就可以大顯身手了,。 在c代碼中讀取jpeg一般是使用libjpeg, 這個(gè)庫提供了不完全讀取圖片的功能。 給ln::LBitmap添加有關(guān)jpeg的接口,,如下ReadJpeg第三個(gè)參數(shù)fraction可取值為1,2,4,8,,分別對應(yīng)1/1,1/2,1/4,1/8 ```在上面LBitmap的基本上加入下面5個(gè)函數(shù):// 不讀取像素?cái)?shù)據(jù),只讀取jpeg文件的大小, 用指針*width, *height做為傳出參數(shù), 返回值bool返回文件是否為jpeg格式static bool ReadJpegSize(const wchar_t *path, int *width, int *height);// 判斷文件是否為jpeg格式static bool IsJpegFile(const wchar_t *fileame);// 讀取jpeg,,fraction可取值為1, 2, 4, 8bool ReadJpeg(const wchar_t *filename, int fraction = 1);// 按照width, height的大小讀取合適的jpeg大小, 所得的圖像大小不會(huì)超過width*heightbool ReadFitJpeg(const wchar_t *filename, int width, int height);// 保存jpeg,,quality范圍是[0, 100]bool WriteJpeg(const wchar_t *filename, int quality = 80);``` JpegAPI 具體的實(shí)現(xiàn)在JpegDemo用上面的函數(shù)進(jìn)行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放大后顯示如下 發(fā)現(xiàn)左上角的顏色發(fā)生了變化,,并且也影響到周圍的像素,,就算將上面WriteJpeg第二個(gè)參數(shù)換成100,也還是這種效果,,這是Jpeg格式無法避免的問題但如果讀取一張風(fēng)景照,,再保存成Jpeg,就幾乎看不出有什么差別了,。 android平臺下實(shí)現(xiàn)jpeg預(yù)讀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 設(shè)置為true后,,就只會(huì)讀取Jpeg的大小,而不會(huì)去解析像素?cái)?shù)據(jù),。然后再設(shè)置inSampleSize后,,就可以根據(jù)這個(gè)值來讀取適當(dāng)大小的圖片,研究android的源碼后可以發(fā)現(xiàn)底層也是調(diào)用的libjpeg庫來實(shí)現(xiàn),。 ios,mac本人還沒有在ios/mac中發(fā)現(xiàn)如何預(yù)讀jpeg的官方API,。Apple對圖形、圖像,、多媒體領(lǐng)域提供了豐富接口,,如果這個(gè)功能真沒實(shí)現(xiàn)就太令我驚訝了! 不過ObjectC完全兼容C,可以調(diào)用libjpeg庫來實(shí)現(xiàn)這個(gè)功能,。 .NET下僅讀取jpeg的大小下面是用c#僅僅讀取jpeg寬高(沒有解析像素?cái)?shù)據(jù)), 直接用C#讀取1/2,1/4,1/8還不知道如何實(shí)現(xiàn) FileStream stream = new FileStream(path, FileMode.Open);Image img = Image.FromStream(stream, false, false); //關(guān)鍵是將第三個(gè)參數(shù)設(shè)置為falseConsole.WriteLine('size: {0},{1}', img.Width, img.Height);jpeg批量轉(zhuǎn)化工具 用相機(jī)拍出來的原始jpeg圖片是高保真質(zhì)量, 所占文件體積非常大,本人寫了一個(gè)批量轉(zhuǎn)化的工具,可以將jpeg的質(zhì)量都轉(zhuǎn)化成80, 圖像的寬高不變, 這時(shí)人眼幾乎看不出有什么差別, 但其體積只有原來的1/3. 如果有大量的照片需要保存時(shí), 節(jié)約的空間就很客觀了,。實(shí)現(xiàn)原理很簡單, 就是讀取jpeg文件, 然后再保存. 用c#實(shí)現(xiàn)的,代碼量非常少,,在此貼出全部源碼 1 class Program2 {3 static string src_path;4 static long small_size = 0;56 private static ImageCodecInfo GetCodecInfo(string mimeType)7 {8 ImageCodecInfo CodecInfo = ImageCodecInfo.GetImageEncoders;910 foreach (ImageCodecInfo ici in CodecInfo) {11 if (ici.MimeType == mimeType)12 return ici;13 }14 return null;15 }1617 static void SaveImage(string path)18 {19 FileStream stream = new FileStream(path, FileMode.Open, FileAccess.Read);2021 if (stream.Length == 0) {22 stream.Close;23 return;24 }2526 byte file_data = new byte[stream.Length];27 stream.Read(file_data, 0, (int)stream.Length);28 Stream mem = new MemoryStream(file_data);2930 long old_size = stream.Length;3132 try {33 Image img = new Bitmap(mem);34 stream.Close;3536 EncoderParameter p = new EncoderParameter(System.Drawing.Imaging.Encoder.Quality, 80L);37 EncoderParameters ps = new EncoderParameters(1);3839 ps.Param[0] = p;4041 img.Save(path, GetCodecInfo('image/jpeg'), ps);4243 FileStream f = new FileStream(path, FileMode.Open, FileAccess.Read);44 long new_size = f.Length;45 f.Close;4647 small_size += old_size - new_size;4849 } catch (System.Exception ex) {5051 } finally {52 stream.Close;53 }5455 }5657 static void ConvertOneImage(string path, bool is_save)58 {59 if (is_save) {60 string new_name = src_path + path.Substring(path.LastIndexOf('\\'));61 File.Copy(path, new_name, true);62 }6364 SaveImage(path);65 }6667 static void ShowSize(string path)68 {69 FileStream stream = new FileStream(path, FileMode.Open);70 Image img = Image.FromStream(stream, false, false);71 stream.Close;72 //Console.WriteLine('{0} {1}', img.Width, img.Height);73 if (img.Width == 0) {74 Console.WriteLine('Error');75 }76 }7778 static void BatchJpeg79 {80 string path = Application.ExecutablePath;81 path = path.Substring(0, path.LastIndexOf('\\'));8283 src_path = path + '\\' + 'src';84 //Console.WriteLine(src_path);8586 Console.WriteLine('批量轉(zhuǎn)化jpeg圖片,,保證其圖片質(zhì)量的前提下減少其存儲大小');87 Console.WriteLine('若想保存原圖片,,其按y(原圖將放在src文件夾下), 否則按任意鍵開始處理');8889 ConsoleKeyInfo key = Console.ReadKey;90 bool is_save = false;9192 if (key.KeyChar == 'y' || key.KeyChar == 'Y') {93 is_save = true;9495 Directory.CreateDirectory('src');96 }9798 string files = Directory.GetFiles(path, '*.jpg');99100 Stopwatch sw = new Stopwatch;101 sw.Start;102103 for (int i = 0; i < files.length;="" ++i)="" {104="" convertoneimage(files[i],="" is_save);105="" string="" s="files[i].Substring(files[i].LastIndexOf('\\')" +="" 1);106="" console.writeline((i="" +="" 1).tostring="" +="" '/'="" +="" files.length.tostring="" +="" '="" \t="" '="" +="" s);107108="" showsize(files[i]);109="" }110111="" sw.stop;112113="" console.writeline('*********已結(jié)束,,按任意鍵結(jié)束********');114="" double="" v="(small_size" *="" 1.0="" (1024="" *="" 1024));115116="" console.writeline('共減少="" '="" +="" v.tostring('0.00##')="" +="" 'm="" 的存儲空間');117="" console.writeline('耗時(shí):'="" +="" sw.elapsed.totalseconds.tostring('0.00##')="" +="" '秒');118="" console.readkey;119="" }120121="" static="" void="" main(string[]="" args)122="" {123="" batchjpeg;124="" saveimage('e:\\img="" -="" 副本.jpg');125="" string="" path='E:\\cpp_app\\LiteTools\\JpegBatch\\bin\\Release\\img - 副本.JPG' ;126="" file.delete(path);127="" }128=""> JpegBatchConvert Exif信息另外jpeg文件一般有一個(gè)附屬的exif信息,這個(gè)信息中有圖像大小,,拍攝時(shí)間,,拍攝的相關(guān)參數(shù),照片方向,,圖像縮略圖等信息,。 用相機(jī)拍出來的jpeg都會(huì)有這個(gè)信息。如果照片方向不是正立的話,,在讀取到像素取后,,還得按exif所指明的方向?qū)D像旋轉(zhuǎn)下。mspaint程序就沒有做這個(gè)處理,,有些圖片用picasa查看和用mspaint查看方向就不一樣,。當(dāng)然為了簡單起見,,上面的LBitmap中也自動(dòng)忽略了exif信息及其圖像拍攝時(shí)的方向。 如果不用讀取1/2,1/4,1/8的方法,,也可以從exif中來讀取縮略圖,,但這個(gè)縮略圖一般很小。 說到exif,,不得不說一款用perl實(shí)現(xiàn)的命令行工具:exiftool,。幾乎所有的多媒體文件(圖像、音樂,、視頻)都可以用這個(gè)工具來查看其有關(guān)信息,,當(dāng)然如果不是jpeg文件就是指廣義上的'exif'。在git中有已經(jīng)編譯好可執(zhí)行文件exiftool.exe,。使用方法是將這個(gè)文件放到系統(tǒng)路徑下,,然后在想查看的文件路徑下執(zhí)行 exiftool filename 在實(shí)現(xiàn)BatchJpeg工具時(shí)如果僅僅用上面實(shí)現(xiàn)的LBitmap來讀取,保存, 將會(huì)失去exif信息, 而相片的拍攝時(shí)間等信息又很重要, 所以還得用另一個(gè)庫exiv2來讀取寫入exif。如果用c#, 用上面的代碼exif信息會(huì)自動(dòng)保留下來,。默默地向c#致敬,。 intelJpeg庫如果在win32環(huán)境下對jpeg IO速度有很高的要求,可以使用interlJpeg庫,,不開源,,但提供有*.h,*.lib文件。這個(gè)庫可以大大提高jpg讀取,、保存速度,。 當(dāng)時(shí)分別用c#和c實(shí)現(xiàn)了jpeg批量轉(zhuǎn)化工具, 在處理大量圖片時(shí)發(fā)現(xiàn)c#用時(shí)居然只有c的一半,。太奇怪了,,按理說,c的速度比c#應(yīng)該快才對啊,, 而實(shí)事是c慢了這么多,。 最后發(fā)現(xiàn)問題就在libjpeg上,用了intetJpeg后速度就和c#差不多了(猜想.NET內(nèi)部也是用intelJpeg來處理jpeg),。 PNG格式
再強(qiáng)調(diào)一下: jpeg比較適合存儲色彩“雜亂”的拍攝圖片,,png比較適合存儲方幾何特征比較強(qiáng)的矢量圖。 png可能有24位圖和32位圖之分。32位圖就是帶有alpha通道的圖片,。 將圖片a繪制到另一幅圖片b上,,如果圖片a沒有alpha通道,那么就會(huì)完全將b圖片的像素給替換掉,。而如果有alpha通道,,那么最后覆蓋的結(jié)果值將是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); 具體實(shí)現(xiàn)在PngDemo中,。有調(diào)用libpng庫,,并且libpng庫依賴zlib庫(由此可以看出png算法有用到常規(guī)的壓縮算法)。 GIF格式上面提到的bmp,jpeg,png圖片都只有一幀,,而gif可以保存多幀圖像,,如圖所示 libgif庫可以用來讀取gif圖片。gif中有個(gè)參數(shù)可以控制圖片變化的快慢,。在程序中可以使用這個(gè)參數(shù),,也可以自己定義一個(gè)參數(shù),這就是為什么gif圖片,,在不同程序中查看時(shí)其變化速度不一樣,。 webpgoogle開發(fā)的一種有損、透明圖片格式,,相當(dāng)于jpeg和png的合體,,google聲稱其可以把圖片大小減少40%。 一個(gè)強(qiáng)大的格式庫,CxImageCxImage幾乎可以讀取任何圖片格式 下面是其頭文件中的宏定義: #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 CxImage在針對特定格式時(shí),,也是調(diào)用了其它圖片庫(比如libjpeg, libpng, libtiff),。由于CxImage太過龐大,如果不想使用其全部代碼,,可以自己從中“偷取”特定圖片格式的讀取,、保存代碼。 |
|