| /* |
| * Copyright (C) 2011 The Android Open Source Project |
| * |
| * Licensed under the Apache License, Version 2.0 (the "License"); |
| * you may not use this file except in compliance with the License. |
| * You may obtain a copy of the License at |
| * |
| * http://www.apache.org/licenses/LICENSE-2.0 |
| * |
| * Unless required by applicable law or agreed to in writing, software |
| * distributed under the License is distributed on an "AS IS" BASIS, |
| * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. |
| * See the License for the specific language governing permissions and |
| * limitations under the License. |
| */ |
| |
| #ifndef SYSTEM_CORE_INCLUDE_ANDROID_GRAPHICS_H |
| #define SYSTEM_CORE_INCLUDE_ANDROID_GRAPHICS_H |
| |
| #include <stddef.h> |
| #include <stdint.h> |
| |
| #ifdef __cplusplus |
| extern "C" { |
| #endif |
| |
| /* |
| * If the HAL needs to create service threads to handle graphics related |
| * tasks, these threads need to run at HAL_PRIORITY_URGENT_DISPLAY priority |
| * if they can block the main rendering thread in any way. |
| * |
| * the priority of the current thread can be set with: |
| * |
| * #include <sys/resource.h> |
| * setpriority(PRIO_PROCESS, 0, HAL_PRIORITY_URGENT_DISPLAY); |
| * |
| */ |
| |
| #define HAL_PRIORITY_URGENT_DISPLAY (-8) |
| |
| /** |
| * pixel format definitions |
| */ |
| |
| typedef enum android_pixel_format { |
| /* |
| * "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 |
| } android_pixel_format_t; |
| |
| /* |
| * Structure for describing YCbCr formats for consumption by applications. |
| * This is used with HAL_PIXEL_FORMAT_YCbCr_*_888. |
| * |
| * Buffer chroma subsampling is defined in the format. |
| * e.g. HAL_PIXEL_FORMAT_YCbCr_420_888 has subsampling 4:2:0. |
| * |
| * Buffers must have a 8 bit depth. |
| * |
| * @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. |
| * |
| * @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. |
| */ |
| |
| struct android_ycbcr { |
| void *y; |
| void *cb; |
| void *cr; |
| size_t ystride; |
| size_t cstride; |
| size_t chroma_step; |
| |
| /** reserved for future use, set to 0 by gralloc's (*lock_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. |
| * When locking a native buffer of the above format and dataSpace value, |
| * the vaddr pointer can be cast to this structure. |
| * |
| * A variable-length list of (x,y,z, confidence) 3D points, as floats. (x, y, |
| * z) represents a measured point's position, with the coordinate system defined |
| * by the data source. Confidence represents the estimated likelihood that this |
| * 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 |
| * |
| * @xyz_points is the flexible array of floating-point values. |
| * It contains (num_points) * 4 floats. |
| * |
| * For example: |
| * android_depth_points d = get_depth_buffer(); |
| * struct { |
| * float x; float y; float z; float confidence; |
| * } firstPoint, lastPoint; |
| * |
| * firstPoint.x = d.xyzc_points[0]; |
| * firstPoint.y = d.xyzc_points[1]; |
| * firstPoint.z = d.xyzc_points[2]; |
| * firstPoint.confidence = d.xyzc_points[3]; |
| * lastPoint.x = d.xyzc_points[(d.num_points - 1) * 4 + 0]; |
| * lastPoint.y = d.xyzc_points[(d.num_points - 1) * 4 + 1]; |
| * lastPoint.z = d.xyzc_points[(d.num_points - 1) * 4 + 2]; |
| * lastPoint.confidence = d.xyzc_points[(d.num_points - 1) * 4 + 3]; |
| */ |
| |
| struct android_depth_points { |
| uint32_t num_points; |
| |
| /** reserved for future use, set to 0 by gralloc's (*lock)() */ |
| uint32_t reserved[8]; |
| |
| float xyzc_points[]; |
| }; |
| |
| /** |
| * Transformation definitions |
| * |
| * IMPORTANT NOTE: |
| * HAL_TRANSFORM_ROT_90 is applied CLOCKWISE and AFTER HAL_TRANSFORM_FLIP_{H|V}. |
| * |
| */ |
| |
| typedef enum android_transform { |
| /* 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, |
| } android_transform_t; |
| |
| /** |
| * 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. |
| * |
| * A dataspace is comprised of a number of fields. |
| * |
| * Version |
| * -------- |
| * The top 2 bits represent the revision of the field specification. This is |
| * currently always 0. |
| * |
| * |
| * bits 31-30 29 - 0 |
| * +-----+----------------------------------------------------+ |
| * fields | Rev | Revision specific fields | |
| * +-----+----------------------------------------------------+ |
| * |
| * Field layout for version = 0: |
| * ---------------------------- |
| * |
| * A dataspace is comprised of the following fields: |
| * Standard |
| * Transfer function |
| * Range |
| * |
| * bits 31-30 29-27 26 - 22 21 - 16 15 - 0 |
| * +-----+-----+--------+--------+----------------------------+ |
| * fields | 0 |Range|Transfer|Standard| Legacy and custom | |
| * +-----+-----+--------+--------+----------------------------+ |
| * VV RRR TTTTT SSSSSS LLLLLLLL LLLLLLLL |
| * |
| * If range, transfer and standard fields are all 0 (e.g. top 16 bits are |
| * all zeroes), the bottom 16 bits contain either a legacy dataspace value, |
| * or a custom value. |
| */ |
| |
| 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, |
| |
| /* |
| * Color-description aspects |
| * |
| * The following aspects define various characteristics of the color |
| * specification. These represent bitfields, so that a data space value |
| * can specify each of them independently. |
| */ |
| |
| HAL_DATASPACE_STANDARD_SHIFT = 16, |
| |
| /* |
| * Standard aspect |
| * |
| * Defines the chromaticity coordinates of the source primaries in terms of |
| * the CIE 1931 definition of x and y specified in ISO 11664-1. |
| */ |
| HAL_DATASPACE_STANDARD_MASK = 63 << HAL_DATASPACE_STANDARD_SHIFT, // 0x3F |
| |
| /* |
| * Chromacity coordinates are unknown or are determined by the application. |
| * Implementations shall use the following suggested standards: |
| * |
| * All YCbCr formats: BT709 if size is 720p or larger (since most video |
| * content is letterboxed this corresponds to width is |
| * 1280 or greater, or height is 720 or greater). |
| * BT601_625 if size is smaller than 720p or is JPEG. |
| * All RGB formats: BT709. |
| * |
| * For all other formats standard is undefined, and implementations should use |
| * an appropriate standard for the data represented. |
| */ |
| HAL_DATASPACE_STANDARD_UNSPECIFIED = 0 << HAL_DATASPACE_STANDARD_SHIFT, |
| |
| /* |
| * Primaries: x y |
| * green 0.300 0.600 |
| * blue 0.150 0.060 |
| * red 0.640 0.330 |
| * white (D65) 0.3127 0.3290 |
| * |
| * Use the unadjusted KR = 0.2126, KB = 0.0722 luminance interpretation |
| * for RGB conversion. |
| */ |
| HAL_DATASPACE_STANDARD_BT709 = 1 << HAL_DATASPACE_STANDARD_SHIFT, |
| |
| /* |
| * Primaries: x y |
| * green 0.290 0.600 |
| * blue 0.150 0.060 |
| * red 0.640 0.330 |
| * white (D65) 0.3127 0.3290 |
| * |
| * KR = 0.299, KB = 0.114. This adjusts the luminance interpretation |
| * for RGB conversion from the one purely determined by the primaries |
| * to minimize the color shift into RGB space that uses BT.709 |
| * primaries. |
| */ |
| HAL_DATASPACE_STANDARD_BT601_625 = 2 << HAL_DATASPACE_STANDARD_SHIFT, |
| |
| /* |
| * Primaries: x y |
| * green 0.290 0.600 |
| * blue 0.150 0.060 |
| * red 0.640 0.330 |
| * white (D65) 0.3127 0.3290 |
| * |
| * Use the unadjusted KR = 0.222, KB = 0.071 luminance interpretation |
| * for RGB conversion. |
| */ |
| HAL_DATASPACE_STANDARD_BT601_625_UNADJUSTED = 3 << HAL_DATASPACE_STANDARD_SHIFT, |
| |
| /* |
| * Primaries: x y |
| * green 0.310 0.595 |
| * blue 0.155 0.070 |
| * red 0.630 0.340 |
| * white (D65) 0.3127 0.3290 |
| * |
| * KR = 0.299, KB = 0.114. This adjusts the luminance interpretation |
| * for RGB conversion from the one purely determined by the primaries |
| * to minimize the color shift into RGB space that uses BT.709 |
| * primaries. |
| */ |
| HAL_DATASPACE_STANDARD_BT601_525 = 4 << HAL_DATASPACE_STANDARD_SHIFT, |
| |
| /* |
| * Primaries: x y |
| * green 0.310 0.595 |
| * blue 0.155 0.070 |
| * red 0.630 0.340 |
| * white (D65) 0.3127 0.3290 |
| * |
| * Use the unadjusted KR = 0.212, KB = 0.087 luminance interpretation |
| * for RGB conversion (as in SMPTE 240M). |
| */ |
| HAL_DATASPACE_STANDARD_BT601_525_UNADJUSTED = 5 << HAL_DATASPACE_STANDARD_SHIFT, |
| |
| /* |
| * Primaries: x y |
| * green 0.170 0.797 |
| * blue 0.131 0.046 |
| * red 0.708 0.292 |
| * white (D65) 0.3127 0.3290 |
| * |
| * Use the unadjusted KR = 0.2627, KB = 0.0593 luminance interpretation |
| * for RGB conversion. |
| */ |
| HAL_DATASPACE_STANDARD_BT2020 = 6 << HAL_DATASPACE_STANDARD_SHIFT, |
| |
| /* |
| * Primaries: x y |
| * green 0.170 0.797 |
| * blue 0.131 0.046 |
| * red 0.708 0.292 |
| * white (D65) 0.3127 0.3290 |
| * |
| * Use the unadjusted KR = 0.2627, KB = 0.0593 luminance interpretation |
| * for RGB conversion using the linear domain. |
| */ |
| HAL_DATASPACE_STANDARD_BT2020_CONSTANT_LUMINANCE = 7 << HAL_DATASPACE_STANDARD_SHIFT, |
| |
| /* |
| * Primaries: x y |
| * green 0.21 0.71 |
| * blue 0.14 0.08 |
| * red 0.67 0.33 |
| * white (C) 0.310 0.316 |
| * |
| * Use the unadjusted KR = 0.30, KB = 0.11 luminance interpretation |
| * for RGB conversion. |
| */ |
| HAL_DATASPACE_STANDARD_BT470M = 8 << HAL_DATASPACE_STANDARD_SHIFT, |
| |
| /* |
| * Primaries: x y |
| * green 0.243 0.692 |
| * blue 0.145 0.049 |
| * red 0.681 0.319 |
| * white (C) 0.310 0.316 |
| * |
| * Use the unadjusted KR = 0.254, KB = 0.068 luminance interpretation |
| * for RGB conversion. |
| */ |
| HAL_DATASPACE_STANDARD_FILM = 9 << HAL_DATASPACE_STANDARD_SHIFT, |
| |
| HAL_DATASPACE_TRANSFER_SHIFT = 22, |
| |
| /* |
| * Transfer aspect |
| * |
| * Transfer characteristics are the opto-electronic transfer characteristic |
| * at the source as a function of linear optical intensity (luminance). |
| * |
| * For digital signals, E corresponds to the recorded value. Normally, the |
| * transfer function is applied in RGB space to each of the R, G and B |
| * components independently. This may result in color shift that can be |
| * minized by applying the transfer function in Lab space only for the L |
| * component. Implementation may apply the transfer function in RGB space |
| * for all pixel formats if desired. |
| */ |
| |
| HAL_DATASPACE_TRANSFER_MASK = 31 << HAL_DATASPACE_TRANSFER_SHIFT, // 0x1F |
| |
| /* |
| * Transfer characteristics are unknown or are determined by the |
| * application. |
| * |
| * Implementations should use the following transfer functions: |
| * |
| * For YCbCr formats: use HAL_DATASPACE_TRANSFER_SMPTE_170M |
| * For RGB formats: use HAL_DATASPACE_TRANSFER_SRGB |
| * |
| * For all other formats transfer function is undefined, and implementations |
| * should use an appropriate standard for the data represented. |
| */ |
| HAL_DATASPACE_TRANSFER_UNSPECIFIED = 0 << HAL_DATASPACE_TRANSFER_SHIFT, |
| |
| /* |
| * Transfer characteristic curve: |
| * E = L |
| * L - luminance of image 0 <= L <= 1 for conventional colorimetry |
| * E - corresponding electrical signal |
| */ |
| HAL_DATASPACE_TRANSFER_LINEAR = 1 << HAL_DATASPACE_TRANSFER_SHIFT, |
| |
| /* |
| * Transfer characteristic curve: |
| * |
| * E = 1.055 * L^(1/2.4) - 0.055 for 0.0031308 <= L <= 1 |
| * = 12.92 * L for 0 <= L < 0.0031308 |
| * L - luminance of image 0 <= L <= 1 for conventional colorimetry |
| * E - corresponding electrical signal |
| */ |
| HAL_DATASPACE_TRANSFER_SRGB = 2 << HAL_DATASPACE_TRANSFER_SHIFT, |
| |
| /* |
| * BT.601 525, BT.601 625, BT.709, BT.2020 |
| * |
| * Transfer characteristic curve: |
| * E = 1.099 * L ^ 0.45 - 0.099 for 0.018 <= L <= 1 |
| * = 4.500 * L for 0 <= L < 0.018 |
| * L - luminance of image 0 <= L <= 1 for conventional colorimetry |
| * E - corresponding electrical signal |
| */ |
| HAL_DATASPACE_TRANSFER_SMPTE_170M = 3 << HAL_DATASPACE_TRANSFER_SHIFT, |
| |
| /* |
| * Assumed display gamma 2.2. |
| * |
| * Transfer characteristic curve: |
| * E = L ^ (1/2.2) |
| * L - luminance of image 0 <= L <= 1 for conventional colorimetry |
| * E - corresponding electrical signal |
| */ |
| HAL_DATASPACE_TRANSFER_GAMMA2_2 = 4 << HAL_DATASPACE_TRANSFER_SHIFT, |
| |
| /* |
| * display gamma 2.8. |
| * |
| * Transfer characteristic curve: |
| * E = L ^ (1/2.8) |
| * L - luminance of image 0 <= L <= 1 for conventional colorimetry |
| * E - corresponding electrical signal |
| */ |
| HAL_DATASPACE_TRANSFER_GAMMA2_8 = 5 << HAL_DATASPACE_TRANSFER_SHIFT, |
| |
| /* |
| * SMPTE ST 2084 |
| * |
| * Transfer characteristic curve: |
| * E = ((c1 + c2 * L^n) / (1 + c3 * L^n)) ^ m |
| * c1 = c3 - c2 + 1 = 3424 / 4096 = 0.8359375 |
| * c2 = 32 * 2413 / 4096 = 18.8515625 |
| * c3 = 32 * 2392 / 4096 = 18.6875 |
| * m = 128 * 2523 / 4096 = 78.84375 |
| * n = 0.25 * 2610 / 4096 = 0.1593017578125 |
| * L - luminance of image 0 <= L <= 1 for HDR colorimetry. |
| * L = 1 corresponds to 10000 cd/m2 |
| * E - corresponding electrical signal |
| */ |
| HAL_DATASPACE_TRANSFER_ST2084 = 6 << HAL_DATASPACE_TRANSFER_SHIFT, |
| |
| /* |
| * ARIB STD-B67 Hybrid Log Gamma |
| * |
| * Transfer characteristic curve: |
| * E = r * L^0.5 for 0 <= L <= 1 |
| * = a * ln(L - b) + c for 1 < L |
| * a = 0.17883277 |
| * b = 0.28466892 |
| * c = 0.55991073 |
| * r = 0.5 |
| * L - luminance of image 0 <= L for HDR colorimetry. L = 1 corresponds |
| * to reference white level of 100 cd/m2 |
| * E - corresponding electrical signal |
| */ |
| HAL_DATASPACE_TRANSFER_HLG = 7 << HAL_DATASPACE_TRANSFER_SHIFT, |
| |
| HAL_DATASPACE_RANGE_SHIFT = 27, |
| |
| /* |
| * Range aspect |
| * |
| * Defines the range of values corresponding to the unit range of 0-1. |
| * This is defined for YCbCr only, but can be expanded to RGB space. |
| */ |
| HAL_DATASPACE_RANGE_MASK = 7 << HAL_DATASPACE_RANGE_SHIFT, // 0x7 |
| |
| /* |
| * Range is unknown or are determined by the application. Implementations |
| * shall use the following suggested ranges: |
| * |
| * All YCbCr formats: limited range. |
| * All RGB or RGBA formats (including RAW and Bayer): full range. |
| * All Y formats: full range |
| * |
| * For all other formats range is undefined, and implementations should use |
| * an appropriate range for the data represented. |
| */ |
| HAL_DATASPACE_RANGE_UNSPECIFIED = 0 << HAL_DATASPACE_RANGE_SHIFT, |
| |
| /* |
| * Full range uses all values for Y, Cb and Cr from |
| * 0 to 2^b-1, where b is the bit depth of the color format. |
| */ |
| HAL_DATASPACE_RANGE_FULL = 1 << HAL_DATASPACE_RANGE_SHIFT, |
| |
| /* |
| * Limited range uses values 16/256*2^b to 235/256*2^b for Y, and |
| * 1/16*2^b to 15/16*2^b for Cb, Cr, R, G and B, where b is the bit depth of |
| * the color format. |
| * |
| * E.g. 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 |
| */ |
| HAL_DATASPACE_RANGE_LIMITED = 2 << HAL_DATASPACE_RANGE_SHIFT, |
| |
| /* |
| * Legacy dataspaces |
| */ |
| |
| /* |
| * 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, // deprecated, use HAL_DATASPACE_V0_SRGB_LINEAR |
| |
| HAL_DATASPACE_V0_SRGB_LINEAR = HAL_DATASPACE_STANDARD_BT709 | |
| HAL_DATASPACE_TRANSFER_LINEAR | HAL_DATASPACE_RANGE_FULL, |
| |
| |
| /* |
| * sRGB gamma encoding: |
| * |
| * The red, green and blue components are stored in sRGB space, and |
| * converted to linear space when read, using the SRGB transfer function |
| * for each of the R, G and B components. When written, the inverse |
| * transformation is performed. |
| * |
| * The alpha component, if present, is always stored in linear space and |
| * is left unmodified when read or written. |
| * |
| * Use full range and BT.709 standard. |
| */ |
| HAL_DATASPACE_SRGB = 0x201, // deprecated, use HAL_DATASPACE_V0_SRGB |
| |
| HAL_DATASPACE_V0_SRGB = HAL_DATASPACE_STANDARD_BT709 | |
| HAL_DATASPACE_TRANSFER_SRGB | HAL_DATASPACE_RANGE_FULL, |
| |
| |
| /* |
| * 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 |
| * |
| * Use full range, BT.601 transfer and BT.601_625 standard. |
| */ |
| HAL_DATASPACE_JFIF = 0x101, // deprecated, use HAL_DATASPACE_V0_JFIF |
| |
| HAL_DATASPACE_V0_JFIF = HAL_DATASPACE_STANDARD_BT601_625 | |
| HAL_DATASPACE_TRANSFER_SMPTE_170M | HAL_DATASPACE_RANGE_FULL, |
| |
| /* |
| * ITU-R Recommendation 601 (BT.601) - 625-line |
| * |
| * Standard-definition television, 625 Lines (PAL) |
| * |
| * Use limited range, BT.601 transfer and BT.601_625 standard. |
| */ |
| HAL_DATASPACE_BT601_625 = 0x102, // deprecated, use HAL_DATASPACE_V0_BT601_625 |
| |
| HAL_DATASPACE_V0_BT601_625 = HAL_DATASPACE_STANDARD_BT601_625 | |
| HAL_DATASPACE_TRANSFER_SMPTE_170M | HAL_DATASPACE_RANGE_LIMITED, |
| |
| |
| /* |
| * ITU-R Recommendation 601 (BT.601) - 525-line |
| * |
| * Standard-definition television, 525 Lines (NTSC) |
| * |
| * Use limited range, BT.601 transfer and BT.601_525 standard. |
| */ |
| HAL_DATASPACE_BT601_525 = 0x103, // deprecated, use HAL_DATASPACE_V0_BT601_525 |
| |
| HAL_DATASPACE_V0_BT601_525 = HAL_DATASPACE_STANDARD_BT601_525 | |
| HAL_DATASPACE_TRANSFER_SMPTE_170M | HAL_DATASPACE_RANGE_LIMITED, |
| |
| /* |
| * ITU-R Recommendation 709 (BT.709) |
| * |
| * High-definition television |
| * |
| * Use limited range, BT.709 transfer and BT.709 standard. |
| */ |
| HAL_DATASPACE_BT709 = 0x104, // deprecated, use HAL_DATASPACE_V0_BT709 |
| |
| HAL_DATASPACE_V0_BT709 = HAL_DATASPACE_STANDARD_BT709 | |
| HAL_DATASPACE_TRANSFER_SMPTE_170M | HAL_DATASPACE_RANGE_LIMITED, |
| |
| /* |
| * Data spaces for non-color formats |
| */ |
| |
| /* |
| * 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 |
| |
| } android_dataspace_t; |
| |
| /* |
| * Color modes that may be supported by a display. |
| * |
| * Definitions: |
| * Rendering intent generally defines the goal in mapping a source (input) |
| * color to a destination device color for a given color mode. |
| * |
| * It is important to keep in mind three cases where mapping may be applied: |
| * 1. The source gamut is much smaller than the destination (display) gamut |
| * 2. The source gamut is much larger than the destination gamut (this will |
| * ordinarily be handled using colorimetric rendering, below) |
| * 3. The source and destination gamuts are roughly equal, although not |
| * completely overlapping |
| * Also, a common requirement for mappings is that skin tones should be |
| * preserved, or at least remain natural in appearance. |
| * |
| * Colorimetric Rendering Intent (All cases): |
| * Colorimetric indicates that colors should be preserved. In the case |
| * that the source gamut lies wholly within the destination gamut or is |
| * about the same (#1, #3), this will simply mean that no manipulations |
| * (no saturation boost, for example) are applied. In the case where some |
| * source colors lie outside the destination gamut (#2, #3), those will |
| * need to be mapped to colors that are within the destination gamut, |
| * while the already in-gamut colors remain unchanged. |
| * |
| * Non-colorimetric transforms can take many forms. There are no hard |
| * rules and it's left to the implementation to define. |
| * Two common intents are described below. |
| * |
| * Stretched-Gamut Enhancement Intent (Source < Destination): |
| * When the destination gamut is much larger than the source gamut (#1), the |
| * source primaries may be redefined to reflect the full extent of the |
| * destination space, or to reflect an intermediate gamut. |
| * Skin-tone preservation would likely be applied. An example might be sRGB |
| * input displayed on a DCI-P3 capable device, with skin-tone preservation. |
| * |
| * Within-Gamut Enhancement Intent (Source >= Destination): |
| * When the device (destination) gamut is not larger than the source gamut |
| * (#2 or #3), but the appearance of a larger gamut is desired, techniques |
| * such as saturation boost may be applied to the source colors. Skin-tone |
| * preservation may be applied. There is no unique method for within-gamut |
| * enhancement; it would be defined within a flexible color mode. |
| * |
| */ |
| typedef enum android_color_mode { |
| |
| /* |
| * HAL_COLOR_MODE_DEFAULT is the "native" gamut of the display. |
| * White Point: Vendor/OEM defined |
| * Panel Gamma: Vendor/OEM defined (typically 2.2) |
| * Rendering Intent: Vendor/OEM defined (typically 'enhanced') |
| */ |
| HAL_COLOR_MODE_NATIVE = 0, |
| |
| /* |
| * HAL_COLOR_MODE_STANDARD_BT601_625 corresponds with display |
| * settings that implement the ITU-R Recommendation BT.601 |
| * or Rec 601. Using 625 line version |
| * Rendering Intent: Colorimetric |
| * Primaries: |
| * x y |
| * green 0.290 0.600 |
| * blue 0.150 0.060 |
| * red 0.640 0.330 |
| * white (D65) 0.3127 0.3290 |
| * |
| * KR = 0.299, KB = 0.114. This adjusts the luminance interpretation |
| * for RGB conversion from the one purely determined by the primaries |
| * to minimize the color shift into RGB space that uses BT.709 |
| * primaries. |
| * |
| * Gamma Correction (GC): |
| * |
| * if Vlinear < 0.018 |
| * Vnonlinear = 4.500 * Vlinear |
| * else |
| * Vnonlinear = 1.099 * (Vlinear)^(0.45) – 0.099 |
| */ |
| HAL_COLOR_MODE_STANDARD_BT601_625 = 1, |
| |
| /* |
| * Primaries: |
| * x y |
| * green 0.290 0.600 |
| * blue 0.150 0.060 |
| * red 0.640 0.330 |
| * white (D65) 0.3127 0.3290 |
| * |
| * Use the unadjusted KR = 0.222, KB = 0.071 luminance interpretation |
| * for RGB conversion. |
| * |
| * Gamma Correction (GC): |
| * |
| * if Vlinear < 0.018 |
| * Vnonlinear = 4.500 * Vlinear |
| * else |
| * Vnonlinear = 1.099 * (Vlinear)^(0.45) – 0.099 |
| */ |
| HAL_COLOR_MODE_STANDARD_BT601_625_UNADJUSTED = 2, |
| |
| /* |
| * Primaries: |
| * x y |
| * green 0.310 0.595 |
| * blue 0.155 0.070 |
| * red 0.630 0.340 |
| * white (D65) 0.3127 0.3290 |
| * |
| * KR = 0.299, KB = 0.114. This adjusts the luminance interpretation |
| * for RGB conversion from the one purely determined by the primaries |
| * to minimize the color shift into RGB space that uses BT.709 |
| * primaries. |
| * |
| * Gamma Correction (GC): |
| * |
| * if Vlinear < 0.018 |
| * Vnonlinear = 4.500 * Vlinear |
| * else |
| * Vnonlinear = 1.099 * (Vlinear)^(0.45) – 0.099 |
| */ |
| HAL_COLOR_MODE_STANDARD_BT601_525 = 3, |
| |
| /* |
| * Primaries: |
| * x y |
| * green 0.310 0.595 |
| * blue 0.155 0.070 |
| * red 0.630 0.340 |
| * white (D65) 0.3127 0.3290 |
| * |
| * Use the unadjusted KR = 0.212, KB = 0.087 luminance interpretation |
| * for RGB conversion (as in SMPTE 240M). |
| * |
| * Gamma Correction (GC): |
| * |
| * if Vlinear < 0.018 |
| * Vnonlinear = 4.500 * Vlinear |
| * else |
| * Vnonlinear = 1.099 * (Vlinear)^(0.45) – 0.099 |
| */ |
| HAL_COLOR_MODE_STANDARD_BT601_525_UNADJUSTED = 4, |
| |
| /* |
| * HAL_COLOR_MODE_REC709 corresponds with display settings that implement |
| * the ITU-R Recommendation BT.709 / Rec. 709 for high-definition television. |
| * Rendering Intent: Colorimetric |
| * Primaries: |
| * x y |
| * green 0.300 0.600 |
| * blue 0.150 0.060 |
| * red 0.640 0.330 |
| * white (D65) 0.3127 0.3290 |
| * |
| * HDTV REC709 Inverse Gamma Correction (IGC): V represents normalized |
| * (with [0 to 1] range) value of R, G, or B. |
| * |
| * if Vnonlinear < 0.081 |
| * Vlinear = Vnonlinear / 4.5 |
| * else |
| * Vlinear = ((Vnonlinear + 0.099) / 1.099) ^ (1/0.45) |
| * |
| * HDTV REC709 Gamma Correction (GC): |
| * |
| * if Vlinear < 0.018 |
| * Vnonlinear = 4.5 * Vlinear |
| * else |
| * Vnonlinear = 1.099 * (Vlinear) ^ 0.45 – 0.099 |
| */ |
| HAL_COLOR_MODE_STANDARD_BT709 = 5, |
| |
| /* |
| * HAL_COLOR_MODE_DCI_P3 corresponds with display settings that implement |
| * SMPTE EG 432-1 and SMPTE RP 431-2 |
| * Rendering Intent: Colorimetric |
| * Primaries: |
| * x y |
| * green 0.265 0.690 |
| * blue 0.150 0.060 |
| * red 0.680 0.320 |
| * white (D65) 0.3127 0.3290 |
| * |
| * Gamma: 2.2 |
| */ |
| HAL_COLOR_MODE_DCI_P3 = 6, |
| |
| /* |
| * HAL_COLOR_MODE_SRGB corresponds with display settings that implement |
| * the sRGB color space. Uses the same primaries as ITU-R Recommendation |
| * BT.709 |
| * Rendering Intent: Colorimetric |
| * Primaries: |
| * x y |
| * green 0.300 0.600 |
| * blue 0.150 0.060 |
| * red 0.640 0.330 |
| * white (D65) 0.3127 0.3290 |
| * |
| * PC/Internet (sRGB) Inverse Gamma Correction (IGC): |
| * |
| * if Vnonlinear ≤ 0.03928 |
| * Vlinear = Vnonlinear / 12.92 |
| * else |
| * Vlinear = ((Vnonlinear + 0.055)/1.055) ^ 2.4 |
| * |
| * PC/Internet (sRGB) Gamma Correction (GC): |
| * |
| * if Vlinear ≤ 0.0031308 |
| * Vnonlinear = 12.92 * Vlinear |
| * else |
| * Vnonlinear = 1.055 * (Vlinear)^(1/2.4) – 0.055 |
| */ |
| HAL_COLOR_MODE_SRGB = 7, |
| |
| /* |
| * HAL_COLOR_MODE_ADOBE_RGB corresponds with the RGB color space developed |
| * by Adobe Systems, Inc. in 1998. |
| * Rendering Intent: Colorimetric |
| * Primaries: |
| * x y |
| * green 0.210 0.710 |
| * blue 0.150 0.060 |
| * red 0.640 0.330 |
| * white (D65) 0.3127 0.3290 |
| * |
| * Gamma: 2.2 |
| */ |
| HAL_COLOR_MODE_ADOBE_RGB = 8 |
| |
| } android_color_mode_t; |
| |
| /* |
| * Color transforms that may be applied by hardware composer to the whole |
| * display. |
| */ |
| typedef enum android_color_transform { |
| /* Applies no transform to the output color */ |
| HAL_COLOR_TRANSFORM_IDENTITY = 0, |
| |
| /* Applies an arbitrary transform defined by a 4x4 affine matrix */ |
| HAL_COLOR_TRANSFORM_ARBITRARY_MATRIX = 1, |
| |
| /* Applies a transform that inverts the value or luminance of the color, but |
| * does not modify hue or saturation */ |
| HAL_COLOR_TRANSFORM_VALUE_INVERSE = 2, |
| |
| /* Applies a transform that maps all colors to shades of gray */ |
| HAL_COLOR_TRANSFORM_GRAYSCALE = 3, |
| |
| /* Applies a transform which corrects for protanopic color blindness */ |
| HAL_COLOR_TRANSFORM_CORRECT_PROTANOPIA = 4, |
| |
| /* Applies a transform which corrects for deuteranopic color blindness */ |
| HAL_COLOR_TRANSFORM_CORRECT_DEUTERANOPIA = 5, |
| |
| /* Applies a transform which corrects for tritanopic color blindness */ |
| HAL_COLOR_TRANSFORM_CORRECT_TRITANOPIA = 6 |
| } android_color_transform_t; |
| |
| /* |
| * Supported HDR formats. Must be kept in sync with equivalents in Display.java. |
| */ |
| typedef enum android_hdr { |
| /* Device supports Dolby Vision HDR */ |
| HAL_HDR_DOLBY_VISION = 1, |
| |
| /* Device supports HDR10 */ |
| HAL_HDR_HDR10 = 2, |
| |
| /* Device supports hybrid log-gamma HDR */ |
| HAL_HDR_HLG = 3 |
| } android_hdr_t; |
| |
| #ifdef __cplusplus |
| } |
| #endif |
| |
| #endif /* SYSTEM_CORE_INCLUDE_ANDROID_GRAPHICS_H */ |
