文 / 劉智美
首先介紹一下，我們公司是摩象科技，一個技術驅動的小米生態鏈公司，從我們的產品能看出來我們公司是一家基於視覺智慧的消費電子生產和服務廠商。今天要跟大家分享的是“雲臺相機”的研發故事。
我們今天的話題大概從三個方面開始給大家分享。首先，我們是怎麼會想到要做這個產品；其次，我們在研發的過程當中遇到了什麼問題，是怎麼解決的；以及未來我們對這個產品，和這個領域有哪些可行路徑的思考。
1
初 心
我們的初心其實很簡單，作為一個普通人，我們通常對於拍攝和製作影片是沒有什麼感覺和方法的。但我們看到很多導演或者網路上的UP主拍的影片非常好看，甚至抖音上很多業餘的博主拍的影片也很好看；那作為一個普通人，我們要怎麼拍、怎麼做出一個好看的影片？這就是我們最初的出發點。
於是，我們一群理工男分解出了影片三要素：指令碼、拍攝和剪輯。
指令碼就是通常講的創意，大部分人對創意是沒有概念的；不過我們從目的出發，會發現普通人拍影片或者做影片的目的通常只有兩個：一是要記錄，二是要分享。記錄是為了把生活裡的美好時光記錄起來，將來回憶看的，這種其實不需要創意；短影片火起來之後，大家更願意把自己的生活一點點分享出去，很多時候也不那麼講究創意了；特別是在抖音火起來之後，有了拍同款功能，就更不需要費腦子創意了，人家怎麼拍的我就跟著怎麼拍就行了。
後來我們總結後，發現創意反倒不是大問題，拍攝和剪輯才是真正的問題。那在拍攝方面，專業人士就會有各種專業的拍攝工具；而普通人通常只有手機，但手機有很多問題，比如不防抖、畫素不夠等等問題，導致素材質量不夠好。最後，最大的問題其實還是剪輯，剪輯的首要問題就是面對海量素材的選片，然後就是後續的調色、濾鏡、轉場、字幕，音樂等等，對普通人來說這個實在是太難了。我們就希望有一套邏輯，有一套公式或者一套方法能夠解決它。
於是我們立了幾個flag：
解析度與幀率
FOV120
FOV就是視場角，也就是我們大家通常認知的廣角、大廣角、超大廣角這種概念。我們普通的手機拍出來的視場角一般都是80~90度之間。一般超過90度我們就可以叫廣角，或大廣角了，我們希望可以做到FOV120。
防抖
抖其實有兩種表現，一種表現是原因，因為抖導致畫面是糊的；一種表現是結果，也就是畫面在晃動。我們希望我們的產品能防抖，讓普通人拍出來的畫面不抖，普通人拍出來的畫面也不糊。它是清晰的畫面，同時它是穩定的畫面。
便攜
便攜的考慮是一定要輕量，小巧。上圖中這個裝置，差不多就是我們要做的——一個小巧的穩定平臺+單反。
接下來，我們又立了幾個flag：
自動跟蹤
我們拿手機給家人、給朋友，或者是給孩子拍照片的時候，我們通常都是需要擺拍，是因為在實際拍攝的時候，人容易跑出畫面，或者鏡頭還沒調整好就拍了，導致我們錯過很多精彩的瞬間，這也是我們經常使用快門的原因之一。所以我們希望有能夠自動跟蹤的功能。
智慧剪輯
一個10分鐘的影片，我可能只要其中1分鐘就夠了，然後把其他的9分鐘剪掉，這叫剪輯。而剪的過程當中，如果10分鐘裡面有兩段想要的，分別在中間不同的位置，那麼我們就需要把這兩段它剪出來重新拼接成一個新影片。這就跟我們人腦處理資訊是一樣的，我們很多時候回憶過往的美好畫面時，我們往往也只能回憶一些片段，而不是全部。我們在想怎麼能去還原這個東西，或者說模仿這種行為，讓我們把更值得紀念的東西留下來。我們希望把剪輯變成一個自動化的過程。
2
上 下 求 索
作為技術驅動型的創業團隊，我們從去年就開始探索。
選型
選型不是說我們選某個軟體，也不是選某個什麼技術框架，而是讓我們去選晶片。
我們需要用到比較好的影象處理能力，希望它有4k和AI的能力，然後我們還希望它能有比較好的計算效能。我們選型的時候看了很多國內外的晶片，像國外的高通、TI還有安霸，國內的海思和君正。我們選型的時候有兩個主要原因，一個是我們很熟悉海思，另外海思的價效比很高，最終我們在海思的晶片裡面挑了一款叫3519A的晶片。
3519A有兩個ARM Cortex的核，以及神經網路計算單元NPU（他們叫NNIE），還會有個DSP，有2G的記憶體支援，這個配置肯定是夠我們用了。同時，這款晶片還有一個很厲害的ISP（影象處理子系統），能夠支援H.264和H.265的硬編/解碼，非常棒。
方案
定好晶片之後，我們要來做方案了。
方案是指我們選定某個晶片之後，晶片得跑在什麼樣的板子上，板子上得有些什麼元器件、什麼樣的攝像頭、什麼樣的雲臺，使用什麼樣的匯流排、結構等等。
海思也給了我們推薦方案，3519A的說明書上就明確的告訴我們，可以做運動相機，也可以做IP Camera，我們選擇了用IP Camera的方案進行改造。最終我們的板子就長這樣，成品之後就相當於iPhone7的一半大小，這就是我們微型化的結果，這就滿足了我們前面提到的便攜的要求。
上圖是系統的軟體結構，這個跟前面講的硬體結構其實能對應上，兩塊主記憶體，一個DSP，一個NPU和兩個Core，然後上面是一個雲臺的控制器，邊上是一個索尼的攝像頭Sensor，再加上螢幕和觸控式螢幕，永珍鍵、SD卡、以及連手機預覽的USB等等。
最開始的時候我們只在CPU上跑一個Linux系統，然後我們發現一些問題，比如我們從Sensor拿資料進來之後，前期要做畸變校正，然後還要到這邊來做AI處理，CPU佔用非常嚴重。最開始單系統在常規執行的時候，CPU基本就是80%以上的負荷。
後來海思的人說，我們在說明書裡面專門有DSP來做增強式的影象處理的，你們要用起來。後來我們就把Linux拆成兩個系統，每個Core上跑一個系統。後來發現雲臺需要獨立系統，DSP也需要獨立，再後來就跑成了現在這個樣子。現在的架構裡面同時跑了4個系統，還不算MCU，複雜度非常高。我們要切分一下看的話，會發現右邊主要做基礎影象處理，左邊做智慧影象處理。
當然，我們把系統分開，還有一個原因是我們希望把它變得更快。原來跑Linux的時候開機速度非常慢，Linux啟動要做很多初始化，開機通常要8~10秒鐘。但LiteOS其實是一個RTOS，是一個實時作業系統，它的開機非常快。按我們原來做門鈴和貓眼產品的經驗，RTOS系統開機300毫秒以內就起來了，使用者基本沒有感知。用它來做右邊的基礎影象處理的話有一個很大的優勢，一開機就能看到畫面，因為Sensor是直接往這邊輸出的。
廣角
我們剛才講了正常的Camera，也就攝像機的視場角有80~90度。我們人眼其實也差不多，有效的視場角大概90度左右。我們flag立的是FOV120，最終選型選的索尼的MX378，這款攝像頭模組是早幾年的主流機的攝像頭模組，標稱是120度的視場角。這兩年的攝像頭模組開始是MX586，MX686，我記得最新的蘋果12是MX686。還有小米的主流機旗艦機和華為的旗艦機基本上都是MX686。MX686有個好處是他們的視場角會更大，但不能盲目選大，因為實際上標稱跟我們實際拍出來的視場角還是有差異的。標稱116，標稱120的攝像頭，實際拍出來的也差不多80~90度的視場角。
這個涉及到我們的成像原理，攝像頭通常是有塊感光板，在鏡頭的最底下，倒數第二層第三層的樣子，有一塊濾光板，一塊感光板，後面是感光元器件，最後才是成像系統。在感光板上，感知到的最大的解析度多大，就是他的最大的解析度。我們選擇這一款模組的最大解析度是4000×3000的，也就是4k，而FOV就是指當輸出4k影象的時候，才有120度的視場角。但實際的成像是從4k畫面裡切出來的，比如我們要1080p的影象，它是從4000×3000的4k的畫質中間切一塊出來；如果你要2k的話，也是一樣道理，它從中間去切一塊；所以，從一個標稱FOV120，4k的畫面中切出來一塊，那切下來的這塊影象的視場角就相應變小了。如果要4k怎麼辦？通常很難，因為涉及到畸變的問題，下面會講到。
畸變
攝像頭成像的時候，是把光從鏡頭外面打到感光片上，光線穿過鏡頭打到感光片上的時候，其實會發生扭曲，中間的光線扭曲很小，四邊的光線扭曲會比較大，導致在我們成像器上出來的畫面是變形的，變成一個不規則的矩形，這就是畸變。畸變通常又有兩種，要麼是桶形的，要麼就枕形的。桶形的就是它四邊鼓出來，好像一個人吃胖了，肚子大了。枕形的就是它的4個角凸出來，好像蜘蛛網一樣。
拍攝結果（如圖）其實是個畸形。這是我們攝像頭最原始拍出來的圖。如果我們不拍這種方格格圖的話，其實也不太看的出來。
如果我們拍1080p，這中間的部分肯定不會有問題。但如果我們拍4k，明顯這個畫面就沒法看了。如果再細心一點，其實會發現我們這個畸變更厲害，它不是枕形的，也不是桶形的，它是枕形加桶型的。
在相機行業裡面，畸變是非常常見的一個情況，所以畸變函式老早就有了，如果是比較單純的畸變，用一個畸變函式校正一下，立馬就可以得到一張正常的影象。
但我們碰到的畸變不是一個簡單的枕形或桶型，而是一個複合型的，所以我們自己做了一個自研的演算法來解決這個問題。畸變校正的原理其實就是一個座標系轉換，然後在進行座標系轉換的時候，透過差值演算法把對應畫素上的顏色值算出來；也就是說你只要把它座標值算對了，然後把它的顏色值找到了，往那個地方一填，這個畸變也就校正了。
再說到數學上，它其實一個是個矩陣計算。為了解決這個問題，我們最終找模組廠商要了一個他們的座標系轉換的引數。這個引數其實就是告訴我們，光從真實物理世界，打到我們成像器上的時候，那個位置會是什麼座標。它會告訴我們這兩個位置，但不會告訴我們這兩個位置的對應關係。所以我們要做的事情是先把這兩個位置之間的變換公式提出來，也就是把轉換矩陣給提出來。這樣，當我們拍到了一張畸變的影象，用這個轉換矩陣和畸變的影象進行一次矩陣運算，最終得到的就是一個真實的影象了。
4k 60幀
拿到這個轉換矩陣之後，我們在PC上跑了一個數據，大概100毫秒能轉換一張4k的圖形，100毫秒也就意味著幀率只有10FPS，這放在影片領域裡，10FPS的影片誰愛看呢？
發現計算效能根本達不到之後，我們就想到了DSP，但DSP的片上記憶體只有256KB，要做一張4k的圖片的轉換，根本就跑不起來。後來我們想了一個辦法，把矩陣拆成了n個很小的100×100的小矩陣。做畸變校正的時候，把我們的影象根據參考矩陣的大小切成一小塊一小塊，透過DSP進行矩陣計算。DSP一片片的從主記憶體搬到片上記憶體進行運算之後，再搬回去主記憶體，再切第二塊，再去運算之後再搬回去，就這麼迴圈。結果是我們處理一張4k圖片的時間是大概耗時12毫秒。簡單計算一下，60幀綽綽有餘了，這就是我們4k 60幀的由來。
自動跟蹤
我們認為拍影片的時候，我們更關注裡面的人物，會希望TA總是在影片中的C位。
比如說學校運動會，我去看我小孩參加運動會的時候，我會希望鏡頭跟著TA走的，而我什麼也不用幹。TA圍著操場跑的時候，這個攝像頭也會跟著TA轉動，而我不用動。這就是自動跟蹤，自動跟蹤有個基本前提，就是我們要先把目標識別出來，這就要用到AI演算法了。我們最終選用了SSD模型，這是號稱物體分類最快的兩個模型之一，另一個是YOLO。
我們看一下上圖會發現這是一個比較複雜的一個計算，我們其實是要提出來每一幀裡我們所關注的物體。比如上圖影片裡有個小女生，她在影片裡運動的時候，實際上每一幀她的位置我們都會計算出來。
前面提到3519A上有個NPU，是海思平臺給我們提供的一個AI晶片，裡面跑了一些基本的網路模型，我們把SSD演算法移植過去，最終就能把每一幀裡面我們關心的物體，如：人、小貓、小狗和小孩都找出來，並標定TA們的位置。
再之後我們的主Core會根據當前影象和上一張影象計算出目標位移偏移量，同時會把這結果透過我們雲臺控制器，告訴攝像頭，你要朝哪個方向走，你的加速度和角速度是多少等等；雲臺控制器就會驅動馬達轉向，並且是符合我們速度要求的轉向，跟上我們的目標，確保目標總是C位。這樣一來，如果拍攝的時候出現了一些精彩的瞬間，我們就都能抓住了。通常單反是做不到這一點的，手機也做不到。
智慧剪輯
智慧剪輯最大的問題是我要知道我拍到了什麼。這個可能是現在做影片AI演算法，做CV的很多人都想做的一件事情；我們也在嘗試認知相機拍到的東西。
我們選用了PeleeNet模型來做分類，也是號稱最快的實時物體分類演算法。這個演算法能認識1000+種物體，它的作用其實要把每一幀裡面的出現的它認識的物體全標下來。這會產生一堆的幀資料，這些資料我們會把它存起來，也就是透過這些物體的標籤，對影片做了一個索引。
把影片標籤化之後，下一步要做的就是剪輯，前面我們做好了每一幀的索引，那麼在我去真正要剪輯他的時候，需要有一個聚類的過程。聚類的過程其實就是把很多瑣碎的細的標籤往一個場景上聚合。
最終會得出一系列的場景標籤，App會拿這些標籤去雲端詢問一下：有沒有符合這些場景的模板？如果有，你找幾個給我，我來剪一剪試一下。
雲端的目標是我們跟一些抖音達人和B站UP主合作，他們會幫我們做一些主題模板，比如：親子、美食、聚餐、生日會和旅行的模板，或者海邊、草原等的模板。他們通常會用他們的經驗去做，比如在一個青春校園的模板裡面，用什麼樣的音樂更貼切，用什麼樣的調色更有質感，加上什麼樣的轉場會比較打動人等等。我們會把這個模板放到雲端，給它加上一個主題，比如青春校園類，當App來查詢模板時，用App聚類出來的標籤跟雲端的主題標籤進行匹配就行了。
在實際剪輯的時候，App還要透過場景標籤反向查詢，把標籤對應的那些片段給抽出來，最終再去合成，這樣就能得到一個我們認為剪出來還不錯的片子。
3
未來的思考
在今天之前，我們產品其實已經上市了有半年了。經過了一些使用者的驗證，包括很多使用者的反饋，我們也做了更進一步的思考。
更高畫素
因為早段時間雷總說要做一億畫素手機。我們在想是不是也可以做更高的畫素。
幀率的問題
其實我們120幀已經能做那些慢動作的拍攝，但對一些更極限的玩家來講，他們可能希望有更高的幀率，比如240幀。
大底和長焦的問題
大底的問題，比如我們拍星空，沒有大底就拍不出來，因為他要足夠的進光量。
續航
我們現在能拍兩小時。我們覺得如果作為旅行拍攝，或者說作為一個短片的素材的拍攝，可能兩小時不夠，還要更長。
物體跟蹤問題
語義生成
我們也知道最近其實很多Paper都在講語義生成，諸如AI寫詩、AI寫文章等。現在也有比較多的PR出來，大家也看到了，但實際應用可能還有差距。包括早段時間，微軟還PR了一個AI畫畫的產品。我們其實是希望未來在這一塊，我們能夠讓AI去創作，去剪輯短影片，當然這裡面會有更多更細節的探討。