diff options
Diffstat (limited to 'include/android/system/core/include/system/graphics.h')
| -rw-r--r-- | include/android/system/core/include/system/graphics.h | 793 |
1 files changed, 149 insertions, 644 deletions
diff --git a/include/android/system/core/include/system/graphics.h b/include/android/system/core/include/system/graphics.h index 909ffe68..6341e642 100644 --- a/include/android/system/core/include/system/graphics.h +++ b/include/android/system/core/include/system/graphics.h @@ -18,12 +18,32 @@ #ifndef SYSTEM_CORE_INCLUDE_ANDROID_GRAPHICS_H #define SYSTEM_CORE_INCLUDE_ANDROID_GRAPHICS_H +#include <stddef.h> #include <stdint.h> +/* + * Some of the enums are now defined in HIDL in hardware/interfaces and are + * generated. + */ +#include "graphics-base.h" +#include "graphics-sw.h" + #ifdef __cplusplus extern "C" { #endif +/* for compatibility */ +#define HAL_PIXEL_FORMAT_YCbCr_420_888 HAL_PIXEL_FORMAT_YCBCR_420_888 +#define HAL_PIXEL_FORMAT_YCbCr_422_SP HAL_PIXEL_FORMAT_YCBCR_422_SP +#define HAL_PIXEL_FORMAT_YCrCb_420_SP HAL_PIXEL_FORMAT_YCRCB_420_SP +#define HAL_PIXEL_FORMAT_YCbCr_422_I HAL_PIXEL_FORMAT_YCBCR_422_I +typedef android_pixel_format_t android_pixel_format; +typedef android_transform_t android_transform; +typedef android_dataspace_t android_dataspace; +typedef android_color_mode_t android_color_mode; +typedef android_color_transform_t android_color_transform; +typedef android_hdr_t android_hdr; + /* * If the HAL needs to create service threads to handle graphics related * tasks, these threads need to run at HAL_PRIORITY_URGENT_DISPLAY priority @@ -38,411 +58,6 @@ extern "C" { #define HAL_PRIORITY_URGENT_DISPLAY (-8) -/** - * pixel format definitions - */ - -enum { - /* - * "linear" color pixel formats: - * - * When used with ANativeWindow, the dataSpace field describes the color - * space of the buffer. - * - * The color space determines, for example, if the formats are linear or - * gamma-corrected; or whether any special operations are performed when - * reading or writing into a buffer in one of these formats. - */ - HAL_PIXEL_FORMAT_RGBA_8888 = 1, - HAL_PIXEL_FORMAT_RGBX_8888 = 2, - HAL_PIXEL_FORMAT_RGB_888 = 3, - HAL_PIXEL_FORMAT_RGB_565 = 4, - HAL_PIXEL_FORMAT_BGRA_8888 = 5, - - /* - * 0x100 - 0x1FF - * - * This range is reserved for pixel formats that are specific to the HAL - * implementation. Implementations can use any value in this range to - * communicate video pixel formats between their HAL modules. These formats - * must not have an alpha channel. Additionally, an EGLimage created from a - * gralloc buffer of one of these formats must be supported for use with the - * GL_OES_EGL_image_external OpenGL ES extension. - */ - - /* - * Android YUV format: - * - * This format is exposed outside of the HAL to software decoders and - * applications. EGLImageKHR must support it in conjunction with the - * OES_EGL_image_external extension. - * - * YV12 is a 4:2:0 YCrCb planar format comprised of a WxH Y plane followed - * by (W/2) x (H/2) Cr and Cb planes. - * - * This format assumes - * - an even width - * - an even height - * - a horizontal stride multiple of 16 pixels - * - a vertical stride equal to the height - * - * y_size = stride * height - * c_stride = ALIGN(stride/2, 16) - * c_size = c_stride * height/2 - * size = y_size + c_size * 2 - * cr_offset = y_size - * cb_offset = y_size + c_size - * - * When used with ANativeWindow, the dataSpace field describes the color - * space of the buffer. - */ - HAL_PIXEL_FORMAT_YV12 = 0x32315659, // YCrCb 4:2:0 Planar - - - /* - * Android Y8 format: - * - * This format is exposed outside of the HAL to the framework. - * The expected gralloc usage flags are SW_* and HW_CAMERA_*, - * and no other HW_ flags will be used. - * - * Y8 is a YUV planar format comprised of a WxH Y plane, - * with each pixel being represented by 8 bits. - * - * It is equivalent to just the Y plane from YV12. - * - * This format assumes - * - an even width - * - an even height - * - a horizontal stride multiple of 16 pixels - * - a vertical stride equal to the height - * - * size = stride * height - * - * When used with ANativeWindow, the dataSpace field describes the color - * space of the buffer. - */ - HAL_PIXEL_FORMAT_Y8 = 0x20203859, - - /* - * Android Y16 format: - * - * This format is exposed outside of the HAL to the framework. - * The expected gralloc usage flags are SW_* and HW_CAMERA_*, - * and no other HW_ flags will be used. - * - * Y16 is a YUV planar format comprised of a WxH Y plane, - * with each pixel being represented by 16 bits. - * - * It is just like Y8, but has double the bits per pixel (little endian). - * - * This format assumes - * - an even width - * - an even height - * - a horizontal stride multiple of 16 pixels - * - a vertical stride equal to the height - * - strides are specified in pixels, not in bytes - * - * size = stride * height * 2 - * - * When used with ANativeWindow, the dataSpace field describes the color - * space of the buffer, except that dataSpace field - * HAL_DATASPACE_DEPTH indicates that this buffer contains a depth - * image where each sample is a distance value measured by a depth camera, - * plus an associated confidence value. - */ - HAL_PIXEL_FORMAT_Y16 = 0x20363159, - - /* - * Android RAW sensor format: - * - * This format is exposed outside of the camera HAL to applications. - * - * RAW16 is a single-channel, 16-bit, little endian format, typically - * representing raw Bayer-pattern images from an image sensor, with minimal - * processing. - * - * The exact pixel layout of the data in the buffer is sensor-dependent, and - * needs to be queried from the camera device. - * - * Generally, not all 16 bits are used; more common values are 10 or 12 - * bits. If not all bits are used, the lower-order bits are filled first. - * All parameters to interpret the raw data (black and white points, - * color space, etc) must be queried from the camera device. - * - * This format assumes - * - an even width - * - an even height - * - a horizontal stride multiple of 16 pixels - * - a vertical stride equal to the height - * - strides are specified in pixels, not in bytes - * - * size = stride * height * 2 - * - * This format must be accepted by the gralloc module when used with the - * following usage flags: - * - GRALLOC_USAGE_HW_CAMERA_* - * - GRALLOC_USAGE_SW_* - * - GRALLOC_USAGE_RENDERSCRIPT - * - * When used with ANativeWindow, the dataSpace should be - * HAL_DATASPACE_ARBITRARY, as raw image sensor buffers require substantial - * extra metadata to define. - */ - HAL_PIXEL_FORMAT_RAW16 = 0x20, - - /* - * Android RAW10 format: - * - * This format is exposed outside of the camera HAL to applications. - * - * RAW10 is a single-channel, 10-bit per pixel, densely packed in each row, - * unprocessed format, usually representing raw Bayer-pattern images coming from - * an image sensor. - * - * In an image buffer with this format, starting from the first pixel of each - * row, each 4 consecutive pixels are packed into 5 bytes (40 bits). Each one - * of the first 4 bytes contains the top 8 bits of each pixel, The fifth byte - * contains the 2 least significant bits of the 4 pixels, the exact layout data - * for each 4 consecutive pixels is illustrated below (Pi[j] stands for the jth - * bit of the ith pixel): - * - * bit 7 bit 0 - * =====|=====|=====|=====|=====|=====|=====|=====| - * Byte 0: |P0[9]|P0[8]|P0[7]|P0[6]|P0[5]|P0[4]|P0[3]|P0[2]| - * |-----|-----|-----|-----|-----|-----|-----|-----| - * Byte 1: |P1[9]|P1[8]|P1[7]|P1[6]|P1[5]|P1[4]|P1[3]|P1[2]| - * |-----|-----|-----|-----|-----|-----|-----|-----| - * Byte 2: |P2[9]|P2[8]|P2[7]|P2[6]|P2[5]|P2[4]|P2[3]|P2[2]| - * |-----|-----|-----|-----|-----|-----|-----|-----| - * Byte 3: |P3[9]|P3[8]|P3[7]|P3[6]|P3[5]|P3[4]|P3[3]|P3[2]| - * |-----|-----|-----|-----|-----|-----|-----|-----| - * Byte 4: |P3[1]|P3[0]|P2[1]|P2[0]|P1[1]|P1[0]|P0[1]|P0[0]| - * =============================================== - * - * This format assumes - * - a width multiple of 4 pixels - * - an even height - * - a vertical stride equal to the height - * - strides are specified in bytes, not in pixels - * - * size = stride * height - * - * When stride is equal to width * (10 / 8), there will be no padding bytes at - * the end of each row, the entire image data is densely packed. When stride is - * larger than width * (10 / 8), padding bytes will be present at the end of each - * row (including the last row). - * - * This format must be accepted by the gralloc module when used with the - * following usage flags: - * - GRALLOC_USAGE_HW_CAMERA_* - * - GRALLOC_USAGE_SW_* - * - GRALLOC_USAGE_RENDERSCRIPT - * - * When used with ANativeWindow, the dataSpace field should be - * HAL_DATASPACE_ARBITRARY, as raw image sensor buffers require substantial - * extra metadata to define. - */ - HAL_PIXEL_FORMAT_RAW10 = 0x25, - - /* - * Android RAW12 format: - * - * This format is exposed outside of camera HAL to applications. - * - * RAW12 is a single-channel, 12-bit per pixel, densely packed in each row, - * unprocessed format, usually representing raw Bayer-pattern images coming from - * an image sensor. - * - * In an image buffer with this format, starting from the first pixel of each - * row, each two consecutive pixels are packed into 3 bytes (24 bits). The first - * and second byte contains the top 8 bits of first and second pixel. The third - * byte contains the 4 least significant bits of the two pixels, the exact layout - * data for each two consecutive pixels is illustrated below (Pi[j] stands for - * the jth bit of the ith pixel): - * - * bit 7 bit 0 - * ======|======|======|======|======|======|======|======| - * Byte 0: |P0[11]|P0[10]|P0[ 9]|P0[ 8]|P0[ 7]|P0[ 6]|P0[ 5]|P0[ 4]| - * |------|------|------|------|------|------|------|------| - * Byte 1: |P1[11]|P1[10]|P1[ 9]|P1[ 8]|P1[ 7]|P1[ 6]|P1[ 5]|P1[ 4]| - * |------|------|------|------|------|------|------|------| - * Byte 2: |P1[ 3]|P1[ 2]|P1[ 1]|P1[ 0]|P0[ 3]|P0[ 2]|P0[ 1]|P0[ 0]| - * ======================================================= - * - * This format assumes: - * - a width multiple of 4 pixels - * - an even height - * - a vertical stride equal to the height - * - strides are specified in bytes, not in pixels - * - * size = stride * height - * - * When stride is equal to width * (12 / 8), there will be no padding bytes at - * the end of each row, the entire image data is densely packed. When stride is - * larger than width * (12 / 8), padding bytes will be present at the end of - * each row (including the last row). - * - * This format must be accepted by the gralloc module when used with the - * following usage flags: - * - GRALLOC_USAGE_HW_CAMERA_* - * - GRALLOC_USAGE_SW_* - * - GRALLOC_USAGE_RENDERSCRIPT - * - * When used with ANativeWindow, the dataSpace field should be - * HAL_DATASPACE_ARBITRARY, as raw image sensor buffers require substantial - * extra metadata to define. - */ - HAL_PIXEL_FORMAT_RAW12 = 0x26, - - /* - * Android opaque RAW format: - * - * This format is exposed outside of the camera HAL to applications. - * - * RAW_OPAQUE is a format for unprocessed raw image buffers coming from an - * image sensor. The actual structure of buffers of this format is - * implementation-dependent. - * - * This format must be accepted by the gralloc module when used with the - * following usage flags: - * - GRALLOC_USAGE_HW_CAMERA_* - * - GRALLOC_USAGE_SW_* - * - GRALLOC_USAGE_RENDERSCRIPT - * - * When used with ANativeWindow, the dataSpace field should be - * HAL_DATASPACE_ARBITRARY, as raw image sensor buffers require substantial - * extra metadata to define. - */ - HAL_PIXEL_FORMAT_RAW_OPAQUE = 0x24, - - /* - * Android binary blob graphics buffer format: - * - * This format is used to carry task-specific data which does not have a - * standard image structure. The details of the format are left to the two - * endpoints. - * - * A typical use case is for transporting JPEG-compressed images from the - * Camera HAL to the framework or to applications. - * - * Buffers of this format must have a height of 1, and width equal to their - * size in bytes. - * - * When used with ANativeWindow, the mapping of the dataSpace field to - * buffer contents for BLOB is as follows: - * - * dataSpace value | Buffer contents - * -------------------------------+----------------------------------------- - * HAL_DATASPACE_JFIF | An encoded JPEG image - * HAL_DATASPACE_DEPTH | An android_depth_points buffer - * Other | Unsupported - * - */ - HAL_PIXEL_FORMAT_BLOB = 0x21, - - /* - * Android format indicating that the choice of format is entirely up to the - * device-specific Gralloc implementation. - * - * The Gralloc implementation should examine the usage bits passed in when - * allocating a buffer with this format, and it should derive the pixel - * format from those usage flags. This format will never be used with any - * of the GRALLOC_USAGE_SW_* usage flags. - * - * If a buffer of this format is to be used as an OpenGL ES texture, the - * framework will assume that sampling the texture will always return an - * alpha value of 1.0 (i.e. the buffer contains only opaque pixel values). - * - * When used with ANativeWindow, the dataSpace field describes the color - * space of the buffer. - */ - HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED = 0x22, - - /* - * Android flexible YCbCr 4:2:0 formats - * - * This format allows platforms to use an efficient YCbCr/YCrCb 4:2:0 - * buffer layout, while still describing the general format in a - * layout-independent manner. While called YCbCr, it can be - * used to describe formats with either chromatic ordering, as well as - * whole planar or semiplanar layouts. - * - * struct android_ycbcr (below) is the the struct used to describe it. - * - * This format must be accepted by the gralloc module when - * USAGE_SW_WRITE_* or USAGE_SW_READ_* are set. - * - * This format is locked for use by gralloc's (*lock_ycbcr) method, and - * locking with the (*lock) method will return an error. - * - * When used with ANativeWindow, the dataSpace field describes the color - * space of the buffer. - */ - HAL_PIXEL_FORMAT_YCbCr_420_888 = 0x23, - - /* - * Android flexible YCbCr 4:2:2 formats - * - * This format allows platforms to use an efficient YCbCr/YCrCb 4:2:2 - * buffer layout, while still describing the general format in a - * layout-independent manner. While called YCbCr, it can be - * used to describe formats with either chromatic ordering, as well as - * whole planar or semiplanar layouts. - * - * This format is currently only used by SW readable buffers - * produced by MediaCodecs, so the gralloc module can ignore this format. - */ - HAL_PIXEL_FORMAT_YCbCr_422_888 = 0x27, - - /* - * Android flexible YCbCr 4:4:4 formats - * - * This format allows platforms to use an efficient YCbCr/YCrCb 4:4:4 - * buffer layout, while still describing the general format in a - * layout-independent manner. While called YCbCr, it can be - * used to describe formats with either chromatic ordering, as well as - * whole planar or semiplanar layouts. - * - * This format is currently only used by SW readable buffers - * produced by MediaCodecs, so the gralloc module can ignore this format. - */ - HAL_PIXEL_FORMAT_YCbCr_444_888 = 0x28, - - /* - * Android flexible RGB 888 formats - * - * This format allows platforms to use an efficient RGB/BGR/RGBX/BGRX - * buffer layout, while still describing the general format in a - * layout-independent manner. While called RGB, it can be - * used to describe formats with either color ordering and optional - * padding, as well as whole planar layout. - * - * This format is currently only used by SW readable buffers - * produced by MediaCodecs, so the gralloc module can ignore this format. - */ - HAL_PIXEL_FORMAT_FLEX_RGB_888 = 0x29, - - /* - * Android flexible RGBA 8888 formats - * - * This format allows platforms to use an efficient RGBA/BGRA/ARGB/ABGR - * buffer layout, while still describing the general format in a - * layout-independent manner. While called RGBA, it can be - * used to describe formats with any of the component orderings, as - * well as whole planar layout. - * - * This format is currently only used by SW readable buffers - * produced by MediaCodecs, so the gralloc module can ignore this format. - */ - HAL_PIXEL_FORMAT_FLEX_RGBA_8888 = 0x2A, - - /* Legacy formats (deprecated), used by ImageFormat.java */ - HAL_PIXEL_FORMAT_YCbCr_422_SP = 0x10, // NV16 - HAL_PIXEL_FORMAT_YCrCb_420_SP = 0x11, // NV21 - HAL_PIXEL_FORMAT_YCbCr_422_I = 0x14, // YUY2 -}; - /* * Structure for describing YCbCr formats for consumption by applications. * This is used with HAL_PIXEL_FORMAT_YCbCr_*_888. @@ -452,15 +67,15 @@ enum { * * Buffers must have a 8 bit depth. * - * @y, @cb, and @cr point to the first byte of their respective planes. + * y, cb, and cr point to the first byte of their respective planes. * * Stride describes the distance in bytes from the first value of one row of * the image to the first value of the next row. It includes the width of the * image plus padding. - * @ystride is the stride of the luma plane. - * @cstride is the stride of the chroma planes. + * ystride is the stride of the luma plane. + * cstride is the stride of the chroma planes. * - * @chroma_step is the distance in bytes from one chroma pixel value to the + * chroma_step is the distance in bytes from one chroma pixel value to the * next. This is 2 bytes for semiplanar (because chroma values are interleaved * and each chroma value is one byte) and 1 for planar. */ @@ -477,6 +92,102 @@ struct android_ycbcr { uint32_t reserved[8]; }; +/* + * Structures for describing flexible YUVA/RGBA formats for consumption by + * applications. Such flexible formats contain a plane for each component (e.g. + * red, green, blue), where each plane is laid out in a grid-like pattern + * occupying unique byte addresses and with consistent byte offsets between + * neighboring pixels. + * + * The android_flex_layout structure is used with any pixel format that can be + * represented by it, such as: + * - HAL_PIXEL_FORMAT_YCbCr_*_888 + * - HAL_PIXEL_FORMAT_FLEX_RGB*_888 + * - HAL_PIXEL_FORMAT_RGB[AX]_888[8],BGRA_8888,RGB_888 + * - HAL_PIXEL_FORMAT_YV12,Y8,Y16,YCbCr_422_SP/I,YCrCb_420_SP + * - even implementation defined formats that can be represented by + * the structures + * + * Vertical increment (aka. row increment or stride) describes the distance in + * bytes from the first pixel of one row to the first pixel of the next row + * (below) for the component plane. This can be negative. + * + * Horizontal increment (aka. column or pixel increment) describes the distance + * in bytes from one pixel to the next pixel (to the right) on the same row for + * the component plane. This can be negative. + * + * Each plane can be subsampled either vertically or horizontally by + * a power-of-two factor. + * + * The bit-depth of each component can be arbitrary, as long as the pixels are + * laid out on whole bytes, in native byte-order, using the most significant + * bits of each unit. + */ + +typedef enum android_flex_component { + /* luma */ + FLEX_COMPONENT_Y = 1 << 0, + /* chroma blue */ + FLEX_COMPONENT_Cb = 1 << 1, + /* chroma red */ + FLEX_COMPONENT_Cr = 1 << 2, + + /* red */ + FLEX_COMPONENT_R = 1 << 10, + /* green */ + FLEX_COMPONENT_G = 1 << 11, + /* blue */ + FLEX_COMPONENT_B = 1 << 12, + + /* alpha */ + FLEX_COMPONENT_A = 1 << 30, +} android_flex_component_t; + +typedef struct android_flex_plane { + /* pointer to the first byte of the top-left pixel of the plane. */ + uint8_t *top_left; + + android_flex_component_t component; + + /* bits allocated for the component in each pixel. Must be a positive + multiple of 8. */ + int32_t bits_per_component; + /* number of the most significant bits used in the format for this + component. Must be between 1 and bits_per_component, inclusive. */ + int32_t bits_used; + + /* horizontal increment */ + int32_t h_increment; + /* vertical increment */ + int32_t v_increment; + /* horizontal subsampling. Must be a positive power of 2. */ + int32_t h_subsampling; + /* vertical subsampling. Must be a positive power of 2. */ + int32_t v_subsampling; +} android_flex_plane_t; + +typedef enum android_flex_format { + /* not a flexible format */ + FLEX_FORMAT_INVALID = 0x0, + FLEX_FORMAT_Y = FLEX_COMPONENT_Y, + FLEX_FORMAT_YCbCr = FLEX_COMPONENT_Y | FLEX_COMPONENT_Cb | FLEX_COMPONENT_Cr, + FLEX_FORMAT_YCbCrA = FLEX_FORMAT_YCbCr | FLEX_COMPONENT_A, + FLEX_FORMAT_RGB = FLEX_COMPONENT_R | FLEX_COMPONENT_G | FLEX_COMPONENT_B, + FLEX_FORMAT_RGBA = FLEX_FORMAT_RGB | FLEX_COMPONENT_A, +} android_flex_format_t; + +typedef struct android_flex_layout { + /* the kind of flexible format */ + android_flex_format_t format; + + /* number of planes; 0 for FLEX_FORMAT_INVALID */ + uint32_t num_planes; + /* a plane for each component; ordered in increasing component value order. + E.g. FLEX_FORMAT_RGBA maps 0 -> R, 1 -> G, etc. + Can be NULL for FLEX_FORMAT_INVALID */ + android_flex_plane_t *planes; +} android_flex_layout_t; + /** * Structure used to define depth point clouds for format HAL_PIXEL_FORMAT_BLOB * with dataSpace value of HAL_DATASPACE_DEPTH. @@ -489,9 +200,9 @@ struct android_ycbcr { * measurement is correct. It is between 0.f and 1.f, inclusive, with 1.f == * 100% confidence. * - * @num_points is the number of points in the list + * num_points is the number of points in the list * - * @xyz_points is the flexible array of floating-point values. + * xyz_points is the flexible array of floating-point values. * It contains (num_points) * 4 floats. * * For example: @@ -516,246 +227,40 @@ struct android_depth_points { /** reserved for future use, set to 0 by gralloc's (*lock)() */ uint32_t reserved[8]; +#if defined(__clang__) +#pragma clang diagnostic push +#pragma clang diagnostic ignored "-Wc99-extensions" +#endif float xyzc_points[]; +#if defined(__clang__) +#pragma clang diagnostic pop +#endif }; /** - * Transformation definitions - * - * IMPORTANT NOTE: - * HAL_TRANSFORM_ROT_90 is applied CLOCKWISE and AFTER HAL_TRANSFORM_FLIP_{H|V}. - * - */ - -enum { - /* flip source image horizontally (around the vertical axis) */ - HAL_TRANSFORM_FLIP_H = 0x01, - /* flip source image vertically (around the horizontal axis)*/ - HAL_TRANSFORM_FLIP_V = 0x02, - /* rotate source image 90 degrees clockwise */ - HAL_TRANSFORM_ROT_90 = 0x04, - /* rotate source image 180 degrees */ - HAL_TRANSFORM_ROT_180 = 0x03, - /* rotate source image 270 degrees clockwise */ - HAL_TRANSFORM_ROT_270 = 0x07, - /* don't use. see system/window.h */ - HAL_TRANSFORM_RESERVED = 0x08, + * These structures are used to define the reference display's + * capabilities for HDR content. Display engine can use this + * to better tone map content to user's display. + * Color is defined in CIE XYZ coordinates + */ +struct android_xy_color { + float x; + float y; }; -/** - * Dataspace Definitions - * ====================== - * - * Dataspace is the definition of how pixel values should be interpreted. - * - * For many formats, this is the colorspace of the image data, which includes - * primaries (including white point) and the transfer characteristic function, - * which describes both gamma curve and numeric range (within the bit depth). - * - * Other dataspaces include depth measurement data from a depth camera. - */ - -typedef enum android_dataspace { - /* - * Default-assumption data space, when not explicitly specified. - * - * It is safest to assume the buffer is an image with sRGB primaries and - * encoding ranges, but the consumer and/or the producer of the data may - * simply be using defaults. No automatic gamma transform should be - * expected, except for a possible display gamma transform when drawn to a - * screen. - */ - HAL_DATASPACE_UNKNOWN = 0x0, - - /* - * Arbitrary dataspace with manually defined characteristics. Definition - * for colorspaces or other meaning must be communicated separately. - * - * This is used when specifying primaries, transfer characteristics, - * etc. separately. - * - * A typical use case is in video encoding parameters (e.g. for H.264), - * where a colorspace can have separately defined primaries, transfer - * characteristics, etc. - */ - HAL_DATASPACE_ARBITRARY = 0x1, - - /* - * RGB Colorspaces - * ----------------- - * - * Primaries are given using (x,y) coordinates in the CIE 1931 definition - * of x and y specified by ISO 11664-1. - * - * Transfer characteristics are the opto-electronic transfer characteristic - * at the source as a function of linear optical intensity (luminance). - */ - - /* - * sRGB linear encoding: - * - * The red, green, and blue components are stored in sRGB space, but - * are linear, not gamma-encoded. - * The RGB primaries and the white point are the same as BT.709. - * - * The values are encoded using the full range ([0,255] for 8-bit) for all - * components. - */ - HAL_DATASPACE_SRGB_LINEAR = 0x200, - - /* - * sRGB gamma encoding: - * - * The red, green and blue components are stored in sRGB space, and - * converted to linear space when read, using the standard sRGB to linear - * equation: - * - * Clinear = Csrgb / 12.92 for Csrgb <= 0.04045 - * = (Csrgb + 0.055 / 1.055)^2.4 for Csrgb > 0.04045 - * - * When written the inverse transformation is performed: - * - * Csrgb = 12.92 * Clinear for Clinear <= 0.0031308 - * = 1.055 * Clinear^(1/2.4) - 0.055 for Clinear > 0.0031308 - * - * - * The alpha component, if present, is always stored in linear space and - * is left unmodified when read or written. - * - * The RGB primaries and the white point are the same as BT.709. - * - * The values are encoded using the full range ([0,255] for 8-bit) for all - * components. - * - */ - HAL_DATASPACE_SRGB = 0x201, - - /* - * YCbCr Colorspaces - * ----------------- - * - * Primaries are given using (x,y) coordinates in the CIE 1931 definition - * of x and y specified by ISO 11664-1. - * - * Transfer characteristics are the opto-electronic transfer characteristic - * at the source as a function of linear optical intensity (luminance). - */ - - /* - * JPEG File Interchange Format (JFIF) - * - * Same model as BT.601-625, but all values (Y, Cb, Cr) range from 0 to 255 - * - * Transfer characteristic curve: - * E = 1.099 * L ^ 0.45 - 0.099, 1.00 >= L >= 0.018 - * E = 4.500 L, 0.018 > L >= 0 - * L - luminance of image 0 <= L <= 1 for conventional colorimetry - * E - corresponding electrical signal - * - * Primaries: x y - * green 0.290 0.600 - * blue 0.150 0.060 - * red 0.640 0.330 - * white (D65) 0.3127 0.3290 - */ - HAL_DATASPACE_JFIF = 0x101, - - /* - * ITU-R Recommendation 601 (BT.601) - 625-line - * - * Standard-definition television, 625 Lines (PAL) - * - * For 8-bit-depth formats: - * Luma (Y) samples should range from 16 to 235, inclusive - * Chroma (Cb, Cr) samples should range from 16 to 240, inclusive - * - * For 10-bit-depth formats: - * Luma (Y) samples should range from 64 to 940, inclusive - * Chroma (Cb, Cr) samples should range from 64 to 960, inclusive - * - * Transfer characteristic curve: - * E = 1.099 * L ^ 0.45 - 0.099, 1.00 >= L >= 0.018 - * E = 4.500 L, 0.018 > L >= 0 - * L - luminance of image 0 <= L <= 1 for conventional colorimetry - * E - corresponding electrical signal - * - * Primaries: x y - * green 0.290 0.600 - * blue 0.150 0.060 - * red 0.640 0.330 - * white (D65) 0.3127 0.3290 - */ - HAL_DATASPACE_BT601_625 = 0x102, - - /* - * ITU-R Recommendation 601 (BT.601) - 525-line - * - * Standard-definition television, 525 Lines (NTSC) - * - * For 8-bit-depth formats: - * Luma (Y) samples should range from 16 to 235, inclusive - * Chroma (Cb, Cr) samples should range from 16 to 240, inclusive - * - * For 10-bit-depth formats: - * Luma (Y) samples should range from 64 to 940, inclusive - * Chroma (Cb, Cr) samples should range from 64 to 960, inclusive - * - * Transfer characteristic curve: - * E = 1.099 * L ^ 0.45 - 0.099, 1.00 >= L >= 0.018 - * E = 4.500 L, 0.018 > L >= 0 - * L - luminance of image 0 <= L <= 1 for conventional colorimetry - * E - corresponding electrical signal - * - * Primaries: x y - * green 0.310 0.595 - * blue 0.155 0.070 - * red 0.630 0.340 - * white (D65) 0.3127 0.3290 - */ - HAL_DATASPACE_BT601_525 = 0x103, - - /* - * ITU-R Recommendation 709 (BT.709) - * - * High-definition television - * - * For 8-bit-depth formats: - * Luma (Y) samples should range from 16 to 235, inclusive - * Chroma (Cb, Cr) samples should range from 16 to 240, inclusive - * - * For 10-bit-depth formats: - * Luma (Y) samples should range from 64 to 940, inclusive - * Chroma (Cb, Cr) samples should range from 64 to 960, inclusive - * - * Primaries: x y - * green 0.300 0.600 - * blue 0.150 0.060 - * red 0.640 0.330 - * white (D65) 0.3127 0.3290 - */ - HAL_DATASPACE_BT709 = 0x104, - - /* - * The buffer contains depth ranging measurements from a depth camera. - * This value is valid with formats: - * HAL_PIXEL_FORMAT_Y16: 16-bit samples, consisting of a depth measurement - * and an associated confidence value. The 3 MSBs of the sample make - * up the confidence value, and the low 13 LSBs of the sample make up - * the depth measurement. - * For the confidence section, 0 means 100% confidence, 1 means 0% - * confidence. The mapping to a linear float confidence value between - * 0.f and 1.f can be obtained with - * float confidence = (((depthSample >> 13) - 1) & 0x7) / 7.0f; - * The depth measurement can be extracted simply with - * uint16_t range = (depthSample & 0x1FFF); - * HAL_PIXEL_FORMAT_BLOB: A depth point cloud, as - * a variable-length float (x,y,z, confidence) coordinate point list. - * The point cloud will be represented with the android_depth_points - * structure. - */ - HAL_DATASPACE_DEPTH = 0x1000 +struct android_smpte2086_metadata { + struct android_xy_color displayPrimaryRed; + struct android_xy_color displayPrimaryGreen; + struct android_xy_color displayPrimaryBlue; + struct android_xy_color whitePoint; + float maxLuminance; + float minLuminance; +}; -} android_dataspace_t; +struct android_cta861_3_metadata { + float maxContentLightLevel; + float maxFrameAverageLightLevel; +}; #ifdef __cplusplus } |