fuchsia.images2

The location of the origin of the rectangle in the x-axis.

The location of the origin of the rectangle in the y-axis.

The distance along the x-axis.

The region includes x values starting at x and increasing along the x-axis.

The distance along the y-axis.

The region includes y values starting at y and increasing along the y-axis.

INVALID

Not a valid color space type.

SRGB

sRGB, gamma transfer function and full range, per spec

REC601_NTSC

601 NTSC ("525 line") YCbCr primaries, limited range

REC601_NTSC_FULL_RANGE

601 NTSC ("525 line") YCbCr primaries, full range

REC601_PAL

601 PAL ("625 line") YCbCr primaries, limited range

REC601_PAL_FULL_RANGE

601 PAL ("625 line") YCbCr primaries, full range

REC709

709 YCbCr (not RGB), limited range

REC2020

2020 YCbCr (not RGB, not YcCbcCrc), 10 or 12 bit according to PixelFormat, with primaries, limited range (not full range), transfer function ("gamma"), etc all per spec, wide color gamut SDR

REC2100

2100 YCbCr (not RGB, not ICtCp), 10 or 12 bit according to PixelFormat, BT.2020 primaries (same wide color gamut as REC2020), limited range (not full range), PQ (aka SMPTE ST 2084) HDR transfer function (not HLG, not SDR "gamma" used by REC2020 and REC709), wide color gamut HDR

PASSTHROUGH

Either the pixel format doesn't represent a color, or it's in an application-specific colorspace that isn't describable by another entry in this enum.

DO_NOT_CARE

A client is explicitly indicating that the client does not care which color space is chosen / used.

INVALID

R8G8B8A8

RGB only, 8 bits per each of R/G/B/A sample

If A is actually X (not set to meaningful values), that can be specified by settting ['fuchsia.sysemm2.ImageFormatConstraints.is_alpha_present'] to false.

If A is known to be set to meaningful values, that can be specified by setting ['fuchsia.sysemm2.ImageFormatConstraints.is_alpha_present'] to true.

Compatible with VK_FORMAT_R8G8B8A8_UNORM.

R8G8B8X8

RGB only, 8 bits per each of R/G/B/X sample

Compatible with VK_FORMAT_R8G8B8A8_UNORM, when treated as opaque.

Deprecated. Use R8G8B8A8 with ['fuchsia.sysemm2.ImageFormatConstraints.is_alpha_present'] set to false instead.

B8G8R8A8

32bpp BGRA, 1 plane. RGB only, 8 bits per each of B/G/R/A sample.

Compatible with VK_FORMAT_B8G8R8A8_UNORM.

If A is actually X (not set to meaningful values), that can be specified by settting ['fuchsia.sysemm2.ImageFormatConstraints.is_alpha_present'] to false.

If A is known to be set to meaningful values, that can be specified by setting ['fuchsia.sysemm2.ImageFormatConstraints.is_alpha_present'] to true.

In sysmem(1), this is BGRA32.

B8G8R8X8

32bpp BGRA, 1 plane. RGB only, 8 bits per each of B/G/R/X sample.

Compatible with VK_FORMAT_B8G8R8A8_UNORM, when treated as opaque.

Deprecated. Use B8G8R8A8 with fuchsia.sysemm2/ImageFormatConstraints.is_alpha_present set to false instead.

I420

YUV only, 8 bits per Y sample

Compatible with VK_FORMAT_G8_B8_R8_3PLANE_420_UNORM.

M420

YUV only, 8 bits per Y sample

Not compatible with any vulkan format.

NV12

YUV only, 8 bits per Y sample

Compatible with VK_FORMAT_G8_B8R8_2PLANE_420_UNORM.

YUY2

YUV only, 8 bits per Y sample

Compatible with VK_FORMAT_G8B8G8R8_422_UNORM.

MJPEG

This value is reserved, and not currently used.

YV12

YUV only, 8 bits per Y sample

Compatible with VK_FORMAT_G8_B8_R8_3PLANE_420_UNORM. The U plane may be located in either the B or R plane for the image (and likewise for the V plane); the ordering may be determined by looking at the members of VkBufferCollectionPropertiesFUCHSIA.samplerYcbcrConversionComponents.

B8G8R8

24bpp BGR, 1 plane. RGB only, 8 bits per each of B/G/R sample

Compatible with VK_FORMAT_B8G8R8_UNORM.

In sysmem(1), this is BGR24.

R5G6B5

16bpp RGB, 1 plane. 5 bits R, 6 bits G, 5 bits B

Compatible with VK_FORMAT_R5G6B5_UNORM_PACK16.

In sysmem(1), this is RGB565.

R3G3B2

8bpp RGB, 1 plane. 3 bits R, 3 bits G, 2 bits B

Not compatible with any vulkan format.

In sysmem(1), this is RGB332.

R2G2B2X2

8bpp RGB, 1 plane. 2 bits R, 2 bits G, 2 bits B

Not compatible with any vulkan format.

If X is actually X (not set to meaningful values), that can be specified by settting ['fuchsia.sysemm2.ImageFormatConstraints.is_alpha_present'] to false.

If X is known to be set to meaningful values, that can be specified by setting ['fuchsia.sysemm2.ImageFormatConstraints.is_alpha_present'] to true.

In sysmem(1), this is RGB2220.

L8

8bpp, Luminance-only (red, green and blue have identical values.)

Compatible with VK_FORMAT_R8_UNORM.

Most clients will prefer to use R8 instead.

R8

8bpp, Red-only (Green and Blue are to be interpreted as 0).

Compatible with VK_FORMAT_R8_UNORM.

R8G8

16bpp RG, 1 plane. 8 bits R, 8 bits G.

Compatible with VK_FORMAT_R8G8_UNORM.

A2R10G10B10

32bpp RGBA, 1 plane. 2 bits A, 10 bits R/G/B.

If A is actually X (not set to meaningful values), that can be specified by settting ['fuchsia.sysemm2.ImageFormatConstraints.is_alpha_present'] to false.

If A is known to be set to meaningful values, that can be specified by setting ['fuchsia.sysemm2.ImageFormatConstraints.is_alpha_present'] to true.

Compatible with VK_FORMAT_A2R10G10B10_UNORM_PACK32.

A2B10G10R10

32bpp BGRA, 1 plane. 2 bits A, 10 bits R/G/B.

If A is actually X (not set to meaningful values), that can be specified by settting ['fuchsia.sysemm2.ImageFormatConstraints.is_alpha_present'] to false.

If A is known to be set to meaningful values, that can be specified by setting ['fuchsia.sysemm2.ImageFormatConstraints.is_alpha_present'] to true.

Compatible with VK_FORMAT_A2B10G10R10_UNORM_PACK32.

P010

YUV only, 16 bits per Y sample

This is like NV12 but with 16 bit samples that have the bottom 6 bits of each sample set to zero and/or ignored. The endianess of each 16 bit sample is host endian-ness (LE on LE system, BE on BE system). The CbCr plane has 16 bit Cb first, then 16 bit Cr, interleaved Cb Cr Cb Cr etc.

Compatible with VK_FORMAT_G10X6_B10X6R10X6_2PLANE_420_UNORM_3PACK16.

R8G8B8

24bpp RGB, 1 plane. RGB only, 8 bits per each of R/G/B sample

Compatible with VK_FORMAT_R8G8B8_UNORM.

DO_NOT_CARE

A client is explicitly indicating that the client does not care which pixel format is chosen / used. When setting this value, the client must not set pixel_format_modifier.

DO_NOT_CARE

INVALID

LINEAR

INTEL_I915_X_TILED

INTEL_I915_Y_TILED

INTEL_I915_YF_TILED

INTEL_I915_Y_TILED_CCS

INTEL_I915_YF_TILED_CCS

ARM_AFBC_16X16

ARM_AFBC_32X8

ARM_LINEAR_TE

ARM_AFBC_16X16_TE

ARM_AFBC_32X8_TE

ARM_AFBC_16X16_YUV_TILED_HEADER

ARM_AFBC_16X16_SPLIT_BLOCK_SPARSE_YUV

ARM_AFBC_16X16_SPLIT_BLOCK_SPARSE_YUV_TE

ARM_AFBC_16X16_SPLIT_BLOCK_SPARSE_YUV_TILED_HEADER

ARM_AFBC_16X16_SPLIT_BLOCK_SPARSE_YUV_TE_TILED_HEADER

GOOGLE_GOLDFISH_OPTIMAL

1

Describes the manner in which pixels are encoded.

2

Vendor-specific pixel format modifier. See format_modifier.fidl.

3

Indicates the color space used to interpret pixel values.

4

The size of the image in pixels.

See also bytes_per_row which is also necessary (along with size) to find where each pixel's data is within a buffer.

Not all of the addressable pixel positions in the buffer are necessarily populated with valid pixel data. See valid_size for the potentially-smaller rectangle of valid pixels.

The right and bottom of the image may have some valid pixels which are not to be displayed. See display_rect.

5

Number of bytes per row. For multi-plane YUV formats, this is the number of bytes per row in the Y plane.

When this field is not set, there is no padding at the end of each row of pixels. In other words, when not set, the stride is equal to the "stride bytes per width pixel" times the size.width.

When set, the value in this field must be >= the "stride bytes per width pixel" times the size.width. If equal, there is no padding at the end of each row of pixels. If greater, the difference is how much padding is at the end of each row of pixels, in bytes.

This is also known as the "stride", "line to line offset", "row to row offset", and other names.

As a specific example, it's not uncommon (but also not always required) for BGR24 (3 bytes per pixel) to have some padding at the end of each row so that each row of pixels starts at a 4 byte aligned offset from the start of the image (the upper left pixel). That padding's size is not necessarily divisible by the size in bytes of a pixel ("stride bytes per width pixel"), so we indicate the padding using this field rather than trying to incorporate the padding as a larger "fake" size.width.

6

The rect within a frame that's for display. This is the location and size in pixels of the rectangle of pixels that should be displayed, when displaying the "whole image" in a UI display sense.

The x + width must be <= size.width, and the y + height must be <= size.height.

For output from a video decoder, pixels outside the display_rect are never to be displayed (outside of test programs), but must be preserved for correct decoder function. The display_rect will always fall within the rect starting at (0, 0) and having valid_size size, when valid_size is set. In other words, display_rect is a subset (not necessarily a proper subset) of valid_size, and valid_size is a subset (not necessarily a proper subset) of size.

Downstream texture filtering operations should avoid letting any pixel outside of display_rect influence the visual appearance of any displayed pixel, to avoid the potential for the right or bottom edge leaking in arbitrary pixels defined by the decode process but not intended for display.

Behavior when this field is not set is protocol-specific. In some protocols, fallback to valid_size, then to size may be implemented. In others, fallback directly to size may be implemented. In others, this field must be set or the channel will close.

WARNING: fuchsia.sysmem.Images2 (V1) doesn't handle non-zero x, y, so any non-zero x, y here (V2) will prevent conversion to V1. Due to the rarity of non-zero x, y in practice, even components that have moved to V2 may in some cases still assume both x and y are 0, until there's a practical reason to implment and test handling of non-zero x, y. The symptom of sending non-zero x, y to a downstream render and/or display pipeline that assumes 0, 0 will be incorrect display, but not a crash, since assuming 0, 0 for x, y does not cause reading out of buffer bounds.

7

The size of a frame in terms of the number of pixels that have valid pixel data in terms of video decoding, but not in terms of which pixels are intended for display.

To convert valid_size into a rect that's directly comparable to display_rect, one can make a rect with (x: 0, y: 0, width: valid_size.width, height: valid_size.height).

In the case of a video decoder, valid_size can include some pixels outside display_rect. The extra pixels are not meant to be displayed, and may or may not contain any real image data. Typically anything that looks like real image data in these regions is only an artifact of video compression and the existence of the remainder of a macroblock which can be referenced by later frames despite not being within the displayed region, and not really any additional "real" pixels from the source. The pixel values in this region are defined by the codec decode process and must be retained for correct decoder operation. Typically the pixels inside valid_size but outside display_rect will be up to the size of a macroblock minus 1. The valid_size is can be useful for testing video decoders and for certain transcoding scenarios.

8

Aspect ratio of a single pixel as the video is intended to be displayed.

For YUV formats, this is the pixel aspect ratio (AKA sample aspect ratio aka SAR) for the luma (AKA Y) samples.

Producers should ensure the width and height values are relatively prime by reducing the fraction (dividing both by GCF) if necessary.

A consumer should interpret this field being un-set as an unknown pixel aspect ratio. A default of 1:1 can be appropriate in some cases, but a consumer may determine the actual pixel aspect ratio by OOB means.

Format has a color control surface after the tile data