國立台灣科技大學資訊工程系
九十八學年度第一學期專題研究
總報告
Using Cloud Computing In Image Retriever
研究組員
楊偉銘 A9715031 古鴻勳 A9715004
指導教授： 鮑興國 博士
中 華 民 國 99 年 1 月 21 日
第一章、緒論
前言
現今，地球村的時代儼然來臨，爆炸般的資訊以文字或影音的形態在網路 上四處流竄充斥，藉此有越來越多的媒體廠商看準這樣的資訊商機，紛紛投入大 量的預算開 發行動數位多媒體裝置，讓人們可以越來越方便的存取網路上的資 源。其中最廣為現在人所使用的，即是結合傳統手機通訊功能，無線通訊功能，
PDA 個人資料管理功能，甚至是數位相機功能的智慧型行動手機作為存取的媒 介。
如何讓這些看似雜亂無章的龐大資料，藉著熱門的 Data Mining 或是 Machine Learning 技術焠鍊出有用的資訊，漸漸受到世人們重視，越來越多的 網路使用者不只是想得到所需的資訊，甚至進一步的希望能取的與其相關連的其 他資訊，而且最好是能不分資訊的形態，找出越多有用的資訊越好。為了這樣的 目的，搜尋引擎因此得以誕生。凡是對於網路進行存取的使用者，都可能正扮演 著搜集或是散佈資訊的角色，其中的資訊形態可能是文字，圖像或是影音，對於 搜尋引擎而言，皆得透過一個或是數個帶有意義的片斷文字資料作為輸入，隨後 才能得到上述的資訊作為輸出，這 樣的方式似乎普遍的被視為常態的做法。然 而是否存在一種可能，同樣的把文字以外的圖像或是影音資料作為輸入，然後得 到其他資訊呢？目前這樣的情節似乎只能 在電影當中才看得到。
也許這樣的想法是個開端，將行動數位多媒體所能提供的資料作為素材，
建置一以圖像或影音作為輸入的搜尋引擎，嘗試能因此取得更多不一樣的有用資 訊。試想像 一下，當我們拿著智慧型行動手機，隨手錄一段聲音，可能是某個 演說，某段音樂，甚至是某種怪聲音，接著把它們當作輸入餵給專門進行聲音搜 尋的搜尋引擎，然 後得到以文字資訊輸出的搜尋結果，告訴你這是哪一個人正
在演講的聲音，這個聲音片斷出自哪首曲子裡面，或是這是哪一種你不曾聽過的 樂器所發出的特殊聲響。 同樣的想像之於影像，是不是也能有個搜尋引擎是以 影像做為入輸的，在當我們把某個人物，街景或是奇怪的圖案輸入之後，同樣的 也可以得到有意思的資訊作為結 果。若那一天真的來臨了，我們透過搜尋引擎 所能得到的就不僅僅是資訊而已，還能得到更多的聯想以及創意。
本專題試著以這樣的概念作為主軸與方向，嘗試建立一專門處理圖像的搜 尋引擎，以圖像資料替代文字資料作為搜尋引擎的輸入，試著得到文字與影像資 料作為搜尋 結果的輸出，期許能讓搜尋不再僅限於文字資料的關聯，還可以像 人類大腦對於影像進行聯想一般，可以天馬行空的得到更多有用而且有意思的資 訊。
動機
是否有過下列經驗：在整理過去的圖像檔案時，想不起來這是當時在哪裡 的留影？或是到了某個陌生地點，想得知自身所在位置，卻苦無收不到人造衛星 所發出的全球定 位系統 (GPS) 的訊號？雖然現今的數位相機或是智慧型手機 可以在拍攝影像的同時，將 GPS 的資訊以 EXIF (Exchangeable Image File Format) 格式寫入影像檔案之中，藉此得以得知拍攝該影像的地點，但是這看似 完美的方案卻有著美中不足的地方。
全球定位系統有著相當高的定位精確度，誤差可以僅在一公尺之內，但是 面對都會型態的城市有著高樓大廈林立的現象，從外太空輻射下來的電磁波容易 因此造成遮蔽或是折射等影響，使得定位精確度降低，甚至無法接受到訊號，因 此依靠 GPS 進行程式導航有時會造成困擾。電信業者所提供的基地台定位可以 作為替代方案，是以目前手機利用基地台間彼此涵蓋範圍的重疊上，利用發送電
磁波信號到鄰近的 基地台後，計算各基地台接收後的反應時間及角度，利用三 角定位的方式標定目前所在的位置達 到定位的效果。也因基地台定位只需要能 夠接收到手機訊號的地方便能夠達到定位效果，可以用來解決在上述無法接收到 衛星訊號環境下的另一種定位方式，不過誤 差會因基地台的涵蓋密度而有所影 響，且誤差也比 GPS 還要來的大。然而反觀數位相機就無法利用這樣的備案，
若真的無法在圖像上取得 GPS 資訊，勢必就得從圖像本身上找出能定位的蛛絲 馬跡。
反過來換句話說，如果能夠解決數位相機在不依靠 GPS 資訊來進行定 位，則智慧型手機必定可以依此當作第三定位方案，讓定位的方法更加完備。但 是圖像本身如何與定位扯上關係？這乍看之下八竿子打不著的問題，卻 是 Data Mining 或是 Machine Learning 最擅長解決的，利用 Supervised 或是
Unsepervised 的方法都可以達到我們想要的目的，可是卻會伴隨另一個棘手的 問題發生，如何消化龐大的運算過程。在實用方面來說，即時的反應將會是第一 要件，整體的運算時 間決定了整個計畫成敗的關鍵，是否有好方法解決這個問 題呢？也許是雲端運算。
雲端運算的發展
在遇到需要執行處理龐大 資料的程式時，往往需要花費許多時間來等待執 行結果，這樣的情況普遍的發生在單一機器上。常用的解決方法有兩種，一是提 升硬體設備，例如增加處理器核心數 (所執行的程式需要使用 multi-thread 技 巧) 來增加單位時間內的 CPU 處理時間，另一則是使用叢集電腦強大的運算能力 解決，這些方法都是利用平行處理的技巧，使得同一時間內能同時處理多個行程 或是執行緒，達到縮短整體運算的時間。但是所謂的處理龐大資料這件事，往往
意味著需要大量的對次級儲存裝置進行存取，所以就算增加大量 CPU 處理時間來 計算這些資料，在次級儲存裝置的 I/O 頻寬上很可能遇到瓶頸，而叢集電腦索 價不婓，並非所有單位或是研究機構負擔的起的。Hadoop 為一自由軟體，這套 Apache 軟體基金會旗下之一的軟體專案計畫，可以在透過簡易的安裝與設定有 效的搭建出一雲端運算的平台，並且讓相異之硬體機器平台與系統能以 Java 程 式語言為基礎，取得硬體抽象化之特性，使軟體與硬體方面能有高度的擴充彈 性，藉此取得統一平台進行平行運算。
2008 年，Google 宣佈在台灣啟動「雲端運算學術計畫」，將這種技術推 廣到校園。雲端運算計畫的產生，是希望能夠降低分散式運算成本，用簡單的個 人 電腦搭配 Open Source 軟體，則可藉此發展各種大規模運算為基礎的研究計 畫。目前在預算與效能上做出最佳的折衷方案莫屬雲端運算。
本專題影像辨識的部份，便是利用雲端運算解決運算量過大而導致比對時 間過長的問題，接著找出比對後的最佳結果之影像，取得其圖像上 EXIF 的經緯 度資訊實現定位的效果。
專題架構
本專題第二章先介紹所使用的影像辨識方法 SIFT；第三章介紹雲端運算整 體架構；第四章為整個專題的系統架構，及如何利用雲端運算實現新的影像比對 方法；第五章為實驗之結果，可以發現有著與預期相符的測試結果；最後第六章 為結論。
第二章、影像特徵點擷取與辨識
我們用 SIFT(Sclae Invariant Feature Transform)演算法從景物影像中擷 取特徵點。利用 SIFT 在不同角度的物件影像，依然能夠找出正確比對結果的特 性，來找出資料庫中最符合的影像。
SIFT 演算法是一種先粗略、後詳細的方法。先找出可能為特徵點的對象，
再刪減一些不好的候選特徵點，針對篩選過後的的特徵點才做較為複雜的運算。
以下主要分為四個步驟：
1. 尺度空間的極值偵測(Scale-space extrema detection) 2. 特徵點定位(keypoint localization)
3. 方向的分配(orientation assignment) 4. 特徵點描述(keypoint descriptor) 尺度空間的極值偵測
此步驟針對影像所有的尺度和區域做搜尋，找出具有成為特徵點潛質的點。
先將圖片以高斯 Mask 做處理
) , ( ) , , ( )
, ,
(x y G x y I x y
L σ = σ ∗
其中 L 為處理後的影像；I 為輸入圖片；*為旋積分(convolution)。
2 2 2 )/2 (
2 2
) 1 , ,
( σ
σ πσ e x y y
x
G = − +
調整變異數σ2以產生不同模糊程度的輸出影像L，代表不同距離的視點、看 到不同的細節。然後將相鄰變異數的兩張圖片相減，產生Difference of Gaussian(DOG)圖，如圖 1。
) , ( )) , , ( ) , , ( ( ) , ,
(x y G x y k G x y I x y
D σ = σ − σ ∗
) , , ( ) , ,
(x y kσ L x y σ
L −
=
圖 1
其中k = 21/s，S為一個octave中有幾張DOG圖。一個octave裡標準差會成長 兩倍，且下一個octave尺寸會縮減一半。
圖 2
在 DOG 圖中，若有一像素大於或小於周圍八個像素，且同時也大於或小於鄰 近尺度相同位置的九個像素，則此點就當作特徵點候選人，如圖 2。
特徵點定位
此步驟對上一個步驟選出來的特徵點做篩選，刪掉一些較不具特徵的點。首 先用泰勒展開式逼近上一步的極值
其中 。將 D(x)對 x 做一次微分後令其為 0，求極值時的 x 值。
若 x 大於一個門檻值(Lowe 的論文中為 0.5)則表示極值非常靠近另一個特徵 點，此時我們用另一個特徵點取代這個點。否則就把 x 加到該特徵點中。
)T
, , σ Χ =(x y
將剛剛求得的 x 代入 D(x)，若小於一個門檻值(Lowe 的論文中為 0.03)表示 對比太低，將它丟棄掉。
方向的分配
此步驟由特徵點周圍的像素差計算剃度方向，給定特徵點一個或多個角度。
m 為剃度大小，θ為角度。
特徵點描述
最後從特徵點周圍找出能夠代表特徵點的描述子(descriptor)。用上一個步 驟的方法計算特徵點周圍區域像素的剃度向量，如圖 3 左
圖 3
圖 3 是從特徵點周圍 8x8 取剃度，然後依方向加權累加後轉成圖 3 右邊的 2x2 小區域描述子，每個區域有 8 個方向。而我們是用特徵點附近 16x16 轉成 4x4 的子區域，共有 4x4x8 = 128 維的向量。
我們用這 128 維向量與其他特徵點取歐幾里得距離(Euclidean distance) 來實現比對，距離越小代表越接近，越有可能吻合。
第三章、雲端運算
Hadoop 概略架構圖如下：
圖中的 Compute Cluster 由許多節點機器所組成，這些節點機器可以作為 Datanode 或是 TaskTracker，甚至可以同時具備這兩種身分。圖中左邊的 Data 與右邊的 Results 接存放於 HDFS 之中，Compute Cluster 則是細部的描述 Datablock 與 Map/Reduce 之間的關係。
Map/Reduce 與 HDFS 關係示意圖：
HDFS 架構圖：
Datanode 為 HDFS 提供次級儲存空間，越多的 Datanode 加入 HDFS 意味 著整體次級儲存空間增加，Datanode 最小的儲存單位為 Datablock，預設為 64MB，換句話說，其實真正存放在 HDFS 內的資料是由許多 Datablock 所組成。
為了管理這些 Datanode 內的 Datablock，必須額外找一節點機器作為
Namenode，紀錄所有 Datablock 之於 Datanode 內的所在位置，因為 Datablock 可能存在於任意一個或多個 datanode 內，所以在每次存取 HDFS 的請求都必須 先詢問 Namenode 所需的資料在哪個 Datanode 中的哪個 Datablock，再進行資 料搬移。某一節點電腦為 Datanode，在經過 HDFS 的請求之後得知所需的 Datablock 已存在自身 Datanode 之中，則此時不須要進行資料搬移，且可視為 具有緩衝效果的存取。
然 而 Namenode 是如此的重要，若其遭到損毀，可想而知 HDFS 上所有 Datanode 之於 Datablock 的資料都將遺失，為了以防萬一，可以額外的找一節 點機器作為 Secondary Namenode，週期性地對 Namenode 進行備分，降低 Namenode 在意外損毀時所造成的傷害。設置 Replication 的目數可以告知 HDFS 對於每個 Datablock 最多可以有幾個副本存在於其他 Datanode 之中。
MapReduce 架構圖：
TaskTracker 為 Hadoop 最小運算單位，可以執行 Map 或是 Reduce 功 能，並由一節點機器來擔任。JobTracker 統籌所有 TaskTracker 的工作分派，
當開始進行運算時，JobTracker 會將自 HDFS 內所給定的輸入資料拆成數等 分，並同時指派給同樣數目的 TaskTracker 執行 Map 來進行 key-value 的配 對。同樣的，JobTracker 也會在這個時候讓一個或多個 TaskTracker 執行 Reduce，用以接收 Map 所傳出的初步結果並將其做資料彙整的動作，最後傳給 JobTracker 做輸出結果的整合。
第四章、系統架構
本系統為建立在手機上的應用程式，實現於 Google 的手持作業系統 Android 下的手機裝置。利用手機的照相功能及網路功能，實現隨時隨地都能定位導航的 功能。
先用手機上的數位相機取得所在位置的影像資訊，透過 TCP/IP 通訊協定傳 送到雲端網路。雲端以分散式處理的方式達成影像辨識，以增加影像處理、比對 效能，提升導航的效率，進而取得最有可能符合影像中所在的位置。
系統架構圖
雲端部份實作
首先，將我們所感興趣的眾多影像各別的給定一獨立 idenity number (目 前使用 UUID) 作為識別之用，並將這些影像上各別的特徵點，與 identity number 資訊先行標定彼此間的關連之後，在 HDFS 上存放成一關連檔案。當影 像輸入由手機端至雲端後利用 SIFT++
(http://www.vlfeat.org/~vedaldi/code/siftpp.html) 所提供的工具 sift，
將所收到的影像進行特徵點的擷取，隨即將所有產生出的特徵點當作被比較的對 像，並將 HDFS 上所存放的關連檔案作為 Maper 的輸入進行分散式比對，把每 個被比對的特徵點找到關連檔案中最相近的特徵點，最後由 Reducer 收集比較 的結果，找出擁有該特徵點的影像並進行次數統計。如此下來，可以得到哪些影 像被尋訪的次數較高，意味著該影像與待測影像之間的相似度越高，再將所找出 的最佳影像送回手機端，進行顯示。
第五章、實驗結果
我們從規劃好的路線上取得影像資訊以建立資料庫，如下圖。共 126 張圖 片，每張照片解析度為 624x416，並在路徑上照攝測試圖片。
測試影像以及從資料庫比對的最佳結果：
測試影像 最佳結果
第 1 組
第 2 組
第 3 組
測試影像特徵數 最佳結果特徵數 比對匹配數 匹配百分比 第 1 組 3955 4204 87 2.2%
第 2 組 4575 4962 30 0.66%
第 3 組 4418 4841 188 4.26%
我們發現成功匹配的特徵點非常稀少，不相干影像的匹配成功數幾乎都為 0，真正非常相近位置的成功數佔的比例也非常少。因此只要資料庫所含影像夠 密集，取樣距離縮小至一定有辦法成功匹配時，再比較匹配成功率便可找出最符 合的影像。
影像匹配正確率
圖中 45 個匹配，只有 1 個明顯的錯誤匹配在位置 a；位置 b 還有許多上圖的點 對到下圖的其中一點。這是因為這些窗戶是具有規律性的重複，而使得特徵非常 相似。
定位準確度
我們將最佳的比對結果，與取樣測試時的 GPS 資訊做比較：
藍色的點是我們的結果，紅色是測試照片上的 GPS 位置。第 2 組和第 3 組因
拍攝距離差異不大，約莫 3 公尺，角度變化也較小，所以位置十分吻合。第 1 組距離差異較大，但誤差的原因為 GPS 本身的誤差。我們產生的結果也是將影像 比對後認為最好的照片，裡面的 GPS 資訊當做結果，所以影響到我們的結果。而 第 1 組的測試圖片 GPS 位置本身也有誤差，造成第一組兩種方式都離真實位置有 明顯差距。但第 1 組 GPS 的差距較我們的結果小。
第六章、結論
透過利用影像比對方式為基礎，實現定位導航的功能，其結果顯示當雲端上 影像的資料標示越正確時，所能得到的效果就會越好。影像的取樣距離的間距亦 是如此，兩次取樣之間的距離越短，定位效果也就越好，但相對，較短的取樣距 離會造成雲端上的影像數量劇增，最後在比對尋找結果所花費的時間相對就越 長。除此之外，本專題有著以下幾樣待解決的問題：
‧ 定位結果依然會受到原先影像上 GPS 精準度的影響。
‧ 未將影像進行特徵點過濾，除了可以降低比對的錯誤率，還可以減 少運算的資料量。
未來展望
若將來能夠精進此專題，有幾個要點是較具有實作價值的。
‧ 利用影像座標、相片座標與空間座標之間的關係作進一步的幾何運 算，以期能增強定位效果，而非僅僅依賴 GPS 資訊。
‧ 利用空間幾何線條的關係過濾一些不符合的匹配點。
‧ 可以嘗試利用計算影像深度和圖片拼接建立環境 3D 模型，達到類 似 Google Street 的效果。
‧ 改進雲端上目前比對的架構，使其更有效率。
參考文獻
[1] Android. Developers http://developer.android.com/index.html
[2] hadoop. http://hadoop.apache.org/
[3] Andrea Vedaldi, SIFT++,
http://www.vlfeat.org/~vedaldi/index.html
[4] drewnoakes.com,
http://www.drewnoakes.com/code/exif/index.html
[5] David G. Lowe, "Distinctive image features from
scale-invariant keypoints," International Journal of Computer Vision, 60, 2 (2004), pp. 91-11
[6] Marius Muja and David G. Lowe, "Fast Approximate Nearest Neighbors with Automatic Algorithm Configuration", in
International Conference on Computer Vision Theory and Applications (VISAPP'09), 2009
[7] Nister,D. and Stewenius, H. (2006). "Scalable recognition with a vocabulary tree " In CVPR,pages 2161-2168
