當(dāng)我們開發(fā)應(yīng)用程序 BooksPlus 以改變讀者的體驗(yàn)時(shí)，我們的機(jī)器視覺和圖像識(shí)別試驗(yàn)之旅加速了。BooksPlus使用圖像識(shí)別使打印的頁面栩栩如生。用戶可以通過使用 BooksPlus 應(yīng)用程序掃描書中的圖像來沉浸在豐富的交互式內(nèi)容中。

例如，您可以掃描一篇關(guān)于詩人的文章并立即收聽詩人的音頻。同樣，您可以掃描歷史藝術(shù)品的圖像并觀看紀(jì)錄片剪輯。

當(dāng)我們開始開發(fā)時(shí)，我們使用了市售的 SDK，當(dāng)我們嘗試在本地識(shí)別圖像時(shí)效果非常好。盡管如此，當(dāng)我們的圖像庫超過幾百?gòu)垐D像時(shí)，這些都會(huì)失敗。一些服務(wù)執(zhí)行基于云的識(shí)別，但它們的定價(jià)結(jié)構(gòu)不符合我們的需求。

因此，我們決定嘗試開發(fā)我們自己的圖像識(shí)別解決方案。

我們實(shí)驗(yàn)的目標(biāo)是什么？

我們專注于構(gòu)建一個(gè)可以擴(kuò)展到我們需要識(shí)別的數(shù)千張圖像的解決方案。我們的目標(biāo)是在實(shí)現(xiàn)高性能的同時(shí)靈活地進(jìn)行設(shè)備上和云端圖像匹配。

當(dāng)我們擴(kuò)展 BooksPlus 應(yīng)用程序時(shí)，目標(biāo)是建立具有成本效益的結(jié)果。我們確保我們自己的努力與 SDK 一樣準(zhǔn)確（在誤報(bào)和誤報(bào)匹配方面）。我們的解決方案需要與原生 iOS 和 Android 項(xiàng)目集成。

選擇圖像識(shí)別工具包

我們旅程的第一步是將圖像識(shí)別工具包歸零。我們基于以下因素決定使用OpenCV ：

• 豐富的圖像相關(guān)算法集合：OpenCV 集合了超過2500 種優(yōu)化算法，得到了學(xué)術(shù)界和工業(yè)界的諸多貢獻(xiàn)，是最重要的開源機(jī)器視覺庫。
• 人氣：OpenCV估計(jì)下載量超過1800萬，擁有4.7萬用戶社區(qū)，技術(shù)支持豐富。
• BSD 許可產(chǎn)品：由于 OpenCV 是 BSD 許可產(chǎn)品，我們可以根據(jù)需要輕松修改和重新分發(fā)它。由于我們想為這項(xiàng)技術(shù)貼上白標(biāo)，OpenCV 將使我們受益。
• C 接口：OpenCV 有 C 接口和支持，這對(duì)我們來說非常重要，因?yàn)樵?iOS 和 Android 都支持 C；這將允許我們?yōu)閮蓚€(gè)平臺(tái)擁有一個(gè)代碼庫。

我們旅程中的挑戰(zhàn)

在為我們的用例開發(fā)有效的解決方案時(shí)，我們面臨著許多挑戰(zhàn)。但首先，讓我們先了解圖像識(shí)別的工作原理。

什么是圖像識(shí)別中的特征檢測(cè)和匹配？

特征檢測(cè)和匹配是每個(gè)計(jì)算機(jī)視覺應(yīng)用程序的重要組成部分。它檢測(cè)物體、檢索圖像、機(jī)器人導(dǎo)航等。

考慮以略微不同的角度單擊單個(gè)對(duì)象的兩個(gè)圖像。你如何讓你的手機(jī)識(shí)別兩張圖片包含相同的對(duì)象？特征檢測(cè)和匹配在這里發(fā)揮作用。

特征是表示圖像是否包含特定模式的一條信息。點(diǎn)和邊可以用作特征。上圖顯示了圖像上的特征點(diǎn)。必須以一種在光照、平移、縮放和平面內(nèi)旋轉(zhuǎn)變化下保持不變的方式選擇特征點(diǎn)。使用不變特征點(diǎn)對(duì)于成功識(shí)別不同位置下的相似圖像至關(guān)重要。

第一個(gè)挑戰(zhàn)：性能緩慢

當(dāng)我們第一次開始使用 OpenCV 進(jìn)行圖像識(shí)別實(shí)驗(yàn)時(shí)，我們使用了推薦的 ORB 特征描述符和 FLANN 特征匹配 2 個(gè)最近鄰。這給了我們準(zhǔn)確的結(jié)果，但速度非常慢。

設(shè)備上的識(shí)別對(duì)幾百?gòu)垐D像效果很好；商業(yè) SDK 在 150 張圖片后會(huì)崩潰，但我們能夠?qū)⑵湓黾拥?350 張左右。但是，這對(duì)于大型應(yīng)用程序來說是不夠的。

要了解這種機(jī)制的速度，請(qǐng)考慮一個(gè)包含 300 張圖像的數(shù)據(jù)庫。匹配圖像最多需要 2 秒。以這種速度，包含數(shù)千張圖像的數(shù)據(jù)庫將需要幾分鐘來匹配一張圖像。為了最好的用戶體驗(yàn)，匹配必須是實(shí)時(shí)的，一眨眼的功夫。

需要最小化在管道的不同點(diǎn)進(jìn)行的匹配數(shù)量以提高性能。因此，我們有兩個(gè)選擇：

1. 減少附近的鄰居數(shù)量，但我們只有 2 個(gè)鄰居：盡可能少的鄰居。
2. 減少我們?cè)诿繌垐D像中檢測(cè)到的特征數(shù)量，但減少數(shù)量會(huì)影響準(zhǔn)確性。

我們決定每張圖像使用 200 個(gè)特征，但時(shí)間消耗仍然不能令人滿意。

第二個(gè)挑戰(zhàn)：低準(zhǔn)確度

另一個(gè)存在的挑戰(zhàn)是在匹配包含文本的書籍中的圖像時(shí)準(zhǔn)確性降低。這些書有時(shí)會(huì)在照片周圍有文字，這會(huì)給文字添加許多高度聚集的特征點(diǎn)。這增加了噪音并降低了準(zhǔn)確性。

一般來說，這本書的印刷造成的干擾比其他任何事情都多：頁面上的文本創(chuàng)建了許多無用的特征，高度聚集在字母的銳利邊緣上，導(dǎo)致 ORB 算法忽略了基本的圖像特征。

第三個(gè)挑戰(zhàn)：原生 SDK

在解決了性能和精度的挑戰(zhàn)之后，最終的挑戰(zhàn)是將解決方案封裝在一個(gè)支持多線程并兼容 Android 和 iOS 移動(dòng)設(shè)備的庫中。

我們的實(shí)驗(yàn)導(dǎo)致了解決方案：

實(shí)驗(yàn) 1：解決性能問題

第一個(gè)實(shí)驗(yàn)的目的是提高性能。我們的工程師想出了一個(gè)提高性能的解決方案。我們的系統(tǒng)可能會(huì)出現(xiàn)任何具有數(shù)十億種可能性的隨機(jī)圖像，我們必須確定該圖像是否與我們的數(shù)據(jù)庫匹配。因此，我們沒有進(jìn)行直接匹配，而是設(shè)計(jì)了一種兩部分的方法：簡(jiǎn)單匹配和深度匹配。

第 1 部分：簡(jiǎn)單匹配：

首先，系統(tǒng)將消除明顯的不匹配。這些是很容易被識(shí)別為不匹配的圖像。它們可以是我們數(shù)據(jù)庫中數(shù)千甚至數(shù)萬張圖像中的任何一張。這是通過非常粗略的級(jí)別掃描完成的，該掃描僅考慮 20 個(gè)特征，通過使用設(shè)備上的數(shù)據(jù)庫來確定正在掃描的圖像是否屬于我們感興趣的集合。

第 2 部分：深度匹配

在第 1 部分之后，我們只剩下很少有來自大型數(shù)據(jù)集（有趣的集合）的具有相似特征的圖像。我們的第二個(gè)匹配步驟是在這幾幅圖像上進(jìn)行的。僅對(duì)這些有趣的圖像進(jìn)行了深度匹配。為了找到匹配的圖像，這里匹配了所有 200 個(gè)特征。因此，我們減少了在每張圖像上執(zhí)行的特征匹配循環(huán)的數(shù)量。

每個(gè)特征都與訓(xùn)練圖像的每個(gè)特征相匹配。這將匹配循環(huán)從 40,000 (200×200) 降低到 400 (20×20)。我們將獲得一個(gè)最佳匹配圖像列表，以進(jìn)一步比較實(shí)際的 200 個(gè)特征。

我們對(duì)結(jié)果非常滿意。以前需要 2 秒才能匹配圖像的 300 張圖像的數(shù)據(jù)集現(xiàn)在只需要 200 毫秒。這種改進(jìn)的機(jī)制比原來的機(jī)制快 10 倍，延遲時(shí)人眼幾乎察覺不到。

實(shí)驗(yàn) 2：解決規(guī)模問題

為了擴(kuò)大系統(tǒng)規(guī)模，第 1 部分匹配在設(shè)備上完成，第 2 部分可以在云端完成——這樣，只有潛在匹配的圖像才會(huì)發(fā)送到云端。我們會(huì)將 20 個(gè)特征指紋匹配信息連同檢測(cè)到的其他圖像特征一起發(fā)送到云端。借助包含有趣圖像的大型數(shù)據(jù)庫，云可以擴(kuò)展。

這種方法允許我們?cè)谠O(shè)備上擁有一個(gè)大型數(shù)據(jù)庫（功能較少），以消除明顯的不匹配。內(nèi)存需求減少了，我們消除了由于系統(tǒng)資源限制導(dǎo)致的崩潰，這是商業(yè) SDK 的一個(gè)問題。由于真正的匹配是在云中完成的，我們能夠通過不使用云 CPU 循環(huán)來降低云計(jì)算成本來進(jìn)行擴(kuò)展，從而避免明顯的不匹配。

實(shí)驗(yàn) 3：提高準(zhǔn)確性

現(xiàn)在我們有了更好的性能結(jié)果，匹配過程的實(shí)際精度需要提高。如前所述，在現(xiàn)實(shí)世界中掃描圖片時(shí)，噪聲量非常大。

我們的第一種方法是使用 CANNY 邊緣檢測(cè)算法找到圖像的正方形或矩形邊緣，并裁剪掉其余數(shù)據(jù)，但結(jié)果并不可靠。我們觀察到兩個(gè)仍然很重要的問題。首先是圖像有時(shí)會(huì)包含作為整個(gè)圖像矩形一部分的標(biāo)題。第二個(gè)問題是圖像有時(shí)會(huì)在美學(xué)上以不同的形狀放置，如圓形或橢圓形。我們需要想出一個(gè)簡(jiǎn)單的解決方案。

最后，我們分析了 16 種灰度的圖像，并試圖找到僅偏向 2 到 3 種灰度的區(qū)域。這種方法準(zhǔn)確地找到了圖像外部區(qū)域的文本區(qū)域。找到這些部分后，模糊它們會(huì)使它們?cè)诟蓴_識(shí)別機(jī)制時(shí)處于休眠狀態(tài)。

實(shí)驗(yàn) 4：為移動(dòng)設(shè)備實(shí)現(xiàn)原生 SDK

我們迅速提高了特征檢測(cè)和匹配系統(tǒng)識(shí)別圖像的準(zhǔn)確性和效率。最后一步是實(shí)現(xiàn)一個(gè)可以在 iOS 和 Android 設(shè)備上運(yùn)行的 SDK，就像我們?cè)谠?SDK 中實(shí)現(xiàn)它們一樣。對(duì)我們來說，Android 和 iOS都支持在其原生 SDK 中使用 C 庫。因此，使用 C 語言編寫了一個(gè)圖像識(shí)別庫，并使用相同的代碼庫生成了兩個(gè) SDK。

每個(gè)移動(dòng)設(shè)備都有不同的可用資源。高端移動(dòng)設(shè)備具有多個(gè)內(nèi)核以同時(shí)執(zhí)行多個(gè)任務(wù)。我們創(chuàng)建了一個(gè)具有可配置線程數(shù)的多線程庫。該庫將根據(jù)移動(dòng)設(shè)備的最佳數(shù)量在運(yùn)行時(shí)自動(dòng)配置線程數(shù)。

結(jié)論

總而言之，我們通過提高機(jī)器視覺的準(zhǔn)確性和效率開發(fā)了一個(gè)大規(guī)模的圖像識(shí)別應(yīng)用程序（用于包括增強(qiáng)現(xiàn)實(shí)在內(nèi)的多個(gè)領(lǐng)域）：特征檢測(cè)和匹配。現(xiàn)有的解決方案速度很慢，我們的用例產(chǎn)生的噪音大大降低了準(zhǔn)確性。我們希望在眨眼之間獲得準(zhǔn)確的匹配結(jié)果。

因此，我們進(jìn)行了一些測(cè)試以提高該機(jī)制的性能和準(zhǔn)確性。這將特征匹配循環(huán)的數(shù)量減少了 90%，從而使匹配速度提高了 10 倍。一旦我們獲得了我們想要的性能，我們就需要通過減少圖像中文本周圍的噪音來提高準(zhǔn)確性。在分析 16 種不同灰度的圖像后，我們能夠通過模糊文本來實(shí)現(xiàn)這一點(diǎn)。最后，所有的東西都被編譯成可以在 iOS 和 Android 上使用的 C 語言庫。