單向資訊傳輸系統設計實現

這樣的系統，必然是真正的「機器視覺」系統，不僅包括影象演算法的處理，而且需要包括裝置的架設，並且結合多種技術（ocr,***），具有一定挑戰意義和現實意義。這裡做簡單實現。

一、基於ocr的單向資訊傳輸系統。

所謂單項資料傳輸，書中提到的方法是採用ascii碼進行分析。但是我認為採用ocr識別的話，如果能夠很好地控制住傳輸的資訊，成功率就會很高。

什麼資訊需要單項傳輸？就是那些實時更新的資料，資料量不是很大但是時效性很大：比如天氣、比如溫度、比如時間等資訊。這個資訊量一旦變得很大，那麼採用機器視覺的方法解決單向傳輸問題，就顯得不是那麼恰當。根據一些經驗，設計這樣的草圖：

資料不需要太多或者變化太快，只要取樣的頻率比變化的頻率更快就可以。採用csharp

1）資料獲取，這裡基於之前介紹過的gopre程式獲得攝像頭的資料

2）資料進行校正，修改成這樣的結果

3）參考答題卡程式，對影象進行修正

需要注意，在這種情況下進行ocr識別，對於影象的問題的要求很高，由於裡面涉及到模板識別的**，如果輸入有問題，程式可能會報錯。這是在實際專案中需要注意的地方。

二、基於***的單向資訊傳輸系統。

這個時候我在設想，如果採用了直接字元ocr的方法，這種方法的優點是思路清晰、可以處理大量資訊；相比較而言，許多解決方案可能會採用一維碼或者是***的方法。這種方法，帶有冗餘校驗資訊，資料傳播的魯棒性大大增強，但是複雜度也增強了，可以說互有利弊。

***可以說是今日這個時代裡面發展比較迅速的乙個技術。既然前面已經將ocr做到了一定的程度，這裡，我轉變思路，而是用***來所謂「單向傳輸問題」

1）基於zxing，編寫***編碼解碼器。這個庫比較優秀，對於***的輸入也有一些預先的處理，不是很挑。而且是開源**庫，有時間值得研究一下。

2）採集

經過一定的測試，發現將解析度設定在640*480的時候，無論是

還是

都是可以被識別的，即使傾斜也沒有問題。但是識別是需要一定的時間的。本來以為可能需要opecv做需要預處理的，結果也不需要進行預先處理。這種思路經過多次測量，結果是可行的。

3）選擇實現模式

因為在這個解決方案中，主要是利用zxing的介面來實現的，而其中影象處理的東西並不多，但是涉及到了攝像頭的影象獲取，所以選擇合適的實現模式。

emgucv例程式提供了cameracapture的效果，借用過來

4）選擇實現模式

具體的**就是柔和了***生成和解碼；以及emgucv的攝像頭操作。難度不是很大。

三、小結

當程式變成動態的時候，遇到了更多的挑戰，你必須要編寫相關的介面程式、必須處理攝像頭的問題：往往是需要將幾件事情一起來做，有的時候還要涉及到多執行緒。

越是複雜的構造需要考慮的問題越多，越難以保持系統的魯棒。但是，越是複雜的事情，越是值得去探索、實現。我相信能夠獲得的價值也就越高。

這裡展示了兩個想法的原型，關鍵是思路，希望能夠對所需之人有所幫助。