1 /* 2 * Copyright (C) 2011 The Android Open Source Project 3 * 4 * Licensed under the Apache License, Version 2.0 (the "License"); 5 * you may not use this file except in compliance with the License. 6 * You may obtain a copy of the License at 7 * 8 * http://www.apache.org/licenses/LICENSE-2.0 9 * 10 * Unless required by applicable law or agreed to in writing, software 11 * distributed under the License is distributed on an "AS IS" BASIS, 12 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 13 * See the License for the specific language governing permissions and 14 * limitations under the License. 15 */ 16 17 #ifndef SYSTEM_CORE_INCLUDE_ANDROID_GRAPHICS_H 18 #define SYSTEM_CORE_INCLUDE_ANDROID_GRAPHICS_H 19 20 #include <stddef.h> 21 #include <stdint.h> 22 23 #ifdef __cplusplus 24 extern "C" { 25 #endif 26 27 /* 28 * If the HAL needs to create service threads to handle graphics related 29 * tasks, these threads need to run at HAL_PRIORITY_URGENT_DISPLAY priority 30 * if they can block the main rendering thread in any way. 31 * 32 * the priority of the current thread can be set with: 33 * 34 * #include <sys/resource.h> 35 * setpriority(PRIO_PROCESS, 0, HAL_PRIORITY_URGENT_DISPLAY); 36 * 37 */ 38 39 #define HAL_PRIORITY_URGENT_DISPLAY (-8) 40 41 /** 42 * pixel format definitions 43 */ 44 45 typedef enum android_pixel_format { 46 /* 47 * "linear" color pixel formats: 48 * 49 * When used with ANativeWindow, the dataSpace field describes the color 50 * space of the buffer. 51 * 52 * The color space determines, for example, if the formats are linear or 53 * gamma-corrected; or whether any special operations are performed when 54 * reading or writing into a buffer in one of these formats. 55 */ 56 HAL_PIXEL_FORMAT_RGBA_8888 = 1, 57 HAL_PIXEL_FORMAT_RGBX_8888 = 2, 58 HAL_PIXEL_FORMAT_RGB_888 = 3, 59 HAL_PIXEL_FORMAT_RGB_565 = 4, 60 HAL_PIXEL_FORMAT_BGRA_8888 = 5, 61 62 /* 63 * 0x100 - 0x1FF 64 * 65 * This range is reserved for pixel formats that are specific to the HAL 66 * implementation. Implementations can use any value in this range to 67 * communicate video pixel formats between their HAL modules. These formats 68 * must not have an alpha channel. Additionally, an EGLimage created from a 69 * gralloc buffer of one of these formats must be supported for use with the 70 * GL_OES_EGL_image_external OpenGL ES extension. 71 */ 72 73 /* 74 * Android YUV format: 75 * 76 * This format is exposed outside of the HAL to software decoders and 77 * applications. EGLImageKHR must support it in conjunction with the 78 * OES_EGL_image_external extension. 79 * 80 * YV12 is a 4:2:0 YCrCb planar format comprised of a WxH Y plane followed 81 * by (W/2) x (H/2) Cr and Cb planes. 82 * 83 * This format assumes 84 * - an even width 85 * - an even height 86 * - a horizontal stride multiple of 16 pixels 87 * - a vertical stride equal to the height 88 * 89 * y_size = stride * height 90 * c_stride = ALIGN(stride/2, 16) 91 * c_size = c_stride * height/2 92 * size = y_size + c_size * 2 93 * cr_offset = y_size 94 * cb_offset = y_size + c_size 95 * 96 * When used with ANativeWindow, the dataSpace field describes the color 97 * space of the buffer. 98 */ 99 HAL_PIXEL_FORMAT_YV12 = 0x32315659, // YCrCb 4:2:0 Planar 100 101 102 /* 103 * Android Y8 format: 104 * 105 * This format is exposed outside of the HAL to the framework. 106 * The expected gralloc usage flags are SW_* and HW_CAMERA_*, 107 * and no other HW_ flags will be used. 108 * 109 * Y8 is a YUV planar format comprised of a WxH Y plane, 110 * with each pixel being represented by 8 bits. 111 * 112 * It is equivalent to just the Y plane from YV12. 113 * 114 * This format assumes 115 * - an even width 116 * - an even height 117 * - a horizontal stride multiple of 16 pixels 118 * - a vertical stride equal to the height 119 * 120 * size = stride * height 121 * 122 * When used with ANativeWindow, the dataSpace field describes the color 123 * space of the buffer. 124 */ 125 HAL_PIXEL_FORMAT_Y8 = 0x20203859, 126 127 /* 128 * Android Y16 format: 129 * 130 * This format is exposed outside of the HAL to the framework. 131 * The expected gralloc usage flags are SW_* and HW_CAMERA_*, 132 * and no other HW_ flags will be used. 133 * 134 * Y16 is a YUV planar format comprised of a WxH Y plane, 135 * with each pixel being represented by 16 bits. 136 * 137 * It is just like Y8, but has double the bits per pixel (little endian). 138 * 139 * This format assumes 140 * - an even width 141 * - an even height 142 * - a horizontal stride multiple of 16 pixels 143 * - a vertical stride equal to the height 144 * - strides are specified in pixels, not in bytes 145 * 146 * size = stride * height * 2 147 * 148 * When used with ANativeWindow, the dataSpace field describes the color 149 * space of the buffer, except that dataSpace field 150 * HAL_DATASPACE_DEPTH indicates that this buffer contains a depth 151 * image where each sample is a distance value measured by a depth camera, 152 * plus an associated confidence value. 153 */ 154 HAL_PIXEL_FORMAT_Y16 = 0x20363159, 155 156 /* 157 * Android RAW sensor format: 158 * 159 * This format is exposed outside of the camera HAL to applications. 160 * 161 * RAW16 is a single-channel, 16-bit, little endian format, typically 162 * representing raw Bayer-pattern images from an image sensor, with minimal 163 * processing. 164 * 165 * The exact pixel layout of the data in the buffer is sensor-dependent, and 166 * needs to be queried from the camera device. 167 * 168 * Generally, not all 16 bits are used; more common values are 10 or 12 169 * bits. If not all bits are used, the lower-order bits are filled first. 170 * All parameters to interpret the raw data (black and white points, 171 * color space, etc) must be queried from the camera device. 172 * 173 * This format assumes 174 * - an even width 175 * - an even height 176 * - a horizontal stride multiple of 16 pixels 177 * - a vertical stride equal to the height 178 * - strides are specified in pixels, not in bytes 179 * 180 * size = stride * height * 2 181 * 182 * This format must be accepted by the gralloc module when used with the 183 * following usage flags: 184 * - GRALLOC_USAGE_HW_CAMERA_* 185 * - GRALLOC_USAGE_SW_* 186 * - GRALLOC_USAGE_RENDERSCRIPT 187 * 188 * When used with ANativeWindow, the dataSpace should be 189 * HAL_DATASPACE_ARBITRARY, as raw image sensor buffers require substantial 190 * extra metadata to define. 191 */ 192 HAL_PIXEL_FORMAT_RAW16 = 0x20, 193 194 /* 195 * Android RAW10 format: 196 * 197 * This format is exposed outside of the camera HAL to applications. 198 * 199 * RAW10 is a single-channel, 10-bit per pixel, densely packed in each row, 200 * unprocessed format, usually representing raw Bayer-pattern images coming from 201 * an image sensor. 202 * 203 * In an image buffer with this format, starting from the first pixel of each 204 * row, each 4 consecutive pixels are packed into 5 bytes (40 bits). Each one 205 * of the first 4 bytes contains the top 8 bits of each pixel, The fifth byte 206 * contains the 2 least significant bits of the 4 pixels, the exact layout data 207 * for each 4 consecutive pixels is illustrated below (Pi[j] stands for the jth 208 * bit of the ith pixel): 209 * 210 * bit 7 bit 0 211 * =====|=====|=====|=====|=====|=====|=====|=====| 212 * Byte 0: |P0[9]|P0[8]|P0[7]|P0[6]|P0[5]|P0[4]|P0[3]|P0[2]| 213 * |-----|-----|-----|-----|-----|-----|-----|-----| 214 * Byte 1: |P1[9]|P1[8]|P1[7]|P1[6]|P1[5]|P1[4]|P1[3]|P1[2]| 215 * |-----|-----|-----|-----|-----|-----|-----|-----| 216 * Byte 2: |P2[9]|P2[8]|P2[7]|P2[6]|P2[5]|P2[4]|P2[3]|P2[2]| 217 * |-----|-----|-----|-----|-----|-----|-----|-----| 218 * Byte 3: |P3[9]|P3[8]|P3[7]|P3[6]|P3[5]|P3[4]|P3[3]|P3[2]| 219 * |-----|-----|-----|-----|-----|-----|-----|-----| 220 * Byte 4: |P3[1]|P3[0]|P2[1]|P2[0]|P1[1]|P1[0]|P0[1]|P0[0]| 221 * =============================================== 222 * 223 * This format assumes 224 * - a width multiple of 4 pixels 225 * - an even height 226 * - a vertical stride equal to the height 227 * - strides are specified in bytes, not in pixels 228 * 229 * size = stride * height 230 * 231 * When stride is equal to width * (10 / 8), there will be no padding bytes at 232 * the end of each row, the entire image data is densely packed. When stride is 233 * larger than width * (10 / 8), padding bytes will be present at the end of each 234 * row (including the last row). 235 * 236 * This format must be accepted by the gralloc module when used with the 237 * following usage flags: 238 * - GRALLOC_USAGE_HW_CAMERA_* 239 * - GRALLOC_USAGE_SW_* 240 * - GRALLOC_USAGE_RENDERSCRIPT 241 * 242 * When used with ANativeWindow, the dataSpace field should be 243 * HAL_DATASPACE_ARBITRARY, as raw image sensor buffers require substantial 244 * extra metadata to define. 245 */ 246 HAL_PIXEL_FORMAT_RAW10 = 0x25, 247 248 /* 249 * Android RAW12 format: 250 * 251 * This format is exposed outside of camera HAL to applications. 252 * 253 * RAW12 is a single-channel, 12-bit per pixel, densely packed in each row, 254 * unprocessed format, usually representing raw Bayer-pattern images coming from 255 * an image sensor. 256 * 257 * In an image buffer with this format, starting from the first pixel of each 258 * row, each two consecutive pixels are packed into 3 bytes (24 bits). The first 259 * and second byte contains the top 8 bits of first and second pixel. The third 260 * byte contains the 4 least significant bits of the two pixels, the exact layout 261 * data for each two consecutive pixels is illustrated below (Pi[j] stands for 262 * the jth bit of the ith pixel): 263 * 264 * bit 7 bit 0 265 * ======|======|======|======|======|======|======|======| 266 * Byte 0: |P0[11]|P0[10]|P0[ 9]|P0[ 8]|P0[ 7]|P0[ 6]|P0[ 5]|P0[ 4]| 267 * |------|------|------|------|------|------|------|------| 268 * Byte 1: |P1[11]|P1[10]|P1[ 9]|P1[ 8]|P1[ 7]|P1[ 6]|P1[ 5]|P1[ 4]| 269 * |------|------|------|------|------|------|------|------| 270 * Byte 2: |P1[ 3]|P1[ 2]|P1[ 1]|P1[ 0]|P0[ 3]|P0[ 2]|P0[ 1]|P0[ 0]| 271 * ======================================================= 272 * 273 * This format assumes: 274 * - a width multiple of 4 pixels 275 * - an even height 276 * - a vertical stride equal to the height 277 * - strides are specified in bytes, not in pixels 278 * 279 * size = stride * height 280 * 281 * When stride is equal to width * (12 / 8), there will be no padding bytes at 282 * the end of each row, the entire image data is densely packed. When stride is 283 * larger than width * (12 / 8), padding bytes will be present at the end of 284 * each row (including the last row). 285 * 286 * This format must be accepted by the gralloc module when used with the 287 * following usage flags: 288 * - GRALLOC_USAGE_HW_CAMERA_* 289 * - GRALLOC_USAGE_SW_* 290 * - GRALLOC_USAGE_RENDERSCRIPT 291 * 292 * When used with ANativeWindow, the dataSpace field should be 293 * HAL_DATASPACE_ARBITRARY, as raw image sensor buffers require substantial 294 * extra metadata to define. 295 */ 296 HAL_PIXEL_FORMAT_RAW12 = 0x26, 297 298 /* 299 * Android opaque RAW format: 300 * 301 * This format is exposed outside of the camera HAL to applications. 302 * 303 * RAW_OPAQUE is a format for unprocessed raw image buffers coming from an 304 * image sensor. The actual structure of buffers of this format is 305 * implementation-dependent. 306 * 307 * This format must be accepted by the gralloc module when used with the 308 * following usage flags: 309 * - GRALLOC_USAGE_HW_CAMERA_* 310 * - GRALLOC_USAGE_SW_* 311 * - GRALLOC_USAGE_RENDERSCRIPT 312 * 313 * When used with ANativeWindow, the dataSpace field should be 314 * HAL_DATASPACE_ARBITRARY, as raw image sensor buffers require substantial 315 * extra metadata to define. 316 */ 317 HAL_PIXEL_FORMAT_RAW_OPAQUE = 0x24, 318 319 /* 320 * Android binary blob graphics buffer format: 321 * 322 * This format is used to carry task-specific data which does not have a 323 * standard image structure. The details of the format are left to the two 324 * endpoints. 325 * 326 * A typical use case is for transporting JPEG-compressed images from the 327 * Camera HAL to the framework or to applications. 328 * 329 * Buffers of this format must have a height of 1, and width equal to their 330 * size in bytes. 331 * 332 * When used with ANativeWindow, the mapping of the dataSpace field to 333 * buffer contents for BLOB is as follows: 334 * 335 * dataSpace value | Buffer contents 336 * -------------------------------+----------------------------------------- 337 * HAL_DATASPACE_JFIF | An encoded JPEG image 338 * HAL_DATASPACE_DEPTH | An android_depth_points buffer 339 * Other | Unsupported 340 * 341 */ 342 HAL_PIXEL_FORMAT_BLOB = 0x21, 343 344 /* 345 * Android format indicating that the choice of format is entirely up to the 346 * device-specific Gralloc implementation. 347 * 348 * The Gralloc implementation should examine the usage bits passed in when 349 * allocating a buffer with this format, and it should derive the pixel 350 * format from those usage flags. This format will never be used with any 351 * of the GRALLOC_USAGE_SW_* usage flags. 352 * 353 * If a buffer of this format is to be used as an OpenGL ES texture, the 354 * framework will assume that sampling the texture will always return an 355 * alpha value of 1.0 (i.e. the buffer contains only opaque pixel values). 356 * 357 * When used with ANativeWindow, the dataSpace field describes the color 358 * space of the buffer. 359 */ 360 HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED = 0x22, 361 362 /* 363 * Android flexible YCbCr 4:2:0 formats 364 * 365 * This format allows platforms to use an efficient YCbCr/YCrCb 4:2:0 366 * buffer layout, while still describing the general format in a 367 * layout-independent manner. While called YCbCr, it can be 368 * used to describe formats with either chromatic ordering, as well as 369 * whole planar or semiplanar layouts. 370 * 371 * struct android_ycbcr (below) is the the struct used to describe it. 372 * 373 * This format must be accepted by the gralloc module when 374 * USAGE_SW_WRITE_* or USAGE_SW_READ_* are set. 375 * 376 * This format is locked for use by gralloc's (*lock_ycbcr) method, and 377 * locking with the (*lock) method will return an error. 378 * 379 * When used with ANativeWindow, the dataSpace field describes the color 380 * space of the buffer. 381 */ 382 HAL_PIXEL_FORMAT_YCbCr_420_888 = 0x23, 383 384 /* 385 * Android flexible YCbCr 4:2:2 formats 386 * 387 * This format allows platforms to use an efficient YCbCr/YCrCb 4:2:2 388 * buffer layout, while still describing the general format in a 389 * layout-independent manner. While called YCbCr, it can be 390 * used to describe formats with either chromatic ordering, as well as 391 * whole planar or semiplanar layouts. 392 * 393 * This format is currently only used by SW readable buffers 394 * produced by MediaCodecs, so the gralloc module can ignore this format. 395 */ 396 HAL_PIXEL_FORMAT_YCbCr_422_888 = 0x27, 397 398 /* 399 * Android flexible YCbCr 4:4:4 formats 400 * 401 * This format allows platforms to use an efficient YCbCr/YCrCb 4:4:4 402 * buffer layout, while still describing the general format in a 403 * layout-independent manner. While called YCbCr, it can be 404 * used to describe formats with either chromatic ordering, as well as 405 * whole planar or semiplanar layouts. 406 * 407 * This format is currently only used by SW readable buffers 408 * produced by MediaCodecs, so the gralloc module can ignore this format. 409 */ 410 HAL_PIXEL_FORMAT_YCbCr_444_888 = 0x28, 411 412 /* 413 * Android flexible RGB 888 formats 414 * 415 * This format allows platforms to use an efficient RGB/BGR/RGBX/BGRX 416 * buffer layout, while still describing the general format in a 417 * layout-independent manner. While called RGB, it can be 418 * used to describe formats with either color ordering and optional 419 * padding, as well as whole planar layout. 420 * 421 * This format is currently only used by SW readable buffers 422 * produced by MediaCodecs, so the gralloc module can ignore this format. 423 */ 424 HAL_PIXEL_FORMAT_FLEX_RGB_888 = 0x29, 425 426 /* 427 * Android flexible RGBA 8888 formats 428 * 429 * This format allows platforms to use an efficient RGBA/BGRA/ARGB/ABGR 430 * buffer layout, while still describing the general format in a 431 * layout-independent manner. While called RGBA, it can be 432 * used to describe formats with any of the component orderings, as 433 * well as whole planar layout. 434 * 435 * This format is currently only used by SW readable buffers 436 * produced by MediaCodecs, so the gralloc module can ignore this format. 437 */ 438 HAL_PIXEL_FORMAT_FLEX_RGBA_8888 = 0x2A, 439 440 /* Legacy formats (deprecated), used by ImageFormat.java */ 441 HAL_PIXEL_FORMAT_YCbCr_422_SP = 0x10, // NV16 442 HAL_PIXEL_FORMAT_YCrCb_420_SP = 0x11, // NV21 443 HAL_PIXEL_FORMAT_YCbCr_422_I = 0x14, // YUY2 444 } android_pixel_format_t; 445 446 /* 447 * Structure for describing YCbCr formats for consumption by applications. 448 * This is used with HAL_PIXEL_FORMAT_YCbCr_*_888. 449 * 450 * Buffer chroma subsampling is defined in the format. 451 * e.g. HAL_PIXEL_FORMAT_YCbCr_420_888 has subsampling 4:2:0. 452 * 453 * Buffers must have a 8 bit depth. 454 * 455 * @y, @cb, and @cr point to the first byte of their respective planes. 456 * 457 * Stride describes the distance in bytes from the first value of one row of 458 * the image to the first value of the next row. It includes the width of the 459 * image plus padding. 460 * @ystride is the stride of the luma plane. 461 * @cstride is the stride of the chroma planes. 462 * 463 * @chroma_step is the distance in bytes from one chroma pixel value to the 464 * next. This is 2 bytes for semiplanar (because chroma values are interleaved 465 * and each chroma value is one byte) and 1 for planar. 466 */ 467 468 struct android_ycbcr { 469 void *y; 470 void *cb; 471 void *cr; 472 size_t ystride; 473 size_t cstride; 474 size_t chroma_step; 475 476 /** reserved for future use, set to 0 by gralloc's (*lock_ycbcr)() */ 477 uint32_t reserved[8]; 478 }; 479 480 /* 481 * Structures for describing flexible YUVA/RGBA formats for consumption by 482 * applications. Such flexible formats contain a plane for each component (e.g. 483 * red, green, blue), where each plane is laid out in a grid-like pattern 484 * occupying unique byte addresses and with consistent byte offsets between 485 * neighboring pixels. 486 * 487 * The android_flex_layout structure is used with any pixel format that can be 488 * represented by it, such as: 489 * - HAL_PIXEL_FORMAT_YCbCr_*_888 490 * - HAL_PIXEL_FORMAT_FLEX_RGB*_888 491 * - HAL_PIXEL_FORMAT_RGB[AX]_888[8],BGRA_8888,RGB_888 492 * - HAL_PIXEL_FORMAT_YV12,Y8,Y16,YCbCr_422_SP/I,YCrCb_420_SP 493 * - even implementation defined formats that can be represented by 494 * the structures 495 * 496 * Vertical increment (aka. row increment or stride) describes the distance in 497 * bytes from the first pixel of one row to the first pixel of the next row 498 * (below) for the component plane. This can be negative. 499 * 500 * Horizontal increment (aka. column or pixel increment) describes the distance 501 * in bytes from one pixel to the next pixel (to the right) on the same row for 502 * the component plane. This can be negative. 503 * 504 * Each plane can be subsampled either vertically or horizontally by 505 * a power-of-two factor. 506 * 507 * The bit-depth of each component can be arbitrary, as long as the pixels are 508 * laid out on whole bytes, in native byte-order, using the most significant 509 * bits of each unit. 510 */ 511 512 typedef enum android_flex_component { 513 /* luma */ 514 FLEX_COMPONENT_Y = 1 << 0, 515 /* chroma blue */ 516 FLEX_COMPONENT_Cb = 1 << 1, 517 /* chroma red */ 518 FLEX_COMPONENT_Cr = 1 << 2, 519 520 /* red */ 521 FLEX_COMPONENT_R = 1 << 10, 522 /* green */ 523 FLEX_COMPONENT_G = 1 << 11, 524 /* blue */ 525 FLEX_COMPONENT_B = 1 << 12, 526 527 /* alpha */ 528 FLEX_COMPONENT_A = 1 << 30, 529 } android_flex_component_t; 530 531 typedef struct android_flex_plane { 532 /* pointer to the first byte of the top-left pixel of the plane. */ 533 uint8_t *top_left; 534 535 android_flex_component_t component; 536 537 /* bits allocated for the component in each pixel. Must be a positive 538 multiple of 8. */ 539 int32_t bits_per_component; 540 /* number of the most significant bits used in the format for this 541 component. Must be between 1 and bits_per_component, inclusive. */ 542 int32_t bits_used; 543 544 /* horizontal increment */ 545 int32_t h_increment; 546 /* vertical increment */ 547 int32_t v_increment; 548 /* horizontal subsampling. Must be a positive power of 2. */ 549 int32_t h_subsampling; 550 /* vertical subsampling. Must be a positive power of 2. */ 551 int32_t v_subsampling; 552 } android_flex_plane_t; 553 554 typedef enum android_flex_format { 555 /* not a flexible format */ 556 FLEX_FORMAT_INVALID = 0x0, 557 FLEX_FORMAT_Y = FLEX_COMPONENT_Y, 558 FLEX_FORMAT_YCbCr = FLEX_COMPONENT_Y | FLEX_COMPONENT_Cb | FLEX_COMPONENT_Cr, 559 FLEX_FORMAT_YCbCrA = FLEX_FORMAT_YCbCr | FLEX_COMPONENT_A, 560 FLEX_FORMAT_RGB = FLEX_COMPONENT_R | FLEX_COMPONENT_G | FLEX_COMPONENT_B, 561 FLEX_FORMAT_RGBA = FLEX_FORMAT_RGB | FLEX_COMPONENT_A, 562 } android_flex_format_t; 563 564 typedef struct android_flex_layout { 565 /* the kind of flexible format */ 566 android_flex_format_t format; 567 568 /* number of planes; 0 for FLEX_FORMAT_INVALID */ 569 uint32_t num_planes; 570 /* a plane for each component; ordered in increasing component value order. 571 E.g. FLEX_FORMAT_RGBA maps 0 -> R, 1 -> G, etc. 572 Can be NULL for FLEX_FORMAT_INVALID */ 573 android_flex_plane_t *planes; 574 } android_flex_layout_t; 575 576 /** 577 * Structure used to define depth point clouds for format HAL_PIXEL_FORMAT_BLOB 578 * with dataSpace value of HAL_DATASPACE_DEPTH. 579 * When locking a native buffer of the above format and dataSpace value, 580 * the vaddr pointer can be cast to this structure. 581 * 582 * A variable-length list of (x,y,z, confidence) 3D points, as floats. (x, y, 583 * z) represents a measured point's position, with the coordinate system defined 584 * by the data source. Confidence represents the estimated likelihood that this 585 * measurement is correct. It is between 0.f and 1.f, inclusive, with 1.f == 586 * 100% confidence. 587 * 588 * @num_points is the number of points in the list 589 * 590 * @xyz_points is the flexible array of floating-point values. 591 * It contains (num_points) * 4 floats. 592 * 593 * For example: 594 * android_depth_points d = get_depth_buffer(); 595 * struct { 596 * float x; float y; float z; float confidence; 597 * } firstPoint, lastPoint; 598 * 599 * firstPoint.x = d.xyzc_points[0]; 600 * firstPoint.y = d.xyzc_points[1]; 601 * firstPoint.z = d.xyzc_points[2]; 602 * firstPoint.confidence = d.xyzc_points[3]; 603 * lastPoint.x = d.xyzc_points[(d.num_points - 1) * 4 + 0]; 604 * lastPoint.y = d.xyzc_points[(d.num_points - 1) * 4 + 1]; 605 * lastPoint.z = d.xyzc_points[(d.num_points - 1) * 4 + 2]; 606 * lastPoint.confidence = d.xyzc_points[(d.num_points - 1) * 4 + 3]; 607 */ 608 609 struct android_depth_points { 610 uint32_t num_points; 611 612 /** reserved for future use, set to 0 by gralloc's (*lock)() */ 613 uint32_t reserved[8]; 614 615 float xyzc_points[]; 616 }; 617 618 /** 619 * Transformation definitions 620 * 621 * IMPORTANT NOTE: 622 * HAL_TRANSFORM_ROT_90 is applied CLOCKWISE and AFTER HAL_TRANSFORM_FLIP_{H|V}. 623 * 624 */ 625 626 typedef enum android_transform { 627 /* flip source image horizontally (around the vertical axis) */ 628 HAL_TRANSFORM_FLIP_H = 0x01, 629 /* flip source image vertically (around the horizontal axis)*/ 630 HAL_TRANSFORM_FLIP_V = 0x02, 631 /* rotate source image 90 degrees clockwise */ 632 HAL_TRANSFORM_ROT_90 = 0x04, 633 /* rotate source image 180 degrees */ 634 HAL_TRANSFORM_ROT_180 = 0x03, 635 /* rotate source image 270 degrees clockwise */ 636 HAL_TRANSFORM_ROT_270 = 0x07, 637 /* don't use. see system/window.h */ 638 HAL_TRANSFORM_RESERVED = 0x08, 639 } android_transform_t; 640 641 /** 642 * Dataspace Definitions 643 * ====================== 644 * 645 * Dataspace is the definition of how pixel values should be interpreted. 646 * 647 * For many formats, this is the colorspace of the image data, which includes 648 * primaries (including white point) and the transfer characteristic function, 649 * which describes both gamma curve and numeric range (within the bit depth). 650 * 651 * Other dataspaces include depth measurement data from a depth camera. 652 * 653 * A dataspace is comprised of a number of fields. 654 * 655 * Version 656 * -------- 657 * The top 2 bits represent the revision of the field specification. This is 658 * currently always 0. 659 * 660 * 661 * bits 31-30 29 - 0 662 * +-----+----------------------------------------------------+ 663 * fields | Rev | Revision specific fields | 664 * +-----+----------------------------------------------------+ 665 * 666 * Field layout for version = 0: 667 * ---------------------------- 668 * 669 * A dataspace is comprised of the following fields: 670 * Standard 671 * Transfer function 672 * Range 673 * 674 * bits 31-30 29-27 26 - 22 21 - 16 15 - 0 675 * +-----+-----+--------+--------+----------------------------+ 676 * fields | 0 |Range|Transfer|Standard| Legacy and custom | 677 * +-----+-----+--------+--------+----------------------------+ 678 * VV RRR TTTTT SSSSSS LLLLLLLL LLLLLLLL 679 * 680 * If range, transfer and standard fields are all 0 (e.g. top 16 bits are 681 * all zeroes), the bottom 16 bits contain either a legacy dataspace value, 682 * or a custom value. 683 */ 684 685 typedef enum android_dataspace { 686 /* 687 * Default-assumption data space, when not explicitly specified. 688 * 689 * It is safest to assume the buffer is an image with sRGB primaries and 690 * encoding ranges, but the consumer and/or the producer of the data may 691 * simply be using defaults. No automatic gamma transform should be 692 * expected, except for a possible display gamma transform when drawn to a 693 * screen. 694 */ 695 HAL_DATASPACE_UNKNOWN = 0x0, 696 697 /* 698 * Arbitrary dataspace with manually defined characteristics. Definition 699 * for colorspaces or other meaning must be communicated separately. 700 * 701 * This is used when specifying primaries, transfer characteristics, 702 * etc. separately. 703 * 704 * A typical use case is in video encoding parameters (e.g. for H.264), 705 * where a colorspace can have separately defined primaries, transfer 706 * characteristics, etc. 707 */ 708 HAL_DATASPACE_ARBITRARY = 0x1, 709 710 /* 711 * Color-description aspects 712 * 713 * The following aspects define various characteristics of the color 714 * specification. These represent bitfields, so that a data space value 715 * can specify each of them independently. 716 */ 717 718 HAL_DATASPACE_STANDARD_SHIFT = 16, 719 720 /* 721 * Standard aspect 722 * 723 * Defines the chromaticity coordinates of the source primaries in terms of 724 * the CIE 1931 definition of x and y specified in ISO 11664-1. 725 */ 726 HAL_DATASPACE_STANDARD_MASK = 63 << HAL_DATASPACE_STANDARD_SHIFT, // 0x3F 727 728 /* 729 * Chromacity coordinates are unknown or are determined by the application. 730 * Implementations shall use the following suggested standards: 731 * 732 * All YCbCr formats: BT709 if size is 720p or larger (since most video 733 * content is letterboxed this corresponds to width is 734 * 1280 or greater, or height is 720 or greater). 735 * BT601_625 if size is smaller than 720p or is JPEG. 736 * All RGB formats: BT709. 737 * 738 * For all other formats standard is undefined, and implementations should use 739 * an appropriate standard for the data represented. 740 */ 741 HAL_DATASPACE_STANDARD_UNSPECIFIED = 0 << HAL_DATASPACE_STANDARD_SHIFT, 742 743 /* 744 * Primaries: x y 745 * green 0.300 0.600 746 * blue 0.150 0.060 747 * red 0.640 0.330 748 * white (D65) 0.3127 0.3290 749 * 750 * Use the unadjusted KR = 0.2126, KB = 0.0722 luminance interpretation 751 * for RGB conversion. 752 */ 753 HAL_DATASPACE_STANDARD_BT709 = 1 << HAL_DATASPACE_STANDARD_SHIFT, 754 755 /* 756 * Primaries: x y 757 * green 0.290 0.600 758 * blue 0.150 0.060 759 * red 0.640 0.330 760 * white (D65) 0.3127 0.3290 761 * 762 * KR = 0.299, KB = 0.114. This adjusts the luminance interpretation 763 * for RGB conversion from the one purely determined by the primaries 764 * to minimize the color shift into RGB space that uses BT.709 765 * primaries. 766 */ 767 HAL_DATASPACE_STANDARD_BT601_625 = 2 << HAL_DATASPACE_STANDARD_SHIFT, 768 769 /* 770 * Primaries: x y 771 * green 0.290 0.600 772 * blue 0.150 0.060 773 * red 0.640 0.330 774 * white (D65) 0.3127 0.3290 775 * 776 * Use the unadjusted KR = 0.222, KB = 0.071 luminance interpretation 777 * for RGB conversion. 778 */ 779 HAL_DATASPACE_STANDARD_BT601_625_UNADJUSTED = 3 << HAL_DATASPACE_STANDARD_SHIFT, 780 781 /* 782 * Primaries: x y 783 * green 0.310 0.595 784 * blue 0.155 0.070 785 * red 0.630 0.340 786 * white (D65) 0.3127 0.3290 787 * 788 * KR = 0.299, KB = 0.114. This adjusts the luminance interpretation 789 * for RGB conversion from the one purely determined by the primaries 790 * to minimize the color shift into RGB space that uses BT.709 791 * primaries. 792 */ 793 HAL_DATASPACE_STANDARD_BT601_525 = 4 << HAL_DATASPACE_STANDARD_SHIFT, 794 795 /* 796 * Primaries: x y 797 * green 0.310 0.595 798 * blue 0.155 0.070 799 * red 0.630 0.340 800 * white (D65) 0.3127 0.3290 801 * 802 * Use the unadjusted KR = 0.212, KB = 0.087 luminance interpretation 803 * for RGB conversion (as in SMPTE 240M). 804 */ 805 HAL_DATASPACE_STANDARD_BT601_525_UNADJUSTED = 5 << HAL_DATASPACE_STANDARD_SHIFT, 806 807 /* 808 * Primaries: x y 809 * green 0.170 0.797 810 * blue 0.131 0.046 811 * red 0.708 0.292 812 * white (D65) 0.3127 0.3290 813 * 814 * Use the unadjusted KR = 0.2627, KB = 0.0593 luminance interpretation 815 * for RGB conversion. 816 */ 817 HAL_DATASPACE_STANDARD_BT2020 = 6 << HAL_DATASPACE_STANDARD_SHIFT, 818 819 /* 820 * Primaries: x y 821 * green 0.170 0.797 822 * blue 0.131 0.046 823 * red 0.708 0.292 824 * white (D65) 0.3127 0.3290 825 * 826 * Use the unadjusted KR = 0.2627, KB = 0.0593 luminance interpretation 827 * for RGB conversion using the linear domain. 828 */ 829 HAL_DATASPACE_STANDARD_BT2020_CONSTANT_LUMINANCE = 7 << HAL_DATASPACE_STANDARD_SHIFT, 830 831 /* 832 * Primaries: x y 833 * green 0.21 0.71 834 * blue 0.14 0.08 835 * red 0.67 0.33 836 * white (C) 0.310 0.316 837 * 838 * Use the unadjusted KR = 0.30, KB = 0.11 luminance interpretation 839 * for RGB conversion. 840 */ 841 HAL_DATASPACE_STANDARD_BT470M = 8 << HAL_DATASPACE_STANDARD_SHIFT, 842 843 /* 844 * Primaries: x y 845 * green 0.243 0.692 846 * blue 0.145 0.049 847 * red 0.681 0.319 848 * white (C) 0.310 0.316 849 * 850 * Use the unadjusted KR = 0.254, KB = 0.068 luminance interpretation 851 * for RGB conversion. 852 */ 853 HAL_DATASPACE_STANDARD_FILM = 9 << HAL_DATASPACE_STANDARD_SHIFT, 854 855 HAL_DATASPACE_TRANSFER_SHIFT = 22, 856 857 /* 858 * Transfer aspect 859 * 860 * Transfer characteristics are the opto-electronic transfer characteristic 861 * at the source as a function of linear optical intensity (luminance). 862 * 863 * For digital signals, E corresponds to the recorded value. Normally, the 864 * transfer function is applied in RGB space to each of the R, G and B 865 * components independently. This may result in color shift that can be 866 * minized by applying the transfer function in Lab space only for the L 867 * component. Implementation may apply the transfer function in RGB space 868 * for all pixel formats if desired. 869 */ 870 871 HAL_DATASPACE_TRANSFER_MASK = 31 << HAL_DATASPACE_TRANSFER_SHIFT, // 0x1F 872 873 /* 874 * Transfer characteristics are unknown or are determined by the 875 * application. 876 * 877 * Implementations should use the following transfer functions: 878 * 879 * For YCbCr formats: use HAL_DATASPACE_TRANSFER_SMPTE_170M 880 * For RGB formats: use HAL_DATASPACE_TRANSFER_SRGB 881 * 882 * For all other formats transfer function is undefined, and implementations 883 * should use an appropriate standard for the data represented. 884 */ 885 HAL_DATASPACE_TRANSFER_UNSPECIFIED = 0 << HAL_DATASPACE_TRANSFER_SHIFT, 886 887 /* 888 * Transfer characteristic curve: 889 * E = L 890 * L - luminance of image 0 <= L <= 1 for conventional colorimetry 891 * E - corresponding electrical signal 892 */ 893 HAL_DATASPACE_TRANSFER_LINEAR = 1 << HAL_DATASPACE_TRANSFER_SHIFT, 894 895 /* 896 * Transfer characteristic curve: 897 * 898 * E = 1.055 * L^(1/2.4) - 0.055 for 0.0031308 <= L <= 1 899 * = 12.92 * L for 0 <= L < 0.0031308 900 * L - luminance of image 0 <= L <= 1 for conventional colorimetry 901 * E - corresponding electrical signal 902 */ 903 HAL_DATASPACE_TRANSFER_SRGB = 2 << HAL_DATASPACE_TRANSFER_SHIFT, 904 905 /* 906 * BT.601 525, BT.601 625, BT.709, BT.2020 907 * 908 * Transfer characteristic curve: 909 * E = 1.099 * L ^ 0.45 - 0.099 for 0.018 <= L <= 1 910 * = 4.500 * L for 0 <= L < 0.018 911 * L - luminance of image 0 <= L <= 1 for conventional colorimetry 912 * E - corresponding electrical signal 913 */ 914 HAL_DATASPACE_TRANSFER_SMPTE_170M = 3 << HAL_DATASPACE_TRANSFER_SHIFT, 915 916 /* 917 * Assumed display gamma 2.2. 918 * 919 * Transfer characteristic curve: 920 * E = L ^ (1/2.2) 921 * L - luminance of image 0 <= L <= 1 for conventional colorimetry 922 * E - corresponding electrical signal 923 */ 924 HAL_DATASPACE_TRANSFER_GAMMA2_2 = 4 << HAL_DATASPACE_TRANSFER_SHIFT, 925 926 /* 927 * display gamma 2.8. 928 * 929 * Transfer characteristic curve: 930 * E = L ^ (1/2.8) 931 * L - luminance of image 0 <= L <= 1 for conventional colorimetry 932 * E - corresponding electrical signal 933 */ 934 HAL_DATASPACE_TRANSFER_GAMMA2_8 = 5 << HAL_DATASPACE_TRANSFER_SHIFT, 935 936 /* 937 * SMPTE ST 2084 938 * 939 * Transfer characteristic curve: 940 * E = ((c1 + c2 * L^n) / (1 + c3 * L^n)) ^ m 941 * c1 = c3 - c2 + 1 = 3424 / 4096 = 0.8359375 942 * c2 = 32 * 2413 / 4096 = 18.8515625 943 * c3 = 32 * 2392 / 4096 = 18.6875 944 * m = 128 * 2523 / 4096 = 78.84375 945 * n = 0.25 * 2610 / 4096 = 0.1593017578125 946 * L - luminance of image 0 <= L <= 1 for HDR colorimetry. 947 * L = 1 corresponds to 10000 cd/m2 948 * E - corresponding electrical signal 949 */ 950 HAL_DATASPACE_TRANSFER_ST2084 = 6 << HAL_DATASPACE_TRANSFER_SHIFT, 951 952 /* 953 * ARIB STD-B67 Hybrid Log Gamma 954 * 955 * Transfer characteristic curve: 956 * E = r * L^0.5 for 0 <= L <= 1 957 * = a * ln(L - b) + c for 1 < L 958 * a = 0.17883277 959 * b = 0.28466892 960 * c = 0.55991073 961 * r = 0.5 962 * L - luminance of image 0 <= L for HDR colorimetry. L = 1 corresponds 963 * to reference white level of 100 cd/m2 964 * E - corresponding electrical signal 965 */ 966 HAL_DATASPACE_TRANSFER_HLG = 7 << HAL_DATASPACE_TRANSFER_SHIFT, 967 968 HAL_DATASPACE_RANGE_SHIFT = 27, 969 970 /* 971 * Range aspect 972 * 973 * Defines the range of values corresponding to the unit range of 0-1. 974 * This is defined for YCbCr only, but can be expanded to RGB space. 975 */ 976 HAL_DATASPACE_RANGE_MASK = 7 << HAL_DATASPACE_RANGE_SHIFT, // 0x7 977 978 /* 979 * Range is unknown or are determined by the application. Implementations 980 * shall use the following suggested ranges: 981 * 982 * All YCbCr formats: limited range. 983 * All RGB or RGBA formats (including RAW and Bayer): full range. 984 * All Y formats: full range 985 * 986 * For all other formats range is undefined, and implementations should use 987 * an appropriate range for the data represented. 988 */ 989 HAL_DATASPACE_RANGE_UNSPECIFIED = 0 << HAL_DATASPACE_RANGE_SHIFT, 990 991 /* 992 * Full range uses all values for Y, Cb and Cr from 993 * 0 to 2^b-1, where b is the bit depth of the color format. 994 */ 995 HAL_DATASPACE_RANGE_FULL = 1 << HAL_DATASPACE_RANGE_SHIFT, 996 997 /* 998 * Limited range uses values 16/256*2^b to 235/256*2^b for Y, and 999 * 1/16*2^b to 15/16*2^b for Cb, Cr, R, G and B, where b is the bit depth of 1000 * the color format. 1001 * 1002 * E.g. For 8-bit-depth formats: 1003 * Luma (Y) samples should range from 16 to 235, inclusive 1004 * Chroma (Cb, Cr) samples should range from 16 to 240, inclusive 1005 * 1006 * For 10-bit-depth formats: 1007 * Luma (Y) samples should range from 64 to 940, inclusive 1008 * Chroma (Cb, Cr) samples should range from 64 to 960, inclusive 1009 */ 1010 HAL_DATASPACE_RANGE_LIMITED = 2 << HAL_DATASPACE_RANGE_SHIFT, 1011 1012 /* 1013 * Legacy dataspaces 1014 */ 1015 1016 /* 1017 * sRGB linear encoding: 1018 * 1019 * The red, green, and blue components are stored in sRGB space, but 1020 * are linear, not gamma-encoded. 1021 * The RGB primaries and the white point are the same as BT.709. 1022 * 1023 * The values are encoded using the full range ([0,255] for 8-bit) for all 1024 * components. 1025 */ 1026 HAL_DATASPACE_SRGB_LINEAR = 0x200, // deprecated, use HAL_DATASPACE_V0_SRGB_LINEAR 1027 1028 HAL_DATASPACE_V0_SRGB_LINEAR = HAL_DATASPACE_STANDARD_BT709 | 1029 HAL_DATASPACE_TRANSFER_LINEAR | HAL_DATASPACE_RANGE_FULL, 1030 1031 1032 /* 1033 * sRGB gamma encoding: 1034 * 1035 * The red, green and blue components are stored in sRGB space, and 1036 * converted to linear space when read, using the SRGB transfer function 1037 * for each of the R, G and B components. When written, the inverse 1038 * transformation is performed. 1039 * 1040 * The alpha component, if present, is always stored in linear space and 1041 * is left unmodified when read or written. 1042 * 1043 * Use full range and BT.709 standard. 1044 */ 1045 HAL_DATASPACE_SRGB = 0x201, // deprecated, use HAL_DATASPACE_V0_SRGB 1046 1047 HAL_DATASPACE_V0_SRGB = HAL_DATASPACE_STANDARD_BT709 | 1048 HAL_DATASPACE_TRANSFER_SRGB | HAL_DATASPACE_RANGE_FULL, 1049 1050 1051 /* 1052 * YCbCr Colorspaces 1053 * ----------------- 1054 * 1055 * Primaries are given using (x,y) coordinates in the CIE 1931 definition 1056 * of x and y specified by ISO 11664-1. 1057 * 1058 * Transfer characteristics are the opto-electronic transfer characteristic 1059 * at the source as a function of linear optical intensity (luminance). 1060 */ 1061 1062 /* 1063 * JPEG File Interchange Format (JFIF) 1064 * 1065 * Same model as BT.601-625, but all values (Y, Cb, Cr) range from 0 to 255 1066 * 1067 * Use full range, BT.601 transfer and BT.601_625 standard. 1068 */ 1069 HAL_DATASPACE_JFIF = 0x101, // deprecated, use HAL_DATASPACE_V0_JFIF 1070 1071 HAL_DATASPACE_V0_JFIF = HAL_DATASPACE_STANDARD_BT601_625 | 1072 HAL_DATASPACE_TRANSFER_SMPTE_170M | HAL_DATASPACE_RANGE_FULL, 1073 1074 /* 1075 * ITU-R Recommendation 601 (BT.601) - 625-line 1076 * 1077 * Standard-definition television, 625 Lines (PAL) 1078 * 1079 * Use limited range, BT.601 transfer and BT.601_625 standard. 1080 */ 1081 HAL_DATASPACE_BT601_625 = 0x102, // deprecated, use HAL_DATASPACE_V0_BT601_625 1082 1083 HAL_DATASPACE_V0_BT601_625 = HAL_DATASPACE_STANDARD_BT601_625 | 1084 HAL_DATASPACE_TRANSFER_SMPTE_170M | HAL_DATASPACE_RANGE_LIMITED, 1085 1086 1087 /* 1088 * ITU-R Recommendation 601 (BT.601) - 525-line 1089 * 1090 * Standard-definition television, 525 Lines (NTSC) 1091 * 1092 * Use limited range, BT.601 transfer and BT.601_525 standard. 1093 */ 1094 HAL_DATASPACE_BT601_525 = 0x103, // deprecated, use HAL_DATASPACE_V0_BT601_525 1095 1096 HAL_DATASPACE_V0_BT601_525 = HAL_DATASPACE_STANDARD_BT601_525 | 1097 HAL_DATASPACE_TRANSFER_SMPTE_170M | HAL_DATASPACE_RANGE_LIMITED, 1098 1099 /* 1100 * ITU-R Recommendation 709 (BT.709) 1101 * 1102 * High-definition television 1103 * 1104 * Use limited range, BT.709 transfer and BT.709 standard. 1105 */ 1106 HAL_DATASPACE_BT709 = 0x104, // deprecated, use HAL_DATASPACE_V0_BT709 1107 1108 HAL_DATASPACE_V0_BT709 = HAL_DATASPACE_STANDARD_BT709 | 1109 HAL_DATASPACE_TRANSFER_SMPTE_170M | HAL_DATASPACE_RANGE_LIMITED, 1110 1111 /* 1112 * Data spaces for non-color formats 1113 */ 1114 1115 /* 1116 * The buffer contains depth ranging measurements from a depth camera. 1117 * This value is valid with formats: 1118 * HAL_PIXEL_FORMAT_Y16: 16-bit samples, consisting of a depth measurement 1119 * and an associated confidence value. The 3 MSBs of the sample make 1120 * up the confidence value, and the low 13 LSBs of the sample make up 1121 * the depth measurement. 1122 * For the confidence section, 0 means 100% confidence, 1 means 0% 1123 * confidence. The mapping to a linear float confidence value between 1124 * 0.f and 1.f can be obtained with 1125 * float confidence = (((depthSample >> 13) - 1) & 0x7) / 7.0f; 1126 * The depth measurement can be extracted simply with 1127 * uint16_t range = (depthSample & 0x1FFF); 1128 * HAL_PIXEL_FORMAT_BLOB: A depth point cloud, as 1129 * a variable-length float (x,y,z, confidence) coordinate point list. 1130 * The point cloud will be represented with the android_depth_points 1131 * structure. 1132 */ 1133 HAL_DATASPACE_DEPTH = 0x1000 1134 1135 } android_dataspace_t; 1136 1137 /* 1138 * Color modes that may be supported by a display. 1139 * 1140 * Definitions: 1141 * Rendering intent generally defines the goal in mapping a source (input) 1142 * color to a destination device color for a given color mode. 1143 * 1144 * It is important to keep in mind three cases where mapping may be applied: 1145 * 1. The source gamut is much smaller than the destination (display) gamut 1146 * 2. The source gamut is much larger than the destination gamut (this will 1147 * ordinarily be handled using colorimetric rendering, below) 1148 * 3. The source and destination gamuts are roughly equal, although not 1149 * completely overlapping 1150 * Also, a common requirement for mappings is that skin tones should be 1151 * preserved, or at least remain natural in appearance. 1152 * 1153 * Colorimetric Rendering Intent (All cases): 1154 * Colorimetric indicates that colors should be preserved. In the case 1155 * that the source gamut lies wholly within the destination gamut or is 1156 * about the same (#1, #3), this will simply mean that no manipulations 1157 * (no saturation boost, for example) are applied. In the case where some 1158 * source colors lie outside the destination gamut (#2, #3), those will 1159 * need to be mapped to colors that are within the destination gamut, 1160 * while the already in-gamut colors remain unchanged. 1161 * 1162 * Non-colorimetric transforms can take many forms. There are no hard 1163 * rules and it's left to the implementation to define. 1164 * Two common intents are described below. 1165 * 1166 * Stretched-Gamut Enhancement Intent (Source < Destination): 1167 * When the destination gamut is much larger than the source gamut (#1), the 1168 * source primaries may be redefined to reflect the full extent of the 1169 * destination space, or to reflect an intermediate gamut. 1170 * Skin-tone preservation would likely be applied. An example might be sRGB 1171 * input displayed on a DCI-P3 capable device, with skin-tone preservation. 1172 * 1173 * Within-Gamut Enhancement Intent (Source >= Destination): 1174 * When the device (destination) gamut is not larger than the source gamut 1175 * (#2 or #3), but the appearance of a larger gamut is desired, techniques 1176 * such as saturation boost may be applied to the source colors. Skin-tone 1177 * preservation may be applied. There is no unique method for within-gamut 1178 * enhancement; it would be defined within a flexible color mode. 1179 * 1180 */ 1181 typedef enum android_color_mode { 1182 1183 /* 1184 * HAL_COLOR_MODE_DEFAULT is the "native" gamut of the display. 1185 * White Point: Vendor/OEM defined 1186 * Panel Gamma: Vendor/OEM defined (typically 2.2) 1187 * Rendering Intent: Vendor/OEM defined (typically 'enhanced') 1188 */ 1189 HAL_COLOR_MODE_NATIVE = 0, 1190 1191 /* 1192 * HAL_COLOR_MODE_STANDARD_BT601_625 corresponds with display 1193 * settings that implement the ITU-R Recommendation BT.601 1194 * or Rec 601. Using 625 line version 1195 * Rendering Intent: Colorimetric 1196 * Primaries: 1197 * x y 1198 * green 0.290 0.600 1199 * blue 0.150 0.060 1200 * red 0.640 0.330 1201 * white (D65) 0.3127 0.3290 1202 * 1203 * KR = 0.299, KB = 0.114. This adjusts the luminance interpretation 1204 * for RGB conversion from the one purely determined by the primaries 1205 * to minimize the color shift into RGB space that uses BT.709 1206 * primaries. 1207 * 1208 * Gamma Correction (GC): 1209 * 1210 * if Vlinear < 0.018 1211 * Vnonlinear = 4.500 * Vlinear 1212 * else 1213 * Vnonlinear = 1.099 * (Vlinear)^(0.45) – 0.099 1214 */ 1215 HAL_COLOR_MODE_STANDARD_BT601_625 = 1, 1216 1217 /* 1218 * Primaries: 1219 * x y 1220 * green 0.290 0.600 1221 * blue 0.150 0.060 1222 * red 0.640 0.330 1223 * white (D65) 0.3127 0.3290 1224 * 1225 * Use the unadjusted KR = 0.222, KB = 0.071 luminance interpretation 1226 * for RGB conversion. 1227 * 1228 * Gamma Correction (GC): 1229 * 1230 * if Vlinear < 0.018 1231 * Vnonlinear = 4.500 * Vlinear 1232 * else 1233 * Vnonlinear = 1.099 * (Vlinear)^(0.45) – 0.099 1234 */ 1235 HAL_COLOR_MODE_STANDARD_BT601_625_UNADJUSTED = 2, 1236 1237 /* 1238 * Primaries: 1239 * x y 1240 * green 0.310 0.595 1241 * blue 0.155 0.070 1242 * red 0.630 0.340 1243 * white (D65) 0.3127 0.3290 1244 * 1245 * KR = 0.299, KB = 0.114. This adjusts the luminance interpretation 1246 * for RGB conversion from the one purely determined by the primaries 1247 * to minimize the color shift into RGB space that uses BT.709 1248 * primaries. 1249 * 1250 * Gamma Correction (GC): 1251 * 1252 * if Vlinear < 0.018 1253 * Vnonlinear = 4.500 * Vlinear 1254 * else 1255 * Vnonlinear = 1.099 * (Vlinear)^(0.45) – 0.099 1256 */ 1257 HAL_COLOR_MODE_STANDARD_BT601_525 = 3, 1258 1259 /* 1260 * Primaries: 1261 * x y 1262 * green 0.310 0.595 1263 * blue 0.155 0.070 1264 * red 0.630 0.340 1265 * white (D65) 0.3127 0.3290 1266 * 1267 * Use the unadjusted KR = 0.212, KB = 0.087 luminance interpretation 1268 * for RGB conversion (as in SMPTE 240M). 1269 * 1270 * Gamma Correction (GC): 1271 * 1272 * if Vlinear < 0.018 1273 * Vnonlinear = 4.500 * Vlinear 1274 * else 1275 * Vnonlinear = 1.099 * (Vlinear)^(0.45) – 0.099 1276 */ 1277 HAL_COLOR_MODE_STANDARD_BT601_525_UNADJUSTED = 4, 1278 1279 /* 1280 * HAL_COLOR_MODE_REC709 corresponds with display settings that implement 1281 * the ITU-R Recommendation BT.709 / Rec. 709 for high-definition television. 1282 * Rendering Intent: Colorimetric 1283 * Primaries: 1284 * x y 1285 * green 0.300 0.600 1286 * blue 0.150 0.060 1287 * red 0.640 0.330 1288 * white (D65) 0.3127 0.3290 1289 * 1290 * HDTV REC709 Inverse Gamma Correction (IGC): V represents normalized 1291 * (with [0 to 1] range) value of R, G, or B. 1292 * 1293 * if Vnonlinear < 0.081 1294 * Vlinear = Vnonlinear / 4.5 1295 * else 1296 * Vlinear = ((Vnonlinear + 0.099) / 1.099) ^ (1/0.45) 1297 * 1298 * HDTV REC709 Gamma Correction (GC): 1299 * 1300 * if Vlinear < 0.018 1301 * Vnonlinear = 4.5 * Vlinear 1302 * else 1303 * Vnonlinear = 1.099 * (Vlinear) ^ 0.45 – 0.099 1304 */ 1305 HAL_COLOR_MODE_STANDARD_BT709 = 5, 1306 1307 /* 1308 * HAL_COLOR_MODE_DCI_P3 corresponds with display settings that implement 1309 * SMPTE EG 432-1 and SMPTE RP 431-2 1310 * Rendering Intent: Colorimetric 1311 * Primaries: 1312 * x y 1313 * green 0.265 0.690 1314 * blue 0.150 0.060 1315 * red 0.680 0.320 1316 * white (D65) 0.3127 0.3290 1317 * 1318 * Gamma: 2.2 1319 */ 1320 HAL_COLOR_MODE_DCI_P3 = 6, 1321 1322 /* 1323 * HAL_COLOR_MODE_SRGB corresponds with display settings that implement 1324 * the sRGB color space. Uses the same primaries as ITU-R Recommendation 1325 * BT.709 1326 * Rendering Intent: Colorimetric 1327 * Primaries: 1328 * x y 1329 * green 0.300 0.600 1330 * blue 0.150 0.060 1331 * red 0.640 0.330 1332 * white (D65) 0.3127 0.3290 1333 * 1334 * PC/Internet (sRGB) Inverse Gamma Correction (IGC): 1335 * 1336 * if Vnonlinear ≤ 0.03928 1337 * Vlinear = Vnonlinear / 12.92 1338 * else 1339 * Vlinear = ((Vnonlinear + 0.055)/1.055) ^ 2.4 1340 * 1341 * PC/Internet (sRGB) Gamma Correction (GC): 1342 * 1343 * if Vlinear ≤ 0.0031308 1344 * Vnonlinear = 12.92 * Vlinear 1345 * else 1346 * Vnonlinear = 1.055 * (Vlinear)^(1/2.4) – 0.055 1347 */ 1348 HAL_COLOR_MODE_SRGB = 7, 1349 1350 /* 1351 * HAL_COLOR_MODE_ADOBE_RGB corresponds with the RGB color space developed 1352 * by Adobe Systems, Inc. in 1998. 1353 * Rendering Intent: Colorimetric 1354 * Primaries: 1355 * x y 1356 * green 0.210 0.710 1357 * blue 0.150 0.060 1358 * red 0.640 0.330 1359 * white (D65) 0.3127 0.3290 1360 * 1361 * Gamma: 2.2 1362 */ 1363 HAL_COLOR_MODE_ADOBE_RGB = 8 1364 1365 } android_color_mode_t; 1366 1367 /* 1368 * Color transforms that may be applied by hardware composer to the whole 1369 * display. 1370 */ 1371 typedef enum android_color_transform { 1372 /* Applies no transform to the output color */ 1373 HAL_COLOR_TRANSFORM_IDENTITY = 0, 1374 1375 /* Applies an arbitrary transform defined by a 4x4 affine matrix */ 1376 HAL_COLOR_TRANSFORM_ARBITRARY_MATRIX = 1, 1377 1378 /* Applies a transform that inverts the value or luminance of the color, but 1379 * does not modify hue or saturation */ 1380 HAL_COLOR_TRANSFORM_VALUE_INVERSE = 2, 1381 1382 /* Applies a transform that maps all colors to shades of gray */ 1383 HAL_COLOR_TRANSFORM_GRAYSCALE = 3, 1384 1385 /* Applies a transform which corrects for protanopic color blindness */ 1386 HAL_COLOR_TRANSFORM_CORRECT_PROTANOPIA = 4, 1387 1388 /* Applies a transform which corrects for deuteranopic color blindness */ 1389 HAL_COLOR_TRANSFORM_CORRECT_DEUTERANOPIA = 5, 1390 1391 /* Applies a transform which corrects for tritanopic color blindness */ 1392 HAL_COLOR_TRANSFORM_CORRECT_TRITANOPIA = 6 1393 } android_color_transform_t; 1394 1395 /* 1396 * Supported HDR formats. Must be kept in sync with equivalents in Display.java. 1397 */ 1398 typedef enum android_hdr { 1399 /* Device supports Dolby Vision HDR */ 1400 HAL_HDR_DOLBY_VISION = 1, 1401 1402 /* Device supports HDR10 */ 1403 HAL_HDR_HDR10 = 2, 1404 1405 /* Device supports hybrid log-gamma HDR */ 1406 HAL_HDR_HLG = 3 1407 } android_hdr_t; 1408 1409 #ifdef __cplusplus 1410 } 1411 #endif 1412 1413 #endif /* SYSTEM_CORE_INCLUDE_ANDROID_GRAPHICS_H */ 1414