最近在做專案，涉及到車道的檢測。由於在日光下，原本就是白色或者是黃色的車道線會比較得很不清晰，於是很自然的想到了灰度拉伸的方案，從少量資料來看的結果，是好的。以下圖為例，左圖是三通道圖，中間是利用opencv的cvtcolor函式轉換的灰度圖，可以看到在右側日光照射下的車道顯得很不清晰，所以對高灰度值區域進行灰度拉伸，可以得到有圖，顯然車道清晰了很多。雖然由此左側的車道沒有原本那麼明顯了，但也還在可以接受的範圍。
//存放直方圖的計算結果，是乙個256*1的矩陣
mat gray_hist;
calchist(&img, 1, , mat(), gray_hist, 1, &histsize, &histrange, true, false);
//cout << gray_hist.cols << "," << gray_hist.rows << endl;
//定義每個灰度值在圖上的寬度
int bin_w = 4;
int histimageheight = 500;
int histimagewidth = bin_w*histsize;
//畫出來是1024x500的，定義的時候是先行後列，與後續讀取數值是不同的！！
mat histimage(histimageheight, histimagewidth, cv_8uc3, scalar(0, 0, 0));
//對結果進行歸一化，才可以繪製到影象中
normalize(gray_hist, gray_hist, 0, histimageheight, norm_minmax, -1, mat());
for (int i = 1; i < histsize; i++)
//列印
}原因也很顯然，因為在做灰度拉伸時，是對灰度值帶入到函式中，計算的結果基本都不是乙個整數，所以需要取整。例如我們設定的兩個點是(160, 120)，(220, 240)，就意味著把0-160的數值壓縮到0-120，簡單的就是0-4壓縮到0-3。[0, 1, 2, 3, 4] ---> [0, 0.75, 1.5, 2.25, 3]，如果是簡單的向下取整，那麼結果是[0, 0, 1, 2, 3]，也就是把1的所有值都加到0中去，所以原本連續的0-4就變得不連續了，變得有乙個明顯的突起。那如果是把小的範圍拉伸到大的範圍呢？160-220拉伸到120-240，也就是原本60的跨度變成了120，例如160 --> 120, 161 ---> 122，所以121這個位置就空了出來，也就出現了上圖中有一段有一半的點為0的區域，正是對應了120-240中的奇數區域。
說不會有什麼影響，這個似乎倒不至於。對於肉眼所看到的影象並沒有什麼特別的邊緣或者干擾，興許有人會說那不要截斷用cvround有沒有用？並沒有哈哈哈，因為實質上都是把某個灰度值的所有點都給調整到另乙個灰度值，只要是這種"全部"的操作，就會對灰度直方圖有如上的影響。不過這種影象結果，實際上更多是因為我畫圖，並不是真正的直方圖，而是將乙個乙個的點連線起來的折線圖。如果畫成直方圖的形式應該就好了。
關於makefile的一點思考
在gnu編譯工具軟體中，如果對單一的原始檔進行編譯，可執行指令如下 gcc o x x.c 此指令會將原始檔編譯為目標檔案。若是對執行緒類檔案進行編譯，則在末尾加上 lpthread指令。但若是對多檔案進行編譯，即若是編譯的目標檔案同時包含另一檔案中的函式。則在編譯的時候需將另一檔案加到編譯原始檔中...
關於指標的一點思考
指標是乙個變數，所不同的是，它存的是位址。因為資料型別決定著如何解釋這個位址 位元組數和操作 因此根據的資料型別的不同，指標又有不同的型別。某個物件 a 的位址範圍為 a,a size n 其中size n是a所佔的位元組數 比如乙個一維陣列int a 10 位址範圍為 a,a 10 sizeof ...
關於演算法的一點思考。。。
關於演算法的一點思考。在實踐過程中，我發現 有時候要解決乙個問題，可以設計幾個演算法分步完成任務，這樣處理起來比較簡單，但是情況並非總是如此，有時，我們需要將幾個步驟放在同乙個演算法內連帶處理，這樣才比較容易處理問題。我還發現，有時候，解決問題的演算法，是被發現出來的，並加以一步一步的檢驗才得以確定...