圖像處理的算法復(fù)雜度通常都比較高，計(jì)算也相應(yīng)比較耗時(shí)。利用CPU多線程處理能力可以大幅度加快計(jì)算速度。但是，為了保證多線程處理的結(jié)果和單線程處理的結(jié)果完全相同，圖像的多線程計(jì)算有一些需要特別考慮的地方。

基本思路：

為了能讓多個(gè)線程同時(shí)并行處理，那么各自處理的數(shù)據(jù)不能有交集，這很好理解。那么基本思路是將一副圖像分成多個(gè)子塊，每個(gè)子塊數(shù)據(jù)肯定是沒有交集的，每個(gè)線程對(duì)一個(gè)子塊數(shù)據(jù)進(jìn)行處理，完成后將所有子塊處理結(jié)果合成最終圖像。

首先，每個(gè)子塊的大小當(dāng)然是必須考慮的問題。通常當(dāng)應(yīng)用進(jìn)行一個(gè)較長(zhǎng)時(shí)間的操作，應(yīng)該用合適的方式告知用戶。既然我們把圖像分子塊處理，如果單個(gè)子塊處理時(shí)間很短，那么每當(dāng)有一個(gè)子塊的數(shù)據(jù)處理完成，我們就可以立即把它相應(yīng)的處理結(jié)果展示給用戶。用戶就會(huì)看到這個(gè)圖像各個(gè)部分的處理結(jié)果不斷展示出來，直至整個(gè)圖像完成。這樣某種程度上用這種方式就是在告知用戶正在處理進(jìn)行中，避免為了把整個(gè)圖像處理完成，用戶需要等待太長(zhǎng)時(shí)間。從這個(gè)角度來說，如果子塊尺寸取的太大，每個(gè)子塊計(jì)算時(shí)間肯定相應(yīng)地加長(zhǎng)，對(duì)于快速顯示部分處理結(jié)果給用戶是不利的。但是如果子塊太小，子塊總數(shù)就會(huì)增加，肯定會(huì)增加線程開銷和其他一些開銷（分割圖像，分配子塊數(shù)據(jù)等等），對(duì)于總的計(jì)算時(shí)間是不利的。這是一個(gè)權(quán)衡問題，可以根據(jù)具體情況確定。

另外，很多圖像處理都要考慮像素領(lǐng)域范圍的信息，因此對(duì)于每個(gè)子塊的處理不能僅僅使用這個(gè)子塊的內(nèi)容。具體地，對(duì)于靠近子塊邊緣的像素，還要把子塊外的部分像素信息考慮進(jìn)來，加入計(jì)算，才能保證相應(yīng)像素的處理結(jié)果是正確的。準(zhǔn)確來說，如果領(lǐng)域半徑為r（對(duì)方形或圓形領(lǐng)域來說，其他領(lǐng)域可做相應(yīng)調(diào)整），那么子塊處理所需要的所有數(shù)據(jù)是子塊四周向外擴(kuò)展r像素的范圍。

代碼中extend就是子塊要向四周擴(kuò)張的大小，其實(shí)就是領(lǐng)域半徑r。pRect[i]是分割的第i個(gè)子塊的大小。Height和Width是原圖的高寬，擴(kuò)展子塊自然不能超過原圖的尺寸。那么最后rect1就是計(jì)算所需要的數(shù)據(jù)在原圖中所在的領(lǐng)域范圍，應(yīng)用原圖的尺寸對(duì)它進(jìn)行了限制。由于我是把每個(gè)子塊當(dāng)成一個(gè)新的圖像進(jìn)行處理，rect2就是新圖像中子塊處理結(jié)果所在的位置，用它來合成最終圖像。

最后關(guān)于線程具體創(chuàng)建銷毀，資源分配與回收，線程同步和通信，不做具體討論。只討論一下在這里多線程如何協(xié)調(diào)工作的問題。由于計(jì)算子塊的線程只負(fù)責(zé)處理子塊，還需要有人來做分割子塊，分配數(shù)據(jù)給子塊計(jì)算線程等等工作。本來應(yīng)該畫流程圖的，實(shí)在懶得畫了，這里簡(jiǎn)單描述一下幾個(gè)線程如何協(xié)調(diào)工作的，其實(shí)也很簡(jiǎn)單。界面線程A，處理和用戶之間的交互，接受用戶命令，發(fā)送計(jì)算消息給線程B。計(jì)算協(xié)調(diào)線程B接受A的消息，分割子塊，分配子塊數(shù)據(jù)，創(chuàng)建子塊計(jì)算線程Ci。子塊計(jì)算線程Ci負(fù)責(zé)子塊計(jì)算，發(fā)送處理結(jié)果（成功或失?。┫⒔o線程B或者A。界面線程A收到子塊完成消息，可以立即顯示子塊處理結(jié)果，當(dāng)然也可以什么都不做，等到所有子塊處理完再顯示。協(xié)調(diào)線程B收到第i個(gè)子塊完成消息，回收分配給線程Ci的資源，銷毀Ci。如果所有的Ci完成了工作，B發(fā)送圖像處理完成的消息給A，A可以接著做后續(xù)的工作。這里單獨(dú)用了一個(gè)線程B來做子塊計(jì)算協(xié)調(diào)的工作，感覺這樣比較清晰一些。當(dāng)然也可以讓界面線程A來做這個(gè)工作，協(xié)調(diào)的工作量也不是很大，這樣就可以不需要B線程。

單線程和多線程處理時(shí)間對(duì)比

多線程處理速度肯定不能簡(jiǎn)單地是單線程處理速度的N倍，這只是理想狀況。由于很多額外工作（線程開銷，準(zhǔn)備每個(gè)線程的數(shù)據(jù)，處理結(jié)果的合成，線程間同步，圖像子塊結(jié)合部的部分重復(fù)計(jì)算），多線程是不可能達(dá)到理想狀況的。下表列出了一副2400x1350大小的24bit圖像分成了12個(gè)子塊，分別在一臺(tái)I5 4300U（雙核四線程）筆記本上和一臺(tái)I5 6500（四核四線程）臺(tái)式機(jī)上，處理高斯模糊的大概的平均耗時(shí)。高斯模糊算法是簡(jiǎn)單的行列方向兩次一維計(jì)算，半徑取50。在我的測(cè)試中，還實(shí)時(shí)顯示了分塊的處理結(jié)果，速度上可能要更慢一點(diǎn)。

理想狀況下四線程耗時(shí)最多能減少75%，實(shí)際上肯定達(dá)不到。在雙核四線程平臺(tái)上，對(duì)亮度通道處理，多線程比單線程耗時(shí)減少了一半（50%）。對(duì)RGB通道，多線程比單線程耗時(shí)減少了大概59%。在四核四線程平臺(tái)上，多線程耗時(shí)在亮度通道和RGB通道處理時(shí)，分別減少了64%和69%?？梢钥吹?，多線程處理的加速效果還是相當(dāng)明顯的。話說牙膏廠超線程的效果還是挺驚人的，不然在雙核CPU上耗時(shí)減少是不可能超過50%的。當(dāng)然物理內(nèi)核的數(shù)量就更重要了。

而且還可以看到一個(gè)現(xiàn)象，在單線程處理下，RGB三通道的處理耗時(shí)是亮度通道處理耗時(shí)3倍略少，約為2.8倍（亮度通道還包括一些在RGB和亮度之間轉(zhuǎn)換的額外計(jì)算量）。而在多線程下，RGB三通道的處理時(shí)間大大小于亮度一個(gè)通道處理時(shí)間的3倍，約為2.38倍。相對(duì)于單線程，節(jié)省的時(shí)間更多了。這是因?yàn)镽GB的處理也是在子塊的一個(gè)線程中處理的，并沒有增加新的線程開銷。因此線程開銷也是必須考慮的一個(gè)因素，不可忽略。