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 定義

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

這份清單針對色域標準的每個變化版本，都有獨立的項目。

因此，我們是否應該新增 709 的 RGB 變體支援，例如，針對該變數，我們會在這份清單中新增一個項目。對 2020 或 2100 的 RGB 變體也類似。也同樣適用於 2020 年的 YcCbcCrc 變化版本。2100 的 ICtCp 變化版本也類似。

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

一般來說，ColorSpace 不支援任何與色域規格不相容的 PixelFormat，也不支援任何 PixelFormat，而 RGB 與 YUV 不符。

下方註解中的「限制範圍」是指黑色和白色定義為 (且對色具有短暫作用) 的位置，但不應解釋為保證不會超出名詞的「有限範圍」。換句話說，「限制範圍」並不一定表示小於黑色或高於白色或「有限」色點範圍以外的任何值。如為「完整範圍」，黑色為 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 傳輸函式，並非使用 0 HLG、
9

像素格式並不代表顏色，或者位於應用程式專屬的色彩空間，且此列舉項目中的其他項目無法描述。
4294967294

用戶端會明確表示用戶端不在乎選擇 / 使用哪個色域。

像素格式彈性

類型：uint32

如 fuchsia.images2/image_format.fidl 定義

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

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

這些值都具有明確性，應該包含的色彩空間 (與 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 和 R 刷新率相容。
108

24bpp 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 位元設為零和/或忽略。每個 16 位元樣本的耐心性為主機對端 (LE 系統上的 LE，在 BE 系統上為 BE)。CbCr 平面先有 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 中定義)。即使沒有對應的 PixelFormatModifier 值，您仍可在 pixel_format_modifier 欄位中將這類值指定為 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。

設定完成後，這個欄位中的值必須 >=「每個寬度像素的跨位元組」乘以 size.width。如果相同，像素列末端就沒有邊框間距。如果大於的話，差異在於每列像素結尾的邊框間距 (以位元組為單位)。

這也稱為「跨距」、「行列偏移」、「列至列偏移」和其他名稱。

舉例來說，BGR24 (每個像素 3 位元組) 在每列結尾處都有一些邊框間距，因此其實邊框間距大小不一定能由像素大小 (「每個寬度像素」的長方形) 分割，因此您可以使用這個欄位指出邊框間距，而不是嘗試將邊框間距合併為較大的「假」size.width。
display_rect fuchsia.math/RectU

頁框內顯示的矩形。這是在 UI 顯示畫面中顯示「整個圖片」時，應顯示的像素矩形位置和大小 (以像素為單位)。

x + width 必須 <= size.width，且 y + height 必須 <= size.height。

如果是影片解碼器的輸出內容，則一律不會顯示 display_rect 以外的像素 (測試程式以外的內容)，但必須保留才能正確解碼器函式。當設定 valid_size 時，display_rect 一律會落在矩形內，且大小從 (0, 0) 開始，大小為 valid_size。換句話說，display_rect 是 valid_size 的子集 (不一定需要適當的子集)，而 valid_size 是 size 的子集 (不一定是適當的子集)。

下游紋理篩選作業應避免讓 display_rect 以外的任何像素影響顯示像素的視覺外觀，以免在解碼程序定義的任意像素中 (但不適合顯示) 的右側或底部邊緣流失。

未設定這個欄位時的行為與通訊協定無關。在某些通訊協定中，系統可能會實作 valid_size 的備用方案，然後才能實作 size。在其他情況下，可以實作直接傳回 size 的備用廣告。在其他情況下，則必須設定這個欄位，否則管道會關閉。

警告：fuchsia.sysmem.Images2 (V1) 不會處理非 0 x, y，因此任何非零 x、y 這裡 (V2) 都不會轉換成 V1。由於 x 的稀有程度不是零，因此實際執行 y 時，即使是已移至 V2 的元件，系統可能仍會假設 x 和 y 為 0，直到有實作和測試處理非零 x、y 的實際原因為止。將非 0 x、y 傳送至下游轉譯和/或顯示管道假設為 0，0 將不正確，但不會顯示當機，因為假設 y 假設 0, 0，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 以外的部分像素。額外像素不會顯示，且不一定包含任何實際圖片資料。一般來說，在這些區域中看起來像真實圖片資料的任何都只是影片壓縮的成果，並且存在巨集區塊的其餘部分，即使不在顯示的區域內，仍可供後續的影格參照，而不是從來源提供的任何其他「實際」像素。此區域中的像素值是由轉碼器解碼程序定義，且必須保留才能正確解碼器作業。一般而言，Valid_size 中的像素位於 display_rect 之外，其大小會等於巨集區塊大小減 1。valid_size 很適合用來測試影片解碼器，以及用於特定轉碼情境。
pixel_aspect_ratio fuchsia.math/SizeU

影片顯示用的長寬比。

如為 YUV 格式，這是指 luma (AKA Y) 樣本的像素顯示比例 (AKA 樣本長寬比，又稱 SAR)。

生產者應在必要時減少比例 (將兩者除以 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 歲