一種可實時處理 O(1)複雜度圖像去霧算法的實現。

　　在我博文的一系列的文章，有很多算法都於去霧有關，好比限制對比度自適應直方圖均衡化算法原理、實現及效果、局部自適應自動色階/對比度算法在圖像加強上的應用這兩個加強算法都有必定的去霧能力，而最直接的就是《Single Image Haze Removal Using Dark Channel Prior》一文中圖像去霧算法的原理、實現、效果及其餘 一文，描述了暗通道去霧這一state-of-the-art algorithms的過程和實現，雖幾經優化，對於經常使用的視頻1024*768大小的圖片，算法處理部分仍是須要70MS的時間（I3 筆記本CPU），所以，這一算法用於實時要求時還有必定的難度，而且優化後的算法基本沒法並行，而可並行的算法重複計算大，因爲不熟悉GPU方面的理念，不曉得使用不優化的算法靠GPU是否能有多大速度的提高。

     爲此，我一直在找尋相關的論文，這種找尋的蹤影通常就是看到一篇好論文--》看其參考文獻--》再看參考文獻的參考文獻，這樣循環下去。 而後有某種機會或巧合，又看到一篇好論文，重複前面的過程，你就會發現不少交集，慢慢的就會有一些好運向你招手。 話說我本來只看英文的文獻，因此一直忽略了國內的文章，前幾日，一個QQ朋友推薦了一篇清華大學的論文，下載後稍微看了下，以爲其描述的結果仍是比較吸引人的，因而就實現了下，實時的效果應該說很不錯，這裏就簡單的介紹並推薦給你們。

      原始論文下載：基於單幅圖像的快速去霧.pdf  ，做者劉倩，陳茂銀，周東華，感謝他們（她們）。

      算法原理沒有什麼複雜的地方，其實說原理，還不如說經驗或實驗，由於論文中能夠用理論來推導的公式確實很少。不過這也不要緊，有用的東西就應該拿來用。

      算法的執行流程直接貼用原圖的文字來講明吧：

     

     先挑點小瑕疵，好比步驟5中的L有個下標，而其餘涉及到L的地方去沒有，這叫先後不一致。論文中也還有一些其餘的地方有些小錯誤，因此看啊，即便是清華的文章，在編輯審覈這一塊仍是至關的不嚴謹。

     咱們先來看看算法，一、二、三、4步都沒有什麼說的，第五步是求大氣透射率的過程，這裏ρ是一個用來調節的參數，當ρ值越大時，結果圖像總體越暗，去霧的效果更明顯，ρ較小時，圖像偏白，有明顯的霧氣。第六步求全局大氣光A值，用了很簡單的方式，即求原始圖像的RGB全部像素份量的最大值（這個估計99%都爲255了）何暗通道的最大值的平均值，而且注意到RGB三個通道用的A值都爲同一個數字。這個和我在何凱明的文章的分析也有類似的地方。 第七步用了標準的去霧模型來求結果值。

     在來看看算法的效率問題， 從算法的初步分析來看，算法的效率取決於第3步和第7步，第三步中，使用了均值模糊，目前已經存在大量的O(1)均值模糊算法，但是O(1)只能表示算法的執行速度和參數的大小無關係，並不表示算法就很快。好比基於積分圖的模糊算法是廣爲認知的O(1)算法，可是他也存在不少問題，最嚴重的就是數據的溢出，當圖像較大和偏白時，對圖像積分圖的累加和存在超出int.Maxvalue所能表達的範圍的問題，解決辦法就是積分圖內的數據所有使用long類型表示，這將致使程序多佔用Width*Height*4字節的大小的內存，且在32位系統還流行的狀況進一步下降程序的速度（32位系統64位整數的計算速度要比32位整數慢)。積分圖的另一個問題就是計算積分圖的過程難以並行化，由於一個像素的積分值是依賴於其前面一系列像素的相關結果值的。另一種優化方式就是先計算行方向的平均值，而後再計算列方向的值。這種方式在同一行（列）內，算法依舊必行順序執行，這也是由於先後影響的緣由。可是不一樣行（列）之間的計算是沒有任何關係，所以很是適合GPU這種可大規模並行計算的場合，但不適於CPU這種重量級的線程併發（反而會慢）。這種算法若是爲了精度會須要一個和原圖同樣大小，佔用字節Width*Height*4字節大小的的中轉區用來保存中間計算的結果。在彩色圖像高速模糊之懶惰算法一文中，我採用了另一種處理方法，利用列直方圖相關的技術，只需對每一個循環的起始位置處的像素作特殊處理，其餘位置的利用簡單的一加一簡便可得到累加和，從而快速的實現模糊，我實際的編碼代表，這種方式比其餘的方式都要快。可是有一個缺點，不適合於並行計算，不過在CPU上這個頗有優點。

      再觀察下第七步。第七步存在兩個須要優化的地方，第一，存在除法；第二，有浮點運算。若是直接編碼必然會帶來性能損失，可是，觀察下在第七步的公式中，只有兩個自變量，H(X)和L(X),而且自變量的取值都爲[0,255]之間的整數，所以，若是事先建議一個查找表，因爲這個查找表的計算量只有 256*256次，要遠遠的小於直接計算的次數，必然能提升程序的速度。256這個數字還有個好處，就是能夠用移位來輔助計算查表表的下標，部分參考代碼以下所示：

unsigned char * Table = (unsigned char  *) malloc (256*256*sizeof(unsigned char));
for (Y = 0; Y < 256; Y++)
{
    Index=Y<<8;
    for (X = 0; X < 256; X++)
    {
        Value = (Y-X) /(1-X*InvA);
        if (Value > 255)
            Value = 255;
        else if (Value < 0)
            Value = 0;
        Table[Index++]= Value;
    }
}

　　其中InvA = 1 / A;A爲全局大氣光值。 Value需爲double類型的變量。

     當咱們須要計算F(x)時，查表的方式爲 F(X)=Table[(H[X]<<8 )+ L[X]];

     實際的效果代表，這樣的方式對於1024*768的圖，能夠提速10ms。

     那麼對於其餘步驟也有不少優化的注意事項，好比計算M(X)中全部元素的平均值M_av這一塊，徹底沒有必要在開一個循環，而是能夠在進行步驟3的時候同步進行，你們知道，循環楚了要計算循環體內部的東西外，還要有個循環計數器的更新的，何須浪費這個時間呢。

for (Y = 0, DarkPt = DarkChannel; Y < Height; Y++)
{
    ImgPt = Src + Y * Stride;
    for (X = 0; X < Width; X++)
    {
        Min = *ImgPt;
        if (Min > *(ImgPt + 1)) Min = *(ImgPt + 1);
        if (Min > *(ImgPt + 2)) Min = *(ImgPt + 2);
        *DarkPt = Min;                                        //    三通道的最小值
        Sum    +=    Min;                                        //  累積以方便後面求平均值
        ImgPt += 3;
        DarkPt++;
    }
}
Mean =(double)Sum /(Width*Height*255);

    還有好比第6步中，分別求原圖RGB三像素最大值以及安通道中的最大值的過程，傳統的過程以下代碼：

int Max1 =0 ;
for (Y = 0; Y < Height; Y++)
{
    ImgPt = Src + Y * Stride;
    for (X = 0; X < Width; X++)
    {
        if (Max1 < *(ImgPt)) Max1 = *(ImgPt);
        if (Max1 < *(ImgPt + 1)) Max1 = *(ImgPt + 1);
        if (Max1 < *(ImgPt + 2)) Max1 = *(ImgPt + 2);
        ImgPt += 3;
    }
}

　　特別是對於求原圖的最大值，實際上不少狀況下這個值都爲255，所以若是Max1變量已是255，則循環徹底沒有必要進行下去了，所以，若是改成下述代碼，必然能夠減小計算量：

for (Y = 0; Y < Height; Y++)
{
    ImgPt = Src + Y * Stride;
    for (X = 0; X < Width; X++)
    {
        if (Max1 < *(ImgPt)) Max1 = *(ImgPt);
        if (Max1 < *(ImgPt + 1)) Max1 = *(ImgPt + 1);
        if (Max1 < *(ImgPt + 2)) Max1 = *(ImgPt + 2);
        ImgPt += 3;
    }
    if (Max1==255) break;
}

      注意，這個break語句必須放在Y循環中，若是放在X循環中，雖然提早退出循環的可能性會增長，可是判斷的工做量帶來的損失更多。
      綜合上述優化，我用C++寫了個DLL，對於1024*768的圖像在個人I3的機器上平均能達到18ms每副圖像的計算速度，至關於56fps,只佔用了單核的資源，考慮解碼、顯示等等其餘過程所佔用的時間，應該是可以靠CPU實現20fps的實時速度的。

      在內存佔用上，約須要> 3*Width*Height+256*256字節的空間（不包括圖像自己的），若是用在連續的視頻處理上，這部份內存就不須要頻繁的分配和釋放，可能也對速度的保證有好處。

     程序下載地址： http://files.cnblogs.com/Imageshop/FastHazeRemovalTest.rar

  

　參數的選取：

　   爲了得到好的效果，該算法須要選擇恰當的參數，咱們爲此作了一些測試。對於半徑參數，個人我的建議是取值不要小於50或圖像寬度和高度最大值的的1/20，好比對下面的圖像（原圖大小不是下圖中的大小，這裏是爲了方便瀏覽縮小顯示的），ρ取1.28時（對於上圖中的去霧程序選擇爲128），半徑取不一樣參數時的效果：

   

   　　　　　　　　　　原圖　　　　　　　　　　　　　　　　　　　　　　　       　r=16　　　　　　　　　　　　　　　　　　　  　　　　　r=50

   注意上面中間的圖，一羣飛鳥的周邊明顯有格格不入的白色霧氣，而在右側的圖中，飛鳥則天然的融入了背景圖像中。

   另外，當半徑足夠大時，半徑的大小對輸出的結果的影響不大。

   ρ參數的大小控制了圖像去霧能力的大小，越大，霧氣越少，圖像越顯得暗，越小，圖像偏白，霧氣越濃，下面給出了在半徑R=50,取不一樣ρ值的效果。

   

   

   

    　　　　　　　　　　原圖　　　　　　　　　　　　　　　　　　　　　　　       　ρ=0.75　　　　　　　　　　　　　　　　　　　  　　　　　ρ=1.3

     ρ值如何取才能得到最佳效果，這個沒有理論依據，須要根據具體圖像進行測試，不過通常在1.2到1.5之間的效果能綜合去霧和保持圖像清晰的能力。

     從更多的測試圖看，該去霧算法的效果都是較爲理想的，並且對於填充部位出現瑕疵的狀況也出現的不多，速度上更是沒的說，所以，做爲一種實時去霧工業化也應該是可行的。

     試過將過程當中的均值模糊更改成高斯模糊，在速度上會稍有降低，也能達到實時要求，但去霧的效果彷佛尚未均值好。

    

 

*****************************基本上我不提供源代碼，可是我會盡可能用文字把對應的算法描述清楚或提供參考文檔*********************

*************************************由於靠本身的努力和實踐寫出來的效果才真正是本身的東西，人必定要靠本身****************************

*********************************做者： laviewpbt   時間： 2013.11.4   聯繫QQ:  33184777  轉載請保留本行信息************************