Hi!请登陆

我在優酷OTT端做自動化制圖

2020-9-13 33 9/13

作者 |阿裡文娛高級前端開發工程師-罄天

責編|楊碧玉

頭圖 | CSDN下載自視覺中國

背景

圖片作為網頁中的重要組成元素,廣泛存在於各種站點中,有些站點中的圖片內容已經遠遠超過瞭其它網頁內容總和。如何高效的、快速的制作業務圖片就被廣泛的提出來。阿裡有很多自動化圖片生產平臺,如海棠,魯班等。

談到自動化制圖,主要有兩種模式:

一是自動化模式:依賴於服務化能力包裝,將核心制圖能力進行抽取,任何三方通過直接調用服務能力即可完成圖片的合成,此種模式完全自動化,無需任何人工幹預即可制作出符合指定條件的業務圖片;

二是半自動化模式:主要依賴於業務共性的提取與升華,將繁瑣的重復的業務流程通過統一的范式來解決,或多或少的需要人工幹預。人工幹預一方面需要人力投入,另一方面意味著可以發揮人的主觀創造性。成品圖除瞭滿足指定的共性外,也可以保證輸出個性,這種個性與共性並存的方式不失為一種好的折中。

OTT自動化制圖

1、OTT自動化制圖的起源

以前,優酷 OTT 側有自動化制圖的雛形,主要依據前端提供制圖的工具平臺,並將 OTT 主要合作廠商坑位圖配置信息進行固化,然後運營在工具平臺上做相應的坑位圖合成。此模式在一定程度上滿足瞭運營的合圖需求。

在2019年, OTT 側開始嘗試自動化制圖。深入自動化制圖的目的也很明顯,主要基於以下痛點:

內容源與成品沉淀

我們觀察到,阿裡集團開始大面積的做自動化制圖的嘗試,有影響力的包括魯班系統。從 OTT 的業務場景出發,這些平臺存在一些不足:比如,所生產物料的最終落地形式是一次性的,忽略瞭物料的源和產物最核心的內容價值。

從渠道維度來講, OTT 側坑位圖具有高度的同質性,不僅包括內容源如節目,而且從產物的角度也如此。例如《愛我就別想太多》,某電視廠商對資源位有明確的要求,而且優酷等平臺方也需要這一內容源,內容源的價值就應該被放大。另外,優酷需要將同一個成品圖,投放到不同渠道上,如果能從產物角度做沉淀,成品圖才能發揮最大價值。

場景單一

制圖工具解決的問題非常有限,主要是節目圖的制作。前文提到,從內容源到成品圖都缺少相應沉淀,這使得自動化制圖服務的場景單一,和當前平臺能力相比有明顯差距。

現階段 OTT 自動化制圖涵蓋瞭節目圖、輪播、專題、動圖等常見的制圖場景,並結合自動化與半自動化雙軌模式。半自動化場景下可以充分發揮運營創造性,基於原材料做創新性嘗試;在自動化場景下,直接對接專題輪播系統,使得依賴於特定模板的制圖無需人工參與。

更近一步,在大數據推薦上也有相應場景,比如依賴於客戶端唯一標識實現個性化的專題類推薦,這使得自動化制圖一改之前"自動化"包裝的外表。

分發效率

平臺建立之初,從素材源到成品的完整鏈路都在本地環境完成,依賴於工具平臺下載的成品圖對接給運營、第三方進行投放。嚴重依賴於運營的人力投入,分發效率低,其原因是從內容源到成品庫,到最終的分發鏈路缺乏一致性,所以使得整個系統沒有“活”起來。

所以從平臺建立開始,我們就在探索一條"活"的完整鏈路。通過鏈路的升級,不僅能完成內容源、成品庫的沉淀,也包括最終分發鏈路的升級,從而擺脫傳統工具平臺面臨的點狀而非面狀鏈路。

TOB廠商

"巧婦難為無米之炊",在自動化制圖場景下,所謂的“米”就是模板,模板的格式包括但不限於 PSD 、 SKETCH 等,也包括如 SVG ,比如海棠。“米”是最核心的內容,如果不能從特定的場景中提取內容共性,那麼自動化制圖領域下的效率提升就非常有限,因此共性才是最應該被重視的特征。

並且,這種共性不僅存在於單個內容提供商,也存在於提供商之間。

2、OTT自動化制圖的模式

自動化制圖的優勢非常明顯:

第一是鏈路的升級:通過自動化制圖的流程,可將原來"線下討論- UED 設計-效果確認-開發使用圖片"的一次性長鏈路,轉化為" UED 設計模板-運營制圖-自動/半自動分發"的非一次性完整流程,縮短溝通成本。

第二,內容共享紅利:基於系統設計的高質量毛料庫,產品庫可進一步沉淀,打通多方,減少任何三方重復設計的可能性,將內容價值從原來的一方擴展到整個合作方生態,形成完整的內容回流鏈路;

第三,分發鏈路的建設:基於系統設計的成品圖無需任何人工對接,可直接輸出到渠道三方或者對接任何系統。現有可行的嘗試,如專題系統自動化,大數據的個性化推薦場景等,完成從內容生產到內容自動分發的一體化能力建設。

制圖效率環節:在半自動化制圖場景,站外投放時間可從原來周級縮短為小時級,計件的時間成本減低50%~60%。而在自動化制圖場景,無需任何人工幹預的方式,使得自動化制圖能真正發揮價值。

OTT自建自動化制圖平臺

可能會有人問,阿裡已經有魯班系統等自動化制圖平臺,為什麼優酷OTT要自建?

1、為什麼考慮自建?

與魯班系統服務的(側重商品化屬性)場景不同, OTT 場景更側重媒資屬性。圖片主體維度的偏差,使得很多原本在商品制圖場景下的規則被打破。比如一個簡單的元素縮放操作,常規是按照等比加移動的方式解決。但是在以人物為中心的場景,這可能並不合理。因為在以人為主體的場景中,所有模板的指定需要考慮“人物”,而非人物所在元素圖片的縮放,簡單的說就是人臉,否則可能面臨著人物縮放不滿足模板要求的場景。

因此,我們需要更進一步引入算法或人工打標的新思路。而且,除瞭元素縮放的特有場景,其實這種區別還很多。比如特定場景的模糊效果、動圖繪制、自動化能力輸出等等,這種基於特定業務特性的需求海棠確實難以做到定制。

2、商品圖使用海棠

除瞭生產媒資海報圖以外,OTT業務也需要生產商品圖。比如天貓魔盒:

在沒有自建系統之前,所有天貓魔盒的圖片生產全部依賴於海棠。設計師從海棠後臺傳入模板,然後基於此模板在海棠上做相應的坑位圖。但自建系統後也慢慢嘗試切回到自有系統,主要原因有兩個:

第一,內容回流:OTT 業務本身是一閉環系統,媒資圖和商品圖缺一不可。這使得內容隔離漸漸不被接受。內容回流到自有系統後可以做統一管理、分發,享受現有系統提供的能力;

第二,定制化能力:設計師的需求往往依據業務的迭代漸漸變化,漸進增強成為一個常態。因此,當自己的述求不被滿足或者不會被滿足後可能會漸漸的喪失信心,進而轉向新的平臺。而自建系統正好提供瞭這樣一個契機。下圖提供瞭一個基於多模板拼接的述求。任何模板可以隨意拖進工作區,然後對模板元素加工並設置模板特性,比如模板間距等。

OTT自動化制圖的流程

關於自動化制圖我們是如何實現的?整體流程可以簡化為下圖:

1、模板解析與數據格式化

自動化制圖的前提是內容的共性,共性點更近一步的提取,就是模板,模板格式包括但不限於 PSD 、 SKETCH 、 SVG 等。任意一張成品圖都可以看做是基於某一種模板生產出來的,這張成品圖由不同圖層構成,這和 Photoshop 中的圖層是同一個道理。比如以下示例圖就包含瞭角標、文案賣點、主題、主角、蒙版,背景圖等諸多圖層。通過對不同圖層的自由組合、編輯,得到最終的成品圖。

上面講到模板是由不同的圖層所描述的,更形象的,模板就是解析後得到的格式化數據,描述瞭模板中的元素信息,如位置、尺寸、數量等等。而成品圖可以看做是基於這些約定(也可以看做是圖紙)生產出來的最終元素。

上圖就是對 PSD 的解析後獲取到的模板縮略圖。當然,正如前文所講,解析後圖片的存在形式也不再是圖片本身,而是格式化的數據,一般是對應的 JSON。該 JSON 包含瞭模板指定的所有元素信息:

2、前端依據模板繪制流程

服務端做瞭統一的數據格式化後,給到前端的是格式化的數據,數據指定瞭模板包含的所有元素信息,前端基於該元素信息進行繪制。

分層繪制

HTML5 頁面中圖層的概念大傢應該已經很熟悉瞭。講到 HTML5 的網頁分層就需要深入理解 Chrome 渲染原理中的 RenderObject 、 RenderLayer 、 Graphiclayer 等幾棵樹。

除瞭網頁會分層以外, Canvas 中繪制的元素也可以分層,分層繪制有很多優勢。比如在遊戲場景中,很多背景類的圖層需要重繪的可能性遠比動態元素,如障礙物低得多。因此,在每一幀的繪制行為中,可以繞過相應背景圖的繪制,直接繪制當前場景變化的圖層即可,這與 Chrome 網頁分層要解決的問題是一樣的。

以上是一個簡單的分層繪制的類,通過該類可以隨意新增、移除、獲取、渲染任意的圖層。這也是很多復雜的多圖層繪制框架的最核心思想,比如 fabric.js 或者 konvajs 。有瞭這樣的圖層管理框架,就可以根據服務端下發的格式化數據來繪制模板中指定的任意元素,以模板為圖紙,生產出符合設計規定的核心產品。例如:

在該Canvas上,我們繪制出幾個指定的圖形看看效果如何:

上面的代碼通過鏈式調用在 Canvas 中添加瞭4個對象, id 分別為 background 、 squares 、 circles 、 triangles 。而且每一個對象都有相應的 render 方法,該方法指定瞭元素本身在 Canvas 的上下文是如何繪制的。基於以上代碼可以看到在 Canvas 中繪制的效果:

單量與批量模式實時渲染

本小節將講述首輪繪制後如何基於用戶輸入做相應的更新。其實所有的半自動化繪圖場景,運營不可能隻根據某一個模板進行繪制,換句話說,多模板同時繪制的場景必須加以考量。

比如,大多數場景下,運營需要同時基於模板來繪制海信、康佳、歌華、 LG 的所有坑位圖然後導出或者投放,進而擺脫每次隻能單獨繪制導出單模板的低效模式。因此基於多模板實時繪制渲染的方式就亟待解決。基於此,在半自動化繪制場景中,天生支持多模板實時渲染繪制的模式,正如下面的動圖所示:

上圖展示的是多模板實時修改的場景,也就是所謂的聯動模式。但在未開啟聯動模式的場景下,所有的修改隻針對單模板生效。因此在滿足成品圖共性的同時又保證瞭模板的個性。

3、數據統一存儲在服務端

前面講過,工具化平臺的設計思路沒法做到鏈路的完整串聯,進而完成內容的回流,這在平臺化的思路下是行不通的。平臺化解決問題的思路是:從內容生產到內容消費的完整鏈路串聯。

基於此,從輸入到輸出,到最終的分發都需要流動起來,這一切的前提都基於數據的存儲,從輸入源到輸出結果。基於存儲的結果,完成瞭從自動化生產,個性化等自由推薦。

OTT蜂鳥制圖場景的主要輸出與輸入

下圖展示瞭制圖平臺在業務上所做的嘗試,也總結瞭在支撐業務的同時,如何在技術上做范式的探索。

從 1.0 到 2.0 ,是整個系統架構的升級。系統現有支持能力在 OTT 場景下已經逐漸完善起來。

1、技術側主要輸出

服務化的能力

服務化的能力是上面所述的解決問題范式的具體形式,而制圖平臺服務化的能力已經涵蓋瞭包括:通用模板解析能力,圖片合成服務化能力,素材服務化能力,統一分發能力等等。

通用模板解析能力,不僅適用於制圖場景的數據格式化,在智能化領域也有涉及;

圖片合成服務化能力,不僅可用於制圖場景,對於動畫合成場景也有滲透;

至於素材的服務化,分發能力的聯合在業務賦能的同時,也能謀求業務發展方向的新思路。

半自動化合圖嘗試

服務化能力將制圖的觸角做瞭極大的延展,但在半自動化的制圖場景,依然需要探究新的制圖范式。基於此,我們產出瞭自有的 Canvas 合圖嘗試,這與魯班、海棠的模式有極大的差異。這條路沒有太多的參考,很多問題需要自己去挖坑和填坑。

2、無人工自動化制圖

自動化制圖具有極大的吸引力,無需運營任何手動制圖幹預,直接在系統中選擇相應的內容集合即可。因此,這種業務賦能嘗試也被極大的重視起來。在 OTT 業務范圍內比較成功的案例就是專題系統:

通過指定內容集合( scgid )以及相應的封面圖生成規則就可生成相應的專題推薦內容,極大的節省瞭人力成本。

Tag: