fuchsia.images2

新增：12

結構

RectU

定義於 fuchsia.images2/math.fidl

一個以 2D 購物車對齊的整數、長方形對齊區域 空格鍵，並且包含未簽署的地點和距離欄位。

這個類型不會指定單位。使用這個類型的通訊協定 指定向量空間的特性，包括方向和 。

移除：18 新增：12

欄位類型說明預設
x uint32

矩形的 X 軸起點位置。

 無預設
y uint32

矩形的 Y 軸位置。

 無預設
width uint32

沿著 X 軸的距離。

區域包含從 x 開始的 x 個值，並沿著 X 軸來參照

 無預設
height uint32

沿著 Y 軸的距離。

區域包含從 y 開始的 y 值，並沿著 Y 軸的值

 無預設

ENUMS

ColorSpace 彈性

類型：uint32

定義於 fuchsia.images2/image_format.fidl

表示用來解讀影片像素值的色域。

此清單針對色彩空間標準的每個子類，分別提供一個項目。

因此，如果我們支援 RGB 變化版本 709， 我們會在這份清單中新增該變化版本專屬的項目。同樣是 2020 或 2100 的 RGB 變化版本。同樣地，針對 YcCbcCrc 變化版本 2020 年。同樣地，ICtCp 變體為 2100。

請參閱 ImageFormatIsSupportedColorSpaceForPixelFormat()瞭解 可能支援 PixelFormat 和 ColorSpace 的組合。

一般來說，如果 PixelFormat 符合以下條件，則不支援 ColorSpace 位元/樣本的位元數與色域的規格或任何 PixelFormat 與 RGB 與 YUV 不相符。

「有限範圍」在以下的留言中，是指黑白人 定義為 (及色標的 SIM 卡)，但不應解讀為 確保名詞的「範圍有限」。 換句話說，「範圍有限」並不一定會 值低於黑色或大於白色，或超出「受限」的範圍每個色碼範圍 「完整範圍」的黑色為 0，白色則是最大可能/允許的數值上限 值 (以色度來說也是如此)。

名稱值說明
0

顏色空間類型無效。
1

sRGB、Gamma 傳遞函數和完整範圍 (依規格)
2

601 NTSC (「525 行」) YCbCr 原色，有限範圍
3

601 NTSC (「525 行」) YCbCr 初選，完整範圍
4

601 PAL (「625 行」) YCbCr 初選，有限範圍
5

601 PAL (「625 行」) YCbCr 初選，完整範圍
6

709 YCbCr (非 RGB)，範圍有限
7

2020 YCbCr (非 RGB，而非 YcCbcCrc)、10 或 12 位元，根據 PixelFormat，有初選，範圍有限 (非完整範圍)，轉乘 函式 (「gamma」)，依規格、廣色域 SDR 等等
8

2100 YCbCr (非 RGB，而非 ICtCp)，10 或 12 位元，根據 PixelFormat，BT.2020 初選 (與 REC2020 相同的廣色域)、 有限範圍 (非完整範圍)，PQ (即 SMPTE ST 2084) HDR 傳輸 函式 (非 HLG，而非 REC2020 和 REC709 使用的 SDR「gamma」)，寬版 色域 HDR
9

像素格式不代表顏色，就是 應用程式特定的顏色空間，無法由另一個項目描述 列舉這些例子
4294967294

用戶端明確指出， 選擇 / 使用的色域。

PixelFormat 彈性

類型：uint32

定義於 fuchsia.images2/image_format.fidl

表示影片像素的編碼方式。

格式名稱中的管道順序反映了實際的版面配置 管道。

每個值都須由 RE 決定。您想要的色彩空間 (與 Vulkan 相比)。

名稱值說明
0
1

僅限 RGB，每個 R/G/B/A 樣本各 8 位元

與 VK_FORMAT_R8G8B8A8_UNORM 相容。
119

僅限 RGB，每個 R/G/B/X 樣本各 8 位元

即使系統將其視為不透明，也能與 VK_FORMAT_R8G8B8A8_UNORM 相容。
101

32bpp BGRA，1 面。僅限 RGB，每個 B/G/R/A 樣本 8 位元。

與 VK_FORMAT_B8G8R8A8_UNORM 相容。

在 sysmem(1) 中，此為 BGRA32。
120

32bpp BGRA，1 面。僅限 RGB，每個 B/G/R/X 樣本各 8 位元。

與 VK_FORMAT_B8G8R8A8_UNORM (不透明) 相容。
102

僅限 YUV，每個 Y 樣本 8 位元

與 VK_FORMAT_G8_B8_R8_3PLANE_420_UNORM 相容。
103

僅限 YUV，每個 Y 樣本 8 位元

與任何 vulkan 格式都不相容。
104

僅限 YUV，每個 Y 樣本 8 位元

與 VK_FORMAT_G8_B8R8_2PLANE_420_UNORM 相容。
105

僅限 YUV，每個 Y 樣本 8 位元

與 VK_FORMAT_G8B8G8R8_422_UNORM 相容。
106

這是保留值，目前並未使用。
107

僅限 YUV，每個 Y 樣本 8 位元

與 VK_FORMAT_G8_B8_R8_3PLANE_420_UNORM 相容。U 飛機可能位於以下兩者之一： 圖片的 B 或 R 平面 (如果是 V 平面)；順序可能是 通過內部研究 VkBufferCollectionPropertiesFUCHSIA.samplerYcbcrConversionComponents。
108

24 bpp BGR，1 圈。僅限 RGB，每個 B/G/R 樣本 8 位元

與 VK_FORMAT_B8G8R8_UNORM 相容。

在 sysmem(1) 中，此為 BGR24。
109

16bpp RGB、1 平面。5 位元 R、6 位元 G、5 位元 B

與 VK_FORMAT_R5G6B5_UNORM_PACK16 相容。

在 sysmem(1) 中，此為 RGB565。
110

8bpp RGB、1 平面。3 位元 R、3 位元 G、2 位元 B

與任何 vulkan 格式都不相容。

在 sysmem(1) 中，此為 RGB332。
111

8bpp RGB、1 平面。2 位元 R、2 位元 G、2 位元 B

與任何 vulkan 格式都不相容。

在 sysmem(1) 中，此為 RGB2220。
112

8bpp，純亮 (紅色、綠色和藍色具有相同的值)。

與 VK_FORMAT_R8_UNORM 相容。

大部分的客戶偏好使用 R8。
113

8bpp，僅限紅色 (綠色和藍色會被解讀為 0)。

與 VK_FORMAT_R8_UNORM 相容。
114

16bpp RG，1 號飛機。8 位元 R、8 位元 G。

與 VK_FORMAT_R8G8_UNORM 相容。
115

32bpp RGBA、1 平面。2 位元 A、10 位元 R/G/B。

與 VK_FORMAT_A2R10G10B10_UNORM_PACK32 相容。
116

32bpp BGRA，1 面。2 位元 A、10 位元 R/G/B。

與 VK_FORMAT_A2B10G10R10_UNORM_PACK32 相容。
117

僅限 YUV，每個 Y 樣本 16 位元

這與 NV12 類似，但包含 16 位元樣本的最低 6 位元 並將每個樣本設為 0 和/或略過每個 16 位元的耐力 樣本是主機端序 (LE 系統上的 LE，BE 系統)。警匪 先是 16 位元 Cb，然後是 16 位元 Cr，交錯 Cb Cr Cb Cr 等

與 VK_FORMAT_G10X6_B10X6R10X6_2PLANE_420_UNORM_3PACK16 相容。
118

24bpp RGB、1 平面。僅限 RGB，每個 R/G/B 樣本均 8 位元

與 VK_FORMAT_R8G8B8_UNORM 相容。
4294967294

用戶端明確指出， 選擇 / 使用。設定這個值時，用戶端必須 未設定「pixel_format_modifier」。

PixelFormatModifier 彈性

類型：uint64

定義於 fuchsia.images2/format_modifier.fidl

上方 8 位元是供應商代碼。較低 56 位元是由供應商定義。

定義的 PixelFormatModifier 值是具體、完整且有效 的值 (除了有專屬的 INVALID 和 DO_NOT_CARE 以外) 意義)。

其他有效或可能有效的 pixel_format_modifier 值不是 定義為 PixelFormatModifier 值，通常是因為該值不是 應用情境 (也可能是最近用過，但尚未定義到 PixelFormatModifier)。您可以將這類值指定為 pixel_format_modifier 欄位中的 PixelFormatModifier 值，雖然 缺少對應的已定義 PixelFormatModifier 值。如果這樣 是在測試程式碼之外使用，請考慮在 PixelFormatModifier。所有這類值都必須符合上限 8 位元 供應商程式碼 (請勿在/合適供應商以外的地方定義/使用值) 程式碼)。

個別定義的 FORMATMODIFIER* uint64 值是由供應商設定 位元欄位值，請自行輸入無效值。這些 uint64 值可用於建立或解讀 PixelFormatModifier 值 依據供應商專屬的 位元欄位呼叫

pixel_format_modifier 設為支援的值時 (不包括 DO_NOT_CARE、INVALID、LINEAR)，否則排列像素資料的方式。 則是由 pixel_format 欄位指定的 一些傾斜、壓縮 (通常為無損的) 減少記憶體頻寬，而非縮減影格緩衝區大小)， 消除、追蹤泥土，但一般不會修改 pixel_format。在某些情況下，每個圖片或每個圖塊都有標題 互動或類似的內容您通常仍需設定 pixel_format 欄位 有效支援的值，與 pixel_format_modifier，而該 pixel_format 值也可以貢獻 有關 ImageFormat 的整體意義。也就是「修飾符」 名稱中有一部分比「覆寫」正確答案是：

名稱值說明
72057594037927934
72057594037927935
0
72057594037927937
72057594037927938
72057594037927939
72057594054705154
72057594054705155
576460752303423489
576460752303423490
576460752303427584
576460752303427585
576460752303427586
576460752303431697
576460752303423601
576460752303427697
576460752303431793
576460752303435889
7421932185906577409

資料表

ImageFormat

定義於 fuchsia.images2/image_format.fidl

說明圖片的格式。

序數欄位類型說明
pixel_format PixelFormat

說明像素的編碼方式。
pixel_format_modifier PixelFormatModifier

供應商專用像素格式修飾符。請參閱「 format_modifier.fidl」。
color_space ColorSpace

指出用來解讀像素值的色域。
size fuchsia.math/SizeU

圖片大小 (以像素為單位)。

另請參閱 bytes_per_row 以及 size 說明， 找出每個像素資料在緩衝區中的位置。

緩衝區中不一定所有可定址的像素位置 填入有效的像素資料請參閱 valid_size 可能較小的有效像素矩形。

圖片的右側和底部可能會有一些有效像素， 不會顯示詳情請參閱《display_rect》。
bytes_per_row uint32

每列的位元組數。如果是多飛機 YUV 格式，請使用數字 Y 層中每個資料列的位元組數

如未設定這個欄位，則每列末端不會有邊框間距 比方針。換句話說，在未設定的情況下，步距等於 「每個寬度像素的刪除位元組」乘以 size.width。

設定之後，這個欄位中的值必須大於或等於「每個寬度的刪除位元組」 Pixel」乘以 size.width。相等時， 位置不會有邊框間距 每一個列的像素末端如果數值大於 邊框間距位於每列像素的結尾 (以位元組為單位)。

也稱為「步距」、「行距」、「行列偏移」 位移」等名稱。

具體來說，這個情況並不常見 (但不一定是必要做法) BGR24 (每像素 3 個位元組) 在每個結尾加上邊框間距 這樣每一列的像素都會從 4 位元組對齊的偏移值開始 圖片開頭 (左上方像素)。邊框間距大小是 不一定可以用像素大小除法 (「步位元組」 所以我們可以使用這個欄位來指出邊框間距 而不是試圖將邊框間距納入更大的「假造」 size.width。
display_rect fuchsia.math/RectU

顯示畫面的矩形。這裡是位置 應該顯示矩形廣告尺寸 (以像素為單位) 顯示「整張圖片」實際操作時

x + width 必須小於= size.width，而 y + height 必須 小於或等於 size.height。

在影片解碼器的輸出內容中，display_rect 以外的像素是 絕不顯示 (測試計畫以外)，但必須加以保留 正確的解碼器函式display_rect 一律會下降 顯示比例為 (0, 0) 且大小為 valid_size valid_size已設定。換句話說，display_rect 是子集 (非 是適當的子集)，且 valid_size 是valid_size size 的子集 (不一定是正確的子集)。

下游紋理篩選作業應避免讓任何像素 display_rect 之外的部分會影響任何已顯示 像素，為了避免右側或底部邊緣流入 由解碼程序定義的任意像素 (不適用於 螢幕。

未設定這個欄位時的行為會因通訊協定而異。某些 系統可能會實作通訊協定，改回 valid_size，再改為 size。 在其他情況下，您可以直接導入 size 的備用方案。在其他情況下 您必須設定這個欄位，否則管道將會關閉。

警告：fuchsia.sysmem.Images2 (V1) 無法處理非零的 x、y，所以 任何非零 x、y 的 y (V2) 都會使轉換為 V1。由於 實際發生非零 x 的稀疏度，甚至是已移至新位置的元件 在某些情況下，V2 可能仍會假設 x 和 y 皆為 0，直到有 實際理由來植入及測試非零 x y 的處理方法。 傳送非零 x、y 到下游轉譯和/或螢幕的症狀 假設 0, 0 的管道會顯示錯誤，但不會導致當機 因為 0、0 代表 x，y 不會導致讀數超出緩衝區 上下限

新增日期：18
valid_size fuchsia.math/SizeU

影格的大小 (以具備有效像素數量為準) 像素資料解碼階段，但對像素資料 供顯示。

將 Valid_size 轉換為能直接比擬的矩形 display_rect，可以使用 (x: 0, y: 0, width: valid_size.width、height：valid_size.height)。

如果是影片解碼器，valid_size 可以包含一些像素 在 display_rect 之外。多餘的像素不會顯示 也可能不包含任何真實的圖像資料一般而言， 這些地區似乎真的影像資料只是影片成果 以及巨集區塊的其餘部分 後來的影格參考，即使不在顯示中 並未提供任何其他「真實」像素。 這裡的像素值是由轉碼器解碼程序所定義 都必須保留，才能進行正確的解碼器作業。通常是像素 範圍之內，但 display_rect 以外的螢幕_rect 不會大於 微距減號 1。valid_size 適用於測試影片 以及特定轉碼情境
pixel_aspect_ratio fuchsia.math/SizeU

影片預計顯示時的像素顯示比例。

YUV 格式的像素顯示比例 (AKA 樣本顯示比例) 又稱 SAR)，用於 Luma (AKA Y) 樣本。

製作人應確保寬度和高度值相對應 即可算出分數 (視需要除以 GCF 值)

消費者應將這個欄位解讀為不明像素 長寬比。在某些情況下可能適合使用預設值 1:1，但 消費者可能會根據 OOB 指標判斷實際的像素顯示比例。

觀測站

名稱值類型說明
FORMAT_MODIFIER_ARM_BCH_BIT 2048 uint64
FORMAT_MODIFIER_ARM_SPARSE_BIT 64 uint64
FORMAT_MODIFIER_ARM_SPLIT_BLOCK_BIT 32 uint64
FORMAT_MODIFIER_ARM_TE_BIT 4096 uint64
FORMAT_MODIFIER_ARM_TILED_HEADER_BIT 8192 uint64
FORMAT_MODIFIER_ARM_YUV_BIT 16 uint64
FORMAT_MODIFIER_INTEL_CCS_BIT 16777216 uint64

格式在圖塊資料後方會具有色彩控制介面
FORMAT_MODIFIER_VENDOR_ALLWINNER 648518346341351424 uint64
新增日期：19
FORMAT_MODIFIER_VENDOR_AMD 144115188075855872 uint64
新增日期：19
FORMAT_MODIFIER_VENDOR_AMLOGIC 720575940379279360 uint64
新增日期：19
FORMAT_MODIFIER_VENDOR_ARM 576460752303423488 uint64
新增日期：19
FORMAT_MODIFIER_VENDOR_BROADCOM 504403158265495552 uint64
新增日期：19
FORMAT_MODIFIER_VENDOR_GOOGLE 7421932185906577408 uint64
新增日期：19
FORMAT_MODIFIER_VENDOR_INTEL 72057594037927936 uint64
新增日期：19
FORMAT_MODIFIER_VENDOR_NVIDIA 216172782113783808 uint64
新增日期：19
FORMAT_MODIFIER_VENDOR_QCOM 360287970189639680 uint64
新增日期：19
FORMAT_MODIFIER_VENDOR_SAMSUNG 288230376151711744 uint64
新增日期：19
FORMAT_MODIFIER_VENDOR_VIVANTE 432345564227567616 uint64
新增日期：19