張海珂 朱宏宣
北京電影學(xué)院中國電影高新技術(shù)研究院,北京 100088
【關(guān)鍵字】Android;移動終端;顯示鏈路;圖像色彩
隨著科技的進(jìn)步,移動終端早已從用途單一的通信設(shè)備發(fā)展到現(xiàn)如今的智能終端設(shè)備,并拓展出了閱讀、觀影、拍攝等豐富的功能,成為人們?nèi)粘I詈蛯W(xué)習(xí)工作中的必備工具。
作為繼電影銀幕、電視屏幕、個人電腦屏幕之后的“第四塊屏幕”,移動終端逐漸成為人們使用最頻繁的圖像顯示設(shè)備。然而,由于不同移動終端在圖像顯示流程、系統(tǒng)配置參數(shù)以及屏幕工作原理,甚至使用方式等方面的差異,會導(dǎo)致其色彩顯示的不一致(圖1),使得人們在不同的移動終端上觀看相同的圖像時,產(chǎn)生不同的觀感,有些嚴(yán)重的色彩偏差甚至?xí)绊懻5挠^看。
圖1 不同Android 手機對于同一圖像顯示的不一致示意
除了民用領(lǐng)域以外,在影視行業(yè)等專業(yè)領(lǐng)域,移動終端也已經(jīng)廣泛地用于監(jiān)看、審閱等工作,移動終端顯示的顏色不一致則會給影視制作人員的溝通帶來不便,影響人們對于影像正確性的判斷,還會影響影像制作的結(jié)果。
導(dǎo)致移動終端圖像顯示結(jié)果不一致的因素是多種的,但核心因素來自于顯示鏈路本身,研究移動終端圖像的顯示鏈路對分析顯示不一致的原因來說十分必要。因此,本文通過研究Android 系統(tǒng)的架構(gòu)以及顯示流程,包括承載圖像數(shù)據(jù)內(nèi)容的Layer 色彩空間的選擇、系統(tǒng)色彩模式的設(shè)置以及移動終端屏幕的類型和不同生產(chǎn)工藝的差異等因素,進(jìn)而分析影響移動終端圖像顯示不一致的原因。
Android 系統(tǒng)是一種基于Linux 技術(shù),由操作系統(tǒng)、用戶界面和應(yīng)用程序組成的具有開源性質(zhì)的手機終端解決方案。Android 系統(tǒng)架構(gòu)分為五層:從下到上依次是Linux 內(nèi)核層、硬件抽象層、系統(tǒng)運行庫層、應(yīng)用架構(gòu)層和應(yīng)用層,各層關(guān)系如圖2所示。
圖2 Android 系統(tǒng)架構(gòu)①
(1)Linux 內(nèi)核層,作為Android 底層的系統(tǒng)使用,是Android 系統(tǒng)的核心。
(2)硬件抽象層(Hardware Abstraction Layer,HAL)是位于操作系統(tǒng)內(nèi)核和硬件電路之間的接口層,為操作系統(tǒng)提供具有硬件無關(guān)性的虛擬硬件平臺。
(3)庫層(Library)的存在主要是為了在Android平臺上復(fù)用一些已經(jīng)開發(fā)好的庫,為上層服務(wù)提供底層實現(xiàn)。
(4)Android 運行時(Runtime)包含核心庫(Core Libraries)和虛擬機(Android Runtime,ART),運行時是一個提供給操作系統(tǒng)使用的系統(tǒng),虛擬機ART 負(fù)責(zé)運行Android 應(yīng)用程序,每一個Android 的應(yīng)用程序都在相應(yīng)的虛擬機中運行。
(5)應(yīng)用架構(gòu)層(Java API Framework)為開發(fā)人員提供了開發(fā)應(yīng)用程序所需要的相應(yīng)API。在應(yīng)用架構(gòu)層中,視圖系統(tǒng)(View System)、活動管理器(Activity Manager)、窗口管理器(Window Manager)三個組件主要服務(wù)于Android 的圖形系統(tǒng)。
View System 負(fù)責(zé)管理View 對象,View 對象承載著應(yīng)用程序中的各種UI 元素,例如按鍵、顯示條等。Activity Manager 負(fù)責(zé)管理Activity,Activity 是應(yīng)用程序界面的載體,主要承載著各種由View System 負(fù)責(zé)的控件。Window Manager 負(fù)責(zé)管理Window,每個應(yīng)用程序端會關(guān)聯(lián)一個Window 對象,用來描述應(yīng)用程序窗口,每一個應(yīng)用程序窗口內(nèi)部又包含一個View對象,用來描述應(yīng)用程序窗口的視圖,應(yīng)用程序窗口視圖則對UI 內(nèi)容和布局進(jìn)行實現(xiàn)。也就是說,應(yīng)用程序上的UI內(nèi)容和布局都是通過與其所關(guān)聯(lián)的一個Window 對象內(nèi)部的View 對象來實現(xiàn),最終在顯示屏上顯示的畫面是由多個窗口組成,如圖3所示,其中,1-3 為系統(tǒng)層面關(guān)聯(lián)的窗口,4 為應(yīng)用程序關(guān)聯(lián)的窗口。
圖3 窗口示意圖②
(6)應(yīng)用層(System Apps),管理著系統(tǒng)級的應(yīng)用程序以及非系統(tǒng)級的應(yīng)用程序,例如:日歷(Calendar)、相機(Camera)、電子郵件(Email)、地圖(Map)、微信(Wechat)等,主要負(fù)責(zé)與用戶進(jìn)行直接交互。
上述介紹了Android 系統(tǒng)的整體框架結(jié)構(gòu),顯示鏈路作為其中的一部分,同樣遵循著Android 系統(tǒng)的架構(gòu),接下來對該鏈路進(jìn)行詳細(xì)闡述。
Android 的圖形顯示系統(tǒng)管理著從渲染到合成再到顯示的過程,圖像信息的顯示流程如圖4所示。
圖4 Android 圖形顯示系統(tǒng)
Android 的顯示系統(tǒng)遵循C/S 架構(gòu),SurfaceFlinger是其中的服務(wù)端,各種含有圖形用戶界面(Graphical User Interface,GUI)的應(yīng)用程序則是用戶端, 應(yīng)用程序的GUI顯示以Surface 為單元[1]。
SurfaceFlinger 作為系統(tǒng)進(jìn)程合成所有窗口的服務(wù),接收系統(tǒng)色彩模式設(shè)置傳輸來的色彩模式參數(shù),系統(tǒng)負(fù)責(zé)合成所有來自系統(tǒng)或不同應(yīng)用程序的Surface 提供的圖形數(shù)據(jù)。Surface 可以抽象為一個繪圖表面,應(yīng)用程序端負(fù)責(zé)往這個繪圖表面中填充圖像內(nèi)容,WindowManagerService 負(fù)責(zé)往這個繪圖表面中填充應(yīng)用程序窗口的屬性,例如位置、大小、透明度等。而SurfaceFlinger 服務(wù)端負(fù)責(zé)取出繪圖表面中的內(nèi)容(在SurfaceFlinger 端,將繪圖表面采用Layer 類來描述),如圖5所示。
圖5 Surface 的對應(yīng)示意
同時Surface 也是應(yīng)用程序與SurfaceFlinger 交互的通道, 每個應(yīng)用程序可以有一個或多個Surface,SurfaceFlinger 將所有的Surface 數(shù)據(jù)通過一定規(guī)則進(jìn)行排列與合成。
圖像從應(yīng)用程序端傳入時,通過應(yīng)用程序的視圖對象View 中Measure、Layout、Draw 方法,對窗口的位置以及大小等屬性進(jìn)行測量和布局,最后通過SurfaceFlinger 請求為Surface 分配一個內(nèi)存Buffer。Android 應(yīng)用程序窗口通過一些Android 系統(tǒng)庫中的圖形庫對Buffer 進(jìn)行操作,將圖片顯示信息通過OpenGL、Skia 等提供的API,利用硬件或軟件的方法渲染繪制在Buffer 上。最后將Buffer 送往Surface-Flinger 中,SurfaceFlinger 與應(yīng)用程序端通過Buffer-Queue 實現(xiàn)內(nèi)存共享,BufferQueue 中包含多個Buffer對象,一些用于渲染繪制,一些用于合成顯示,雙方處理完后,交換Buffer,以此提高效率(圖6)。
通過上述流程,來自多個源的Surface 承載著應(yīng)用程序或系統(tǒng)的圖像數(shù)據(jù)以及窗口屬性,經(jīng)過BufferQueue 來到SurfaceFlinger 系統(tǒng)服務(wù)后,由SurfaceFlinger 的Layer 接收相應(yīng)的圖像數(shù)據(jù)、窗口屬性信息,并從系統(tǒng)傳下來的色彩模式設(shè)置參數(shù)信息,待接收到刷新的指令(VSync)后,SurfaceFlinger 對Surface 進(jìn)行合成,然后發(fā)送到顯示設(shè)備進(jìn)行顯示。HWC2 是SurfaceFlinger 用來與專門的窗口合成硬件進(jìn)行通信的工具,合成工作在硬件端通常由顯示處理單元(Display Processor Unit,DPU)完成,DPU 作為圖形硬件的一部分,通常被封裝在圖形處理器(Graphic Processing Unit,GPU)模塊當(dāng)中,最主要的功能是將GPU 渲染完成的圖層合成輸出到屏幕。DPU 在完成合成工作后將連接顯示設(shè)備(OLED、LCD、HDMI 等),并向其輸送像素色彩信息。為保護知識產(chǎn)權(quán),顯示設(shè)備廠家通常會將硬件接口進(jìn)行封裝,通過硬件抽象層提供的虛擬硬件平臺進(jìn)行連接,最多支持同時2路輸出設(shè)備。
在Android 系統(tǒng)圖像顯示流程中,Surface 承載著圖像顯示數(shù)據(jù)和應(yīng)用程序窗口的屬性,將各種數(shù)據(jù)接收和傳遞到顯示流程的各個服務(wù)當(dāng)中。在應(yīng)用程序端,Surface 將接收圖像的色彩信息,通過Buffer-Queue 傳輸?shù)椒?wù)端SurfaceFlinger,SurfaceFlinger 端通過Layer 接收由BufferQueue 傳來的圖像色彩數(shù)據(jù),因此Layer 中的色彩空間選取會影響圖像色彩數(shù)據(jù)的呈現(xiàn)效果。
在接收圖像信息時,系統(tǒng)會為Layer 分配相應(yīng)的Buffer,同時選擇相應(yīng)的色彩空間參數(shù)。Android 中可被選擇的色彩空間有包含HDR、SDR 范圍在內(nèi)的BT.2020、Display P3、DCI-P3、sRGB 等,這些色彩空間參數(shù)在系統(tǒng)內(nèi)部由DataSpace 參數(shù)記錄,DataSpace 描述了應(yīng)用程序和硬件如何解釋在應(yīng)用程序端接收的圖像色彩數(shù)據(jù),DataSpace 包含顏色的三個部分,三原色信息、轉(zhuǎn)換函數(shù)和數(shù)據(jù)范圍,例如:DataS-pace_sRGB 參數(shù)如圖7所示。
若應(yīng)用程序沒有對Layer 的DataSpace 進(jìn)行設(shè)置,系統(tǒng)則自動將DataSpace 設(shè)置為默認(rèn)UNKNOWN,UNKNOWN 在最終顯示時會被當(dāng)成sRGB 對待,若此時承載的數(shù)據(jù)信息是Display P3 等不與sRGB 相同的色彩空間圖像,則會出現(xiàn)色域不匹配的問題,導(dǎo)致所承載的圖像數(shù)據(jù)信息不正確,進(jìn)而造成圖像顯示的不一致。
在3.1 所描述的顯示流程中,除了Layer 色彩空間選擇之外,移動端系統(tǒng)色彩模式設(shè)置也對圖像顯示造成了影響。移動端中有許多可以提供給消費者選擇的色彩模式,例如自然模式、鮮艷模式、效果增強模式、自動調(diào)節(jié)模式,不同的Android 手機至少提供兩種或兩種以上的色彩模式。這些色彩模式會傳入SurfaceFlinger 中,對合成設(shè)置中的色彩參數(shù)進(jìn)行修改,不同的色彩模式會根據(jù)相應(yīng)的設(shè)置改變移動端顯示的色彩,下面主要分析不同的色彩模式在顯示流程中對圖像顯示造成的影響。
Google 給出的四種色彩模式包括自然模式、鮮艷模式、效果增強模式、自動調(diào)節(jié)模式。在系統(tǒng)面板中選中相應(yīng)的模式后,相應(yīng)模式對應(yīng)的參數(shù)將傳入SurfaceFlinger 中,上述四種模式主要通過兩個參數(shù)來描述,分別是Saturation 飽和度和DisplayColorSetting 顯示顏色,Saturation 飽和度有兩種可選模式:Natural 和Boosted;DisplayColorSetting 顯示顏色有三種可選模式:Managed、UnManaged 以及Enhance。而不同的色彩模式分別對應(yīng)不同的飽和度和顯示顏色兩個參數(shù),具體的對應(yīng)情況如表1、2所示。
表1 飽和度Saturation 參數(shù)對應(yīng)情況
表2 顯示顏色DisplayColorSetting 參數(shù)對應(yīng)情況
在上層系統(tǒng)中選中的色彩模式,按照表1、2 中對應(yīng)情況將相應(yīng)的參數(shù)傳入系統(tǒng)底層,例如自然模式傳入飽和度參數(shù)為Natural,傳入顯示顏色為Managed。上述參數(shù)將傳入SurfaceFlinger 中對Layer 合成的色彩參數(shù)做相應(yīng)的修改。
當(dāng)SurfaceFlinger 接收到傳入的DisplayColorSetting、Saturation 的數(shù)據(jù)時,將會結(jié)合前文所述Layer 的Dataspace,確定出targetDataspace、ColorMode 和RenderIntent 三個參數(shù),最終由這三個參數(shù)生成Color-Map,傳到硬件端。注意此處的ColorMode 與上文的應(yīng)用層端的色彩模式不同,此處的ColorModes 與設(shè)備硬件所支持的色彩模式有關(guān)。
在SurfaceFlinger 中,確定targetDataspace、Color-Mode和RenderIntent的具體數(shù)值。
若上層傳下來的DisplayColorSetting 為UnManaged,則不進(jìn)行任何色彩管理,顯示效果將簡單結(jié)合設(shè)備本身的硬件特性確定一套顯示效果參數(shù),能夠較好地表現(xiàn)出屏幕硬件本身特點,但忽略流程中出現(xiàn)的任何色彩空間參數(shù)的限制,由表1 對應(yīng)可知,不進(jìn)行色彩管理的色彩模式為鮮艷模式。若Display-ColorSetting 參數(shù)不為UnManaged,則遵循下述流程。
首先,通過getBestDataspace 函數(shù)根據(jù)Layer 的DataSpace 確定targetDataspace 參數(shù),函數(shù)將遍歷來自各應(yīng)用程序或系統(tǒng)的Layer 的DataSpace,并將根據(jù)ZOrder 的順序,將最上層的Layer 的DataSpace 作為targetDataspace 的值,其余Layer 的DataSpace 若與最上層的Layer 的DataSpace 不符,則需要對該Layer 做色彩空間的轉(zhuǎn)換。
其次,targetDataspace 確定后,需要確定Render-Intent,RenderIntent 由傳遞下來的DisplayColorSetting確定,對應(yīng)的參數(shù)如表3所示。
表3 RenderIntent 與DisplayColorSetting 對應(yīng)情況
由表3 可知,有COLORIMETRIC 和ENHANCE 兩個參數(shù),其中COLORIMETRIC 參數(shù)不對顯示做任何操作,而ENHANCE 則會將色彩空間拉伸到顯示設(shè)備所能夠顯示的最大色域中,也就是說會改變圖像的色域,將圖像正確的色域拉伸到更大的色域中,使其變得更加鮮艷。
由上層傳下來的飽和度Saturation 參數(shù)則影響顯示的RGBA 值,飽和度通過生成saturationMatrix,將此矩陣與傳輸來的圖像數(shù)據(jù)中的RGBA 值相乘得到新的RGBA 值,通過改變RGBA 數(shù)據(jù)改變圖像的色彩顯示。
最后,調(diào)用getBestColorMode 函數(shù),根據(jù)targetDataspace、RenderIntent 來從本機支持的ColorMode List中確定ColorMode。上述這些參數(shù)在顯示刷新的過程中被傳遞給HAL 層,生成相應(yīng)ColorMap,設(shè)置硬件的顯示參數(shù)。色彩模式參數(shù)傳遞的流程圖如圖8所示。
圖8 色彩模式參數(shù)傳遞流程
經(jīng)由上述流程可以分析得知,圖像顯示的正確與否和承載圖像數(shù)據(jù)的Layer 以及色彩模式的選擇有關(guān),Layer 的相關(guān)參數(shù)影響已經(jīng)在3.1 中闡述。對于色彩模式而言,想要圖像能夠正確顯示,需選擇自然模式的色彩模式,其余三種模式通過改變參數(shù)的方式對圖像色彩進(jìn)行了相應(yīng)的改變。鮮艷模式簡單地結(jié)合設(shè)備本身的硬件特性確定一套顯示效果參數(shù),不同的硬件顯示設(shè)備各有其特點,因此顯示出來的顏色也不一致;自動調(diào)節(jié)模式對色域進(jìn)行了拉伸,將原始色域拉伸至顯示設(shè)備支持的最大色域,旨在凸顯顯示設(shè)備的優(yōu)勢;效果增強模式則對RGBA 矩陣數(shù)據(jù)進(jìn)行了更改,使其變得更加飽和,更加鮮艷;各模式在不同方面對圖像數(shù)據(jù)進(jìn)行了相應(yīng)的改變,導(dǎo)致了圖像顯示的不一致性。
圖9 為華為P50E 中的標(biāo)準(zhǔn)模式和鮮艷模式下的圖像顯示,因此,不同色彩模式下的圖像顯示不一致。
圖9 不同色彩模式下的圖像顯示
移動終端主要采用的屏幕類型有OLED 和LCD兩種,例如:華為P60、OPPO Find X6、小米13 等采用OLED 屏幕,暢享60X、OPPO K10x 等采用LCD 屏幕。OLED 和LCD 因其不同的顯示原理也會導(dǎo)致圖像顯示的不一致。在OLED 屏幕中,每一個像素都由三個基本顏色的發(fā)光結(jié)構(gòu)構(gòu)成(圖10),通過化學(xué)反應(yīng)使得內(nèi)部的有機材料發(fā)光。LCD 為液晶顯示器,液晶本身不發(fā)光,通過背光發(fā)光,以液晶面板控制光通量的方式進(jìn)行顯示[2]。由于液晶分子的特性,LCD 無法做到完全遮擋背光,屏幕會出現(xiàn)“漏光”的現(xiàn)象,所以LCD 屏幕無法顯示真正意義的純黑色(圖11)。而OLED 顯示屏是通過打開和關(guān)閉數(shù)百萬個微小的單個OLED 控制發(fā)光,每個OLED 構(gòu)成顯示器的單個像素,可以通過關(guān)閉該像素的OLED 達(dá)到純黑顯示,因此擁有比LCD更純粹的黑以及更高的顯示對比度。
圖10 OLED 內(nèi)部結(jié)構(gòu)④
圖11 LCD 內(nèi)部結(jié)構(gòu)⑤
在亮度方面,LCD 由于液晶面板較為復(fù)雜的結(jié)構(gòu),需要對一些電路和排線等做遮光處理,光線從背光光源發(fā)射出來后,并不能夠完全穿過液晶面板,降低了LCD 的顯示亮度。OLED 由于其自發(fā)光原理,擁有更大的開口率,光線損耗較少,因此普遍擁有比LCD 更高的顯示亮度。
除了顯示原理的影響之外,屏幕生產(chǎn)廠家的生產(chǎn)工藝不同也影響著屏幕的顯示效果(圖12),現(xiàn)如今,國內(nèi)大多手機品牌都采用京東方、華星光電、天馬、三星等國內(nèi)外知名廠家生產(chǎn)的屏幕,例如華為、小米、OPPO 等。即使是同一型號的手機屏幕,由于生產(chǎn)廠家的技術(shù)流程和誤差標(biāo)準(zhǔn)不同,也會造成顯示不一致。
圖12 京東方(左)和天馬(右)OLED 屏幕顯示效果對比
此外,由于生產(chǎn)批次不同,即便是同一個廠家生產(chǎn)的屏幕,也會有一定程度的差異,例如LCD 屏幕背光的白光波長、LCD 偏光片的旋轉(zhuǎn)角度、OLED 中蒸鍍的有機發(fā)光材料厚度等,都會導(dǎo)致圖像顯示不一致。
總之,對于移動端圖像顯示而言,不同類型屏幕的顯示特性,不同的技術(shù)工藝和生產(chǎn)批次,都會對圖像顯示的一致性造成影響。
大多數(shù)顯示設(shè)備通常僅限于室內(nèi)使用,但移動終端的自身特點決定了其使用的環(huán)境范圍非常廣泛,如白天、晚上、室內(nèi)辦公室和室外環(huán)境等[3],外界光在色域、亮度、對比度等方面會對顯示器顯示圖文信息造成干擾[4],影響著移動端最佳的色彩表現(xiàn)。除此之外,手機屏幕上是否覆蓋手機膜、手機膜的種類(例如防藍(lán)光膜、防窺膜等)、手機屏幕的使用導(dǎo)致的老化等因素,也會影響圖像的顯示亮度和色彩準(zhǔn)確度。
綜上所述,在基于Android 系統(tǒng)的移動終端顯示鏈路中,顯示流程、參數(shù)配置和硬件表現(xiàn)都會對圖像的顯示一致性造成直接影響,其中一部分因素可以通過正確設(shè)置進(jìn)行規(guī)避,另一部分因素需要通過更復(fù)雜的手段進(jìn)行改進(jìn)。
目前采用Dolby Vison 顯示技術(shù)的移動終端,已經(jīng)較好地解決了HDR 圖像內(nèi)容顯示不一致的問題,但對于未采用Dolby Vison 技術(shù)的移動終端,顯示SDR 內(nèi)容時不一致問題依然存在。希望本文在此方面的探討有助于該問題的解決,相信在未來,隨著移動終端的發(fā)展,圖像色彩顯示不一致的問題會得到改善和解決。
作者貢獻(xiàn)聲明:
張海珂:主導(dǎo)設(shè)計論文框架,撰寫和修訂論文,全文文字貢獻(xiàn)80%;
朱宏宣:指導(dǎo)設(shè)計論文框架,修訂論文,全文文字貢獻(xiàn)20%。
注釋
①圖片來源于網(wǎng)站https://developer.android.com/guide/platform?hl=zh-cn。
②圖片來源于網(wǎng)站https://www.jianshu.com/p/6474297924b6。
③圖片來源于網(wǎng)站https://developer.android.com/reference/android/hardware/DataSpace#DATASPACE_UNKNOWN。
④圖片來源于網(wǎng)站https://www.utmel.com/blog/categories/optoelectronics/what-is-oled。
⑤圖片來源于網(wǎng)站https://www.yaoyulcd.com/whatislcd.html。