項目簡介
1.1實驗目標重述
ARM架構的微處理器在追求低成本、低功耗和高性能的嵌入式系統領域占有主導地位，學習ARM微處理器的嵌入式系統設計對于未來的學習與實踐都有重要的意義。本次實驗，主要是基于KDLAB-I 嵌入式系統實驗平臺（核心為ARM9架構的S3C2440微處理器），在Linux系統下進行設計與編程，利用OV9650攝像頭實現攝像、采集圖片、分析圖片、識別顏色的功能。
九層之臺，起于壘土，整個實驗跨度達兩周，具體言之，又可以細分為以下幾個目標:
1、 熟悉Linux虛擬機的安裝和Linux系統的使用，掌握常見的命令，熟悉Linux系統下的操作邏輯；
2、 了解ARM嵌入式Linux系統的開發過程，掌握修改、編寫、燒 寫應用程序和驅動程序的方法；
3、 掌握嵌入式Linux系統開發交叉編譯環境的建立和使用；
4、 熟悉實驗臺上常用外設的使用方法和連接方式；
5、 熟練掌握攝像頭的應用程序的編寫和調試；
6、 熟悉RGB-565、RGB-888和HSI等常見顏色空間的轉換以及編程的實現；
7、 掌握位圖的保存格式、數據格式和保存方法，并在Linux下編程實現；
8、 掌握八鄰域生長算法的算法核心和編程實現，并能夠在嵌入式 Linux系統中實現對拍攝圖片的正確連通；
9、 熟悉嵌入式系統的編程和調試方法，學會利用輸出來進行調試；
1.2作品功能分析
1、 攝像頭能夠實現實時監視功能，將拍攝到的圖像實時顯示在 LCD屏幕上；
2、 具備截圖功能，能夠定時或根據輸入保存當時的實時畫面并另存為圖片；
3、 具備分析功能，能夠判別圖中是否存在面積達到一定大小的紅色色塊，并判定其形心和半徑；
4、 具備結果可視化功能，可以將圖片處理為除原圖紅色區域外均為黑色的圖形，更加直觀；
二、功能流程圖
三、實驗過程
準備:Linux平臺下ARM嵌入式編程基本操作
主要包括基本文件操作、定制與修改內核、給開發板燒寫定制的嵌入式Linux系統以及虛擬機與ARM9開發板的通訊。
其中，燒寫系統或許是最重要的一項技能了，因為在實驗的過程中幾乎每天都會遇到莫名其妙的故障，甚至連重啟都解決不了（比如無限自動重啟），這時候我就采取了最笨的辦法——重新安裝系統。
例程學習——camtest.cpp
Trect類
例程將TRect用作屏幕顯示的基類，定義了圖像存儲的起始地址Addr， 圖像的尺寸Size、寬度Width、高度 Height、每行圖像存儲時占 用的字節數LineLen以及圖像的位數BPP，并聲明和定義了將緩存數據顯示到屏幕上的DrawRect函數和清屏函數Clear。在這次實驗中，完成bmp圖像的存儲和圖像分析功能的SavePic函數都是通過在DrawRect基礎上加以修改來實現的。
TFrameBuffer類
TFrameBuffer作為TRect類的派生類，主要作為緩存，將 TVideo存儲的圖片信息通過映射放到內存中，便于以后的直接讀 寫，也可以少用read（）和write（）這類讀寫函數，加快讀寫 速度，其他部分沒有太大的改動。
TVideo類
TVideo同樣是TRect類的派生類，這個派生類主要負責將攝像頭拍攝到的圖像存儲在緩存區中，以待TFrameBuffer轉存和顯示。
主函數
Camtest的主函數比較簡單，短短的幾行卻完成了很多事情，定義了一個TFrameBuffer對象和一個TVideo對象，調用FetchPicture函數存儲圖像之后，再調用DrawRect將圖像顯示到屏幕上。使用for結構無限循環此動作，并在最外層使用try-catch的結構來捕捉意外動作。
雙線程
需求分析
最初并沒有打算使用雙線程，但是在仔細分析之后，如果需要加入按鍵來決定是否采集分析圖像，那么久不能使用單線程，否則將會出現用戶不按鍵，系統就一直等待的現象，這顯然不是一個合格的系統所應有的樣子。所以還是硬著頭皮使用了雙線程。一個線程負責鍵盤的檢測，另一個線程負責實時拍攝和顯示功能，并且，沒有設置互斥量進行交互以保證完全的實時運行，設置了一個信息量以負責兩個線程之間的信息傳遞。
雙線程例程pthread學習
在雙線程的例程pthread中，首先聲明了互斥量pthread_tmutex，之后聲明了主線程writer_function和子線程reader_function，在主函數中創建了子線程的進程，而主函數則運行主線程，兩者通過互斥量進行交互，分別作為生產者和消費者增加和減少虛擬的緩存buffer_has_item，并在PC終端上對剩余的緩存產品進行顯示。
雙線程設計
基于之前的分析，將雙線程例程中的互斥量去掉以保證兩個線程能夠完全獨立地工作。當然在Makefile中還要在編譯語句的最后加上-lpthread，把多線程的庫鏈接上。在兩個獨立的線程中進一步添加功能。
顏色識別
什么是顏色空間
顏色通常用三個相對獨立的屬性來描述，三個獨立變量綜合作用，自然就構成一個空間坐標，這就是顏色空間。而顏色可以由不同的角度，用三個一組的不同屬性加以描述，就產生了不同的顏色空間。雖然被描述的對象顏色是客觀存在的，但是很明顯這是多指標非線性的，由于不同場合的需求不同，因此不同的顏色空間仍有存在的必要。顏色空間按照基本結構可以分兩大類：基色顏色空間和色、亮分離顏色空間。前者的典型是RGB；后者包括 YCC/YUV、Lab、以及一批“色相類顏色空間”。
RGB顏色空間
RGB顏色空間是一種大的分類，具體而言RGB空間還包含多種空間，其中sRGB是HP和Microsoft聯合制定的標準RGB空間，除此之外還有Adobe RGB，Apple RGB，ColorMatch RGB等等，他們通過不同的方式表示RGB三種顏色，使得它們具有不同的色彩寬度，GAMMA值也是不一樣的，但是在此處并不需要多加討論。
本實驗平臺上攝像頭OV9650回傳的數據是RGB565格式的，相對RGB888格式（俗稱24位真彩色）犧牲了一定的信息量，由于在想HSI空間轉換的時候需要全部的RGB信息，因此還需要轉化到RGB888格式，這其中更還涉及到補償，會在后面敘述。
HSI顏色空間
HSI模型屬于第二類色亮分離的顏色空間，其建立基于兩個重要的事實： 1°L分量與圖像的彩色信息無關;2°H和S分量與人感受顏色的方式是緊密相聯的。這些特點使得HSI模型非常適合彩色特性檢測與分析。
HSI模型是美國色彩學家孟塞爾(H.A.Munseu)于1915年提出的，它反映了人的視覺系統感知彩色的方式，用色調(Hue)、色飽和度(Saturation或Chroma)和亮度 (Intensity或Brightness)來描述色彩其中，色調與光波的波長有關，它表示人的感官對不同顏色的感受，如紅色、綠色、藍色等，它也可表示一定范圍的顏色，如暖色、冷色等。飽和度 表示顏色的純度，純光譜色是完全飽和的，加入白光會稀釋飽和度。飽和度越大，顏色看起來就會越鮮艷，反之亦然。亮度 對應成像亮度和圖像灰度，是顏色的明亮程度。HSI色彩空間可以用一個圓錐空間模型來描述。雖然這種圓錐模型相當復雜，但確能把色調、亮度和色飽和度的變化情形表現得很清楚。為了便于色彩處理和識別，人的視覺系統經常采用HSI色彩空間， 它比RGB色彩空間更符合人的視覺特性。在圖像處理和計算機視覺中大量算法都可在HSI色彩空間中方便地使用，它們可以分開處理而且是相互獨立的。因此，在HSI色彩空間可以大大簡化圖像分析和處理的工作量。HSI色彩空間和RGB色彩空間只是同一物理量的不同表示法，因而它們之間存在著轉換關系。
RGB565->RGB888
將RGB565格式轉換為RGB888以進行到HIS顏色空間的轉換的必要性之前已經講過。我們知道RGB565格式分別保存了色彩的RGB分量的高5位、6位、5位，那么，亟需做的一件事情就是決定如何添加低位信息，最直接的想法是低位補零，但是實踐表明效果并不好，現在被廣泛采用是是一種稱為量化補償的方法，有三個步驟：
1. 將原數據填充至高位
2. 對于低位，用原始數據的低位進行補償
3. 如果仍然有未填充的位，繼續使用原始數據的低位進行循環補償
解釋一下循環補償的概念：
16bit RGB565 -> 24bit RGB888 的轉換
8bit RGB565 R4 R3 R2 R1 R0 - - - G2 G1 G0 B1 B0
24bit RGB888 R2 R1 R0 0 0 0 0 0 G2 G1 G0 0 0 0 0 0 B1 B0 0 0 0 0 0 0
24bit RGB888 R2 R1 R0 R2 R1 R0 0 0 G2 G1 G0 G2 G1 G0 0 0 B1 B0 B1 B0 0 0 0 0
24bit RGB888 R2 R1 R0 R2 R1 R0 R2 R1 G2 G1 G0 G2 G1 G0 G2 G1 B1 B0 B1 B0 B1 B0 0 0
24bit RGB888 R2 R1 R0 R2 R1 R0 R2 R1 G2 G1 G0 G2 G1 G0 G2 G1 B1 B0 B1 B0 B1 B0 B1 B0
RGB顏色空間到HSI顏色空間的轉換
** 紅色界定**
量化補償只是優化顯示效果，并不能改變實際所觀測的結果，所以，在編程的時候直接考慮從原始的RGB565格式的數據著手。
由于G是高6位，B是高5位參照網上資料，當G、B均小于10左右，R大于200，可以視為紅色，故此處僅考慮G末位為000001/000000;
B為00000;紅色為111**;
即只有這幾種可能：
11100000 11101000 11110000 11111000 32+64+128+8+16=224，232，240，248
00000000 00100000 0/32
一些小Trick
宏與三目運算符嵌套
在進行RGB到HSI的轉換的時候，有一個比較RGB三者大小的步驟，本來是寫的if語句嵌套，但是想想貌似有點累贅，于是便選擇了三目運算符的嵌套并寫成了宏，效果還不錯，減少了二十多行的代碼量。
#define MAX(a,b,c) ((a>b)?((a>c)?a:c):((b>c)?b:c))
實驗記錄
Segmentation Fault
在嘗試進行更進一步的圖像處理的時候，試圖將圖像數據寫入數組再進行分析，但是出現了
=============
RESOURCE
今天在REVIEW代碼的時候，發現了這樣一個宏定義：
define COLOR_TO_MTK_COLOR_SIMUL(color) ((((color) >> 19) & 0x1f) << 11) \
|((((color) >> 10) & 0x3f) << 5) \
|(((color) >> 3) & 0x1f)
大家知道這個宏是用來干什么的嗎？
仔細分析后，原來就是實現了RGB888到RGB565的轉換，查閱相關資料后，發現網絡上有一篇牛人寫的東東，在此和大家分享。
講一下量化壓縮與量化補償吧
在進行色彩格式轉換的時候，經常會遇到色彩量化位數的改變，比如說從 24bit RGB888 到 16bit RGB565 的色彩轉換。所謂量化壓縮與量化補償都是我個人所提出的概念，現說明如下。
量化壓縮，舉例：
24bit RGB888 -> 16bit RGB565 的轉換
24ibt RGB888 R7 R6 R5 R4 R3 R2 R1 R0 G7 G6 G5 G4 G3 G2 G1 G0 B7 B6 B5 B4 B3 B2 B1 B0
16bit RGB656 R7 R6 R5 R4 R3 G7 G6 G5 G4 G3 G2 B7 B6 B5 B4 B3
量化位數從8bit到5bit或6bit，取原8bit的高位，量化上做了壓縮，卻損失了精度。
量化補償，舉例：
16bit RGB565 -> 24bit RGB888 的轉換
16bit RGB656 R4 R3 R2 R1 R0 G5 G4 G3 G2 G1 G0 B4 B3 B2 B1 B0
24ibt RGB888 R4 R3 R2 R1 R0 0 0 0 G5 G4 G3 G2 G1 G0 0 0 B4 B3 B2 B1 B0 0 0 0
24ibt RGB888 R4 R3 R2 R1 R0 R2 R1 R0 G5 G4 G3 G2 G1 G0 G1 G0 B4 B3 B2 B1 B0 B2 B1 B0
說明：第二行的 24bit RGB888 數據為轉換后，未進行補償的數據，在精度上會有損失
第三行的 24bit RGB888 數據為經過量化補償的數據，對低位做了量化補償
可以很容易的證明，這樣的補償方法是一種合理的線性補償。補償的原理很簡單，大家仔細想一下就明白了，因此不再詳細說明。
總結一下：
量化壓縮的方法：三個字取高位
量化補償的方法：
1. 將原數據填充至高位
2. 對于低位，用原始數據的低位進行補償
3. 如果仍然有未填充的位，繼續使用原始數據的低位進行循環補償
解釋一下循環補償的概念：
8bit RGB332 -> 24bit RGB888 的轉換
8bit RGB332 R2 R1 R0 G2 G1 G0 B1 B0
24bit RGB888 R2 R1 R0 0 0 0 0 0 G2 G1 G0 0 0 0 0 0 B1 B0 0 0 0 0 0 0
24bit RGB888 R2 R1 R0 R2 R1 R0 0 0 G2 G1 G0 G2 G1 G0 0 0 B1 B0 B1 B0 0 0 0 0
24bit RGB888 R2 R1 R0 R2 R1 R0 R2 R1 G2 G1 G0 G2 G1 G0 G2 G1 B1 B0 B1 B0 B1 B0 0 0
24bit RGB888 R2 R1 R0 R2 R1 R0 R2 R1 G2 G1 G0 G2 G1 G0 G2 G1 B1 B0 B1 B0 B1 B0 B1 B0
看了這個，應該明白則么回事了吧，其中B分量，進行了四輪的補償，達到要求。
量化補償的必要性，從直覺上講，我所提出的這種補償方法是正確的(因為我并沒有嚴格的去證明)，進行這樣的補償，在做色彩各式轉換的時候，能夠明顯的改善色彩效果，減少精度上的損失。
對256色調色板模式的認識和應用，順便講一下這個，因為量化壓縮和量化補償剛好可以應用到調色板模式下。大家都知道，很早以前就有人提過出256色的標準調色板的概念(有的人又稱之為抖動調色板或者萬能調色板)，其實這樣的調色板并不神秘。256色中，一個像素點用8bit表示，那么如果采用 8bit RGB332 的格式，一切問題都可以想通，并且可以進行很好的處理了。對于每個 RGB332 的顏色，都可以使用量化補償的做法，將其轉換為 24bit RGB888 的顏色格式，然后將其設置為調色板即可。這樣，實質上是將256色調色板模式，轉換為了 8bit RGB332 的像素格式。這樣的調色板方式，更加利于某些方面的處理，比如調色板匹配、Alpha混合等。由于采用了這樣的方法，一個像素點的顏色值，與其實際的RGB顏色值，可以很方便的通過量化補償的方法轉換出來，然后就可以對各個顏色分量進行計算，計算完畢，再使用量化壓縮的方法，就可以生成最終需要的顏色值。而所謂的調色板匹配的問題，當然也更加好解決了。關鍵是要把問題想通，把握事物的本質，才能找到簡單而優美的解決問題的方法。
以前我對標準調色板的認識也存在很多錯誤，導致在分析和解決問題上，沒有能找到最好的方法。網上也有許多人寫過有關256色模式下 Alpha Blending 的文章，但是都存在許多認識上的不足，導致最后給出的算法時間和空間的復雜度都太大。我也有過一篇有關256色Alpha混合的文章，但限于當時對事物的認知能力，因此現在看來以前的許多文章是慘不忍睹。大家都在進步，以后有機會再將新的認識寫成文章，同大家分享。
