有限帶寬中基于Socket的網(wǎng)絡(luò)通信圖像傳輸與實(shí)現(xiàn)

田東燊，李思軍，孫旭飛

(福州大學(xué) 物理與信息工程學(xué)院，福建 福州 350108)

近年來(lái)，隨著拍照類(lèi)數(shù)碼產(chǎn)品飛速的發(fā)展，小到人們手中的拍照手機(jī)，大到數(shù)碼相機(jī)所配置的攝像頭像素越來(lái)越大，拍攝的作品也越來(lái)越清晰美觀，但由此導(dǎo)致了圖片大小也越來(lái)越大。人們常愛(ài)把所拍的美麗圖片分享到朋友圈以供他人瀏覽，以往當(dāng)我們點(diǎn)開(kāi)網(wǎng)上一張圖片時(shí)，系統(tǒng)會(huì)先將圖像從服務(wù)端下載到客戶端才能顯示出來(lái)，或者圖像由上向下掃描式顯示。但當(dāng)我們身處深山或者局部網(wǎng)絡(luò)繁忙的環(huán)境中時(shí)，想要再去瀏覽高清圖片勢(shì)必十分困難。原有的圖像傳輸方式大大降低用戶瀏覽圖片的體驗(yàn)度。而采用漸進(jìn)式圖像傳輸，當(dāng)人們點(diǎn)開(kāi)想要查看的圖片時(shí)，系統(tǒng)能第一時(shí)間將原始圖像大致的輪廓數(shù)據(jù)從服務(wù)器傳輸?shù)娇蛻舳瞬@示出來(lái)，人們可以在極短時(shí)間內(nèi)根據(jù)看到的模糊圖像獲得當(dāng)前圖像的大致信息，從而選擇是否等待查看原始圖像。采用漸進(jìn)式圖像傳輸，也能大大降低圖像在網(wǎng)絡(luò)中傳輸對(duì)帶寬的需求。

本設(shè)計(jì)采用基于TCP協(xié)議的Socket網(wǎng)絡(luò)編程的原理，在Linux平臺(tái)搭建了服務(wù)器Windows平臺(tái)搭建了客戶端[1]，實(shí)現(xiàn)了圖像傳輸以及圖像在客戶端由模糊到清晰的顯示。

1 進(jìn)式傳輸和系統(tǒng)設(shè)計(jì)

1.1 算法設(shè)計(jì) 漸進(jìn)式傳輸

漸進(jìn)式圖像傳輸是通過(guò)對(duì)目標(biāo)圖像采用特殊方式的編碼來(lái)實(shí)現(xiàn)的。目前漸進(jìn)式傳輸?shù)姆椒ù笾路譃槿?lèi)，塔型編碼、迭代編碼以及頻率選擇編碼。

塔型編碼將一副圖像像塔一樣分成數(shù)層來(lái)表示，不同的層對(duì)應(yīng)不同的分辨率，其中最頂層圖像分辨率最低，最底層圖像的分辨率最高且和原始圖像分辨率相同。一般下一層分辨率是上一層分辨率的四倍；迭代編碼是通過(guò)迭代編碼殘差圖像來(lái)得到增強(qiáng)層數(shù)據(jù)的；頻率選擇編碼是在圖像頻率域進(jìn)行處理的一種方法。常采用8×8 DCT(離散余弦變換)完成空間域到頻率的轉(zhuǎn)換。DCT系數(shù)的每個(gè)分量對(duì)應(yīng)一定的能量。左上角為低頻分量，記錄著圖像大致輪廓數(shù)據(jù)。右下角為高頻分量記錄著相應(yīng)圖像具體細(xì)節(jié)。在圖像傳輸時(shí)先傳輸?shù)皖l分量再傳輸高頻分量從而達(dá)到漸進(jìn)式傳輸效果[2]。

本次設(shè)計(jì)使用的是Libjpeg圖像處理庫(kù)對(duì)位圖進(jìn)行壓縮處理，該庫(kù)編碼類(lèi)型即為頻率選擇編碼。其編碼器構(gòu)成如圖1所示。

圖1 于DCT的JPEG編碼器構(gòu)成

如圖1所示編碼器原理為先將原始圖像數(shù)據(jù)分割成許多8×8的數(shù)據(jù)單元，然后通過(guò)DCT處理將相應(yīng)的數(shù)據(jù)單元的值轉(zhuǎn)換成對(duì)應(yīng)的頻率系數(shù)。然后通過(guò)量化處理并使用哈夫曼編碼進(jìn)行熵編碼最終得到壓縮圖像數(shù)據(jù)[3]。

利用Libjpeg庫(kù)進(jìn)行漸進(jìn)式壓縮的具體實(shí)現(xiàn)過(guò)程如下：

將位圖數(shù)據(jù)讀入到內(nèi)存中，判斷出圖像是24位還是32位色彩深度位圖(位圖色彩深度有多種，在此只處理了24位和32位的位圖);通過(guò)struct jpeg_compress_struct cinfo和jpeg_create_compress (&cinfo)申請(qǐng)初始化一個(gè)jpeg壓縮對(duì)象;通過(guò)jpeg_stdio_dest(&cinfo, fJpeg)指定壓縮后的jpg圖像所存放的目標(biāo)文件;設(shè)置24位和32位位圖相應(yīng)的壓縮參數(shù); 使用jpeg_create_compress (&cinfo)開(kāi)啟壓縮; 最后釋放壓縮過(guò)程申請(qǐng)的資源。

通過(guò)上述處理，服務(wù)器端將大型位圖壓縮成小型的漸進(jìn)式j(luò)pg圖像。成功減少了傳輸數(shù)據(jù)。本系統(tǒng)采用的是Socket套接字技術(shù)對(duì)數(shù)據(jù)進(jìn)行傳輸。采用的傳輸協(xié)議是TCP/IP協(xié)議，其通信實(shí)現(xiàn)步驟主要包含：服務(wù)端創(chuàng)建套接字，通過(guò)bind()函數(shù)綁定套接字和端口號(hào)，然后通過(guò)listen()函數(shù)開(kāi)啟監(jiān)聽(tīng)功能。客戶端使用connect()函數(shù)連接服務(wù)器指定的相應(yīng)端口號(hào)。連接成功后服務(wù)端和客戶端使用recv()函數(shù)和send()函數(shù)進(jìn)行相互間的數(shù)據(jù)接收與發(fā)送[4-5]。

1.2 系統(tǒng)設(shè)計(jì)

目前圖片傳輸技術(shù)在web網(wǎng)頁(yè)得到廣泛的應(yīng)用，其傳輸原理是當(dāng)用戶點(diǎn)擊一張想要查的圖片時(shí)，系統(tǒng)先將一張低分辨率的圖片按比例放大得到一張模糊圖片，然后將原始圖片傳輸過(guò)來(lái)。當(dāng)放大比例過(guò)大時(shí)，得到的放大圖片十分模糊，不能第一時(shí)間讓用戶得到的可靠信息，而圖片數(shù)據(jù)分片實(shí)時(shí)傳輸?shù)姆绞絽s能解決上述問(wèn)題。

本次設(shè)計(jì)需要自行搭建Linux服務(wù)器和Windows客戶端。Linux系統(tǒng)選用Ubuntu16.04.1 LTS 64 bit版本。因服務(wù)端使用到Libjpeg庫(kù)故需要進(jìn)行相關(guān)配置，首先從網(wǎng)上下載libjpeg-turbo-1.2.1.tar.gz安裝包并解壓，然后使用make命令對(duì)其進(jìn)行編譯生成靜態(tài)庫(kù)，最后將生成的庫(kù)文件移動(dòng)到相應(yīng)的目錄下。Windows客戶端選用的Visio studio 2012版本作為開(kāi)發(fā)平臺(tái)，并將OpenCV2.4.9版本庫(kù)添加到開(kāi)發(fā)環(huán)境中。

系統(tǒng)實(shí)現(xiàn)了用戶在客戶端輸入想要瀏覽的圖片編號(hào)將其發(fā)送到服務(wù)器端，服務(wù)器端收到請(qǐng)求后將存儲(chǔ)的相應(yīng)位圖進(jìn)行頻率選擇編碼壓縮得到一張數(shù)據(jù)量小的jpg圖片，壓縮后得到的圖片大小受壓縮質(zhì)量參數(shù)的影響。在壓縮圖像前需要對(duì)位圖判斷其為正向位圖還是倒向位圖，并做相應(yīng)的位圖數(shù)據(jù)存取順序處理。系統(tǒng)通過(guò)Socket套接字將壓縮后的圖片數(shù)據(jù)分成8次在相等的時(shí)間間隔依次發(fā)送到Windows客戶端。客戶端使用OpenCV庫(kù)將接收到的圖片數(shù)據(jù)依次顯示出來(lái)，從而實(shí)現(xiàn)圖片顯示由模糊到清晰的過(guò)程。上述方式也大大降低了圖像傳輸?shù)臄?shù)據(jù)。服務(wù)端和客戶端系統(tǒng)流程圖如圖2所示。

圖2 系統(tǒng)流程圖

2 實(shí)驗(yàn)過(guò)程及結(jié)果分析

本系統(tǒng)分別對(duì)24位和32位位圖進(jìn)行了相關(guān)的實(shí)驗(yàn)并取得了成功。從下圖3可以看出，服務(wù)端名為test.bmp的32位原始位圖大小為2.8 MB：

圖3 服務(wù)器界面

首先服務(wù)端使用./server命令運(yùn)行服務(wù)程序從而開(kāi)啟服務(wù)器監(jiān)聽(tīng)功能，如圖4所示。

圖4 服務(wù)器運(yùn)行界面

然后Windows客戶端運(yùn)行相應(yīng)程序，輸入用戶需要瀏覽的圖像并嘗試連接到服務(wù)端，如圖5所示。

圖5 客戶端運(yùn)行界面

服務(wù)端在收到客戶端相應(yīng)請(qǐng)求后將相應(yīng)的位圖(本次實(shí)驗(yàn)位圖名為test.bmp)進(jìn)行編碼壓縮成為名為bmptojpg.jpg的圖片，結(jié)果如圖6所示。可以看出，壓縮后的圖片大小為400 KB，其遠(yuǎn)遠(yuǎn)小于原始的位圖的2.8 MB。故當(dāng)系統(tǒng)將圖片從服務(wù)端傳輸?shù)娇蛻舳藭r(shí)，需要傳輸?shù)臄?shù)據(jù)被極大的降低。

圖6 服務(wù)器運(yùn)行后的結(jié)果

圖片壓縮時(shí)采用的是漸進(jìn)式傳輸技術(shù)。因此在圖像數(shù)據(jù)分次被傳輸?shù)娇蛻舳藭r(shí)，客戶端能夠?qū)⒔邮盏降臄?shù)據(jù)依次拼接起來(lái)逐次顯示在屏幕上，從而在用戶瀏覽圖片時(shí)，能夠感覺(jué)到圖像由模糊到清晰的過(guò)程。在Linux服務(wù)端壓縮后得到的jpg圖像數(shù)據(jù)被分成8次傳輸，客戶端程序不僅將接收到的數(shù)據(jù)依次拼接成8張圖片顯示出來(lái)，還將這8張圖片存儲(chǔ)在了Windows端的磁盤(pán)上以供分析使用，8張圖片如7所示。

圖7 編碼壓縮所得圖片顯示效果

可以看出上圖8中由a圖到h圖其清晰程度越來(lái)越高。通過(guò)實(shí)驗(yàn)發(fā)現(xiàn)，當(dāng)傳輸?shù)臄?shù)據(jù)達(dá)到所傳輸圖片全部數(shù)據(jù)的50%時(shí)，圖片清晰度已經(jīng)十分接近原始位圖清晰度，由此可見(jiàn)一張2.8 MB的位圖通過(guò)系統(tǒng)的處理后只需實(shí)時(shí)傳輸200 KB的數(shù)據(jù)就能讓用戶在客戶端看到與原始位圖相差無(wú)幾的圖像。而且由于圖像數(shù)據(jù)分次逐次實(shí)時(shí)傳輸，使得客戶端能夠?qū)崟r(shí)的顯示，與目前web網(wǎng)頁(yè)的圖像傳輸技術(shù)相比較，本系統(tǒng)的處理方法大大提高了用戶瀏覽圖片的體驗(yàn)度，也大大降低系統(tǒng)每次傳輸圖像數(shù)據(jù)的大小。顯然這樣的圖像傳輸系統(tǒng)在網(wǎng)絡(luò)帶寬較低或者網(wǎng)絡(luò)繁忙的環(huán)境中也有著較強(qiáng)的適應(yīng)能力。系統(tǒng)最終實(shí)現(xiàn)結(jié)果如圖8所示。

圖8 運(yùn)行結(jié)果

3 小結(jié)

本文研究了在有限的帶寬下如何實(shí)現(xiàn)大型圖像的傳輸與顯示。實(shí)驗(yàn)以Linux平臺(tái)作為服務(wù)端，Windows平臺(tái)作為客戶端。通過(guò)使用套接字網(wǎng)絡(luò)編程技術(shù)實(shí)現(xiàn)了服務(wù)器客戶端間的通信。并且通過(guò)對(duì)原始圖像采用漸進(jìn)式傳輸技術(shù)，通過(guò)對(duì)圖像的壓縮、分步式數(shù)據(jù)傳輸、拼接接收到的圖像數(shù)據(jù)、刷新顯示圖像，使得客戶端的圖像顯示實(shí)現(xiàn)了由模糊到清晰的顯示過(guò)程，用戶能第一時(shí)間了解到所看圖片的大致輪廓信息，同時(shí)服務(wù)器客戶端間傳輸?shù)臄?shù)據(jù)也大大降低，達(dá)到了預(yù)期目的。