利用iPhone捕捉360度汽車環景影像的問題

作者 : Jai Chaudry & Greg Surma

為了打造一款軟體開發套件(SDK),我們利用iPhone的強大功能來執行汽車的360度影像。即便擁有強大的iPhone處理器,在日常的開發工作上仍舊面對一些特定問題...

當今的iPhone智慧型手機功能已經變得相當強大了。為了打造一款軟體開發套件(SDK),我們可以利用iPhone的強大功能來執行汽車的360度影像,順利推出一款能夠擷取、分析、檢視並上傳這些影像資料的SDK。然而,即便擁有強大的iPhone處理器,在日常的開發工作上仍舊面對一些特定問題。

1:利用iPhone檢查車輛的損壞情形。(圖片來源:Fyusion)

這是一款具備豐富相機功能的SDK,因此我們能在內部建立自己的相機傳輸管道,並且擷取高解析度且完整互動的360度汽車影像,從而能夠藉由各種機器學習(machine learning;ML)功能加以增強。當然,使用相機仍然面對一連串既有的問題。

相機的開銷和過熱問題

我們所開發的SDK最近遇到了這樣的使用案例:為了讓相機能夠保持長時間的開啟狀態,使得手機變得過熱。特別是在炎熱的夏天,這個問題更加值得注意。

我們也利用蘋果(Apple)的MetalKit和AVFoundation API,但這些API通常讓GPU和CPU的負荷變得沉重。在擷取一段360度的環景視訊之後,接著利用電腦視覺和Core ML等工具,在所擷取的視訊媒體上執行內部處理。如果未能妥善地均衡處理,所有的這些舉動都會導致手機過熱。所以,我們想出了許多解決方案,以便將這個問題進行最佳化處理。

在iOS裝置上進行機器學習時,最重要的是利用神經引擎,這顯然是專為加速機器學習推論而設計的。其處理速度平均比GPU快十倍,且隨著效能的提升,你也能夠感受到較低的能耗。然而,為了能夠使用這項功能,我們只能使用其所支援的分層。

裝置上機器學習最具價值的應用之一是即時視覺化。為了達到流暢且即時的視覺化而不至於讓裝置過熱,下列是一些需要考慮的事項:

  1. 跳格(Skipping frames)—無需在每一格影像上都執行機器學習模式。通常在精確度和流暢度之間的最佳權衡是每秒25格(25fps)。
  2. 在讀取機器學習輸出時,利用直接的資料指標以取代下標陣列(subscripting array)。這兩種方法的時間差一開始似乎可被忽略,而當執行每格數千次之後,所耗費的時間累加起來就很可觀。例如,我們有一款App即利用指標補償法來解壓縮,需要耗時000000012秒;相形之下,利用陣列下標法耗時約0.00000076秒。這兩個數字看起來都非常小,甚至可以忽略,但是在累積一整天的差異後,它們對整個效能的影響至關重要。
  3. 儘可能利用足以完成任務的最小化網路。由於推論時間通常與網路的規模成比例,最好小心謹慎以避免利用大規模網路,以免為了流暢地進行即時運算而花費太多時間。
  4. 利用Metal套件進行可視化以取代UIKit由於我們致力於每秒至少產出25格影像,程式碼就必須盡可能地快速。採用Metal套件著色器(shader)的運算可視化比UIKit快了好幾十倍。因為UIKit是高階架構,主要用於多半處於靜態的介面和使用者介面(UI)元素。另一方面,Metal顧名思義,它相當接近硬體,能夠為高效能繪圖渲染提供所需的低階且低營運成本API。除此之外,為了呈現與UIKit的覆蓋層,我們首先需要運算UIImage;在多數情況下這是由一個相對慢速的CPU完成。另一方面,利用Metal套件,我們能夠在提供Metal著色器的同時計算許多畫素值,所有的這些運算都可在GPU上完成,因而能夠更快地渲染覆蓋層。
  5. 利用低階的C++和Objective-C++,以取代像Swift等高階程式語言。即使Swift在效能上已經追趕上來了,它仍然無法達到C++的水準。一般的經驗法則是越關注效能,就越需要接近硬體。
  6. 量化權重。儘管這並不會直接增加推論速度,但將會減少機器學習模式的記憶體佔用及其運算資源,而這將有利於一般App的效能。

上傳任務

上傳作業一開始看起來似乎微不足道,但它也存在固有的問題。以我們的案例來看,由於使用者通常會在停車場使用這一款App,這讓網路情況變得更嚴苛。我們還必須確定,即使這個App在背景執行或被OS暫停時,上傳作業還能夠持續進行。儘管Apple確實提供了特定API來執行這一任務,但它並不如你所想像的那麼簡單。

2:使用者可以透過手機來擷取車輛的3D影像,添加聲音或視覺標記,然後透過email、文字簡訊或傳訊App進行傳送。(圖片來源:Fyusion)

為了上傳資料(利用公司專用檔案格式‘.fyuse’),我們以往曾經使用一連串的多次呼叫(call)。這一開始可能是個還不錯的解決方案,直到開始出現一連串.fyuse的等候作業時,那可能就不再是個好辦法了。值得注意的是,我們必須支援系統後台的上傳作業,同時還要考慮到App的速率限制。你可以把一個限速器視為每次想要喚醒App時所增加的啟動時間。喚醒作業可能採用深層連結的URL、網路呼叫和推送通知等等任何方式。但是,一連串的多次呼叫可能累積並增加啟動所需的時間,以至於完全無法啟動。試想在一個等候作業中,有一百多秒的上傳動作佇列會是什麼狀況。

因此,我們決定將檔案內容壓縮成一個單一的大型檔案,以降低喚醒App所需的呼叫次數。同時,我們也決定利用預先指定的S3 URL進行上傳。這個作法唯一的缺點是如果上傳到98%的完成度時突然故障,就必須從0%重新上傳。為了解決此一問題,我們建議將足夠大的檔案分塊處理。

上述的傳檔途徑也伴隨著一些限制:

  • 在開始上傳之前,我們必須先確定所有的檔案已被寫入磁碟。換句話說,那會增加輸入/輸出(I/O)作業並因而增加CPU的使用率。
  • 利用Apple的背景URLSession API,很難針對這類傳檔途徑進行除錯。唯一的方法是檢查macOS控制台,看看是否有上傳作業在後台執行。

除錯問題

當我們在開發SDK時,重點在於其躼具備的能力,包括追蹤使用者如何使用該App、追查使用SDK時所產生的任何錯誤和警告記錄,以便能夠檢查系統崩潰等。

在此情況下,找到一個經驗證可行的第三方架構極具吸引力。很遺憾地,第三方架構傾向於被設計用來進行應用級的追蹤,如果將它嵌入在SDK中,利用單例模式(singleton pattern),很可能導致意外的衝突。所以,我們採用許多機制來協助追蹤系統崩潰;例如當有人利用我們的SDK擷取360度影像時,相應地列印其工作日誌(logs)。如果我們能在SDK的二位元檔案中找到崩潰所在位址,也就能夠利用Atos工具將崩潰事件加以符號化。

如前所述,當有人利用這款360影像SDK時,通常會印出重要的工作日誌。這些工作日誌記錄讓我們瞭解關鍵錯誤、警告,以及在除錯或處理系統崩潰時可能會用到的其他事件。我們也利用Apple所提供的OSLog架構,用於監看執行除錯的工作日誌和OSLog登入記錄,以便監測SDK中所存在的耗時程序。OSLog可以在Mac控制台上印出工作日誌,讓除錯工作變得容易。

本文作者:

Jai Chaudry,Fyusion iOS工程主管
Greg Surma,Fyusion資深軟體工程師

(參考原文:Problems faced when using iPhone to capture 360° car images,by Jai Chaudry& Greg Surma)

本文同步刊登於EDN Taiwan 2021年10月號雜誌

加入LINE@,最新消息一手掌握!

發表評論