Iliyan Malchev | 66ea357 | 2011-05-01 14:05:30 -0700 | [diff] [blame] | 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 | |
Alex Ray | e13f15a | 2013-03-19 01:41:32 -0700 | [diff] [blame] | 20 | #include <stdint.h> |
| 21 | |
Mathias Agopian | c9b0695 | 2011-08-11 22:35:31 -0700 | [diff] [blame] | 22 | #ifdef __cplusplus |
| 23 | extern "C" { |
| 24 | #endif |
Iliyan Malchev | 66ea357 | 2011-05-01 14:05:30 -0700 | [diff] [blame] | 25 | |
Mathias Agopian | 5c9be40 | 2011-08-09 18:55:44 -0700 | [diff] [blame] | 26 | /* |
| 27 | * If the HAL needs to create service threads to handle graphics related |
| 28 | * tasks, these threads need to run at HAL_PRIORITY_URGENT_DISPLAY priority |
| 29 | * if they can block the main rendering thread in any way. |
| 30 | * |
| 31 | * the priority of the current thread can be set with: |
| 32 | * |
| 33 | * #include <sys/resource.h> |
| 34 | * setpriority(PRIO_PROCESS, 0, HAL_PRIORITY_URGENT_DISPLAY); |
| 35 | * |
| 36 | */ |
| 37 | |
| 38 | #define HAL_PRIORITY_URGENT_DISPLAY (-8) |
| 39 | |
Iliyan Malchev | 66ea357 | 2011-05-01 14:05:30 -0700 | [diff] [blame] | 40 | /** |
| 41 | * pixel format definitions |
| 42 | */ |
| 43 | |
| 44 | enum { |
Mathias Agopian | 8d9da28 | 2013-07-25 17:07:11 -0700 | [diff] [blame] | 45 | /* |
| 46 | * "linear" color pixel formats: |
| 47 | * |
Eino-Ville Talvala | 0374341 | 2015-02-17 15:34:44 -0800 | [diff] [blame] | 48 | * When used with ANativeWindow, the dataSpace field describes the color |
| 49 | * space of the buffer. |
| 50 | * |
| 51 | * The color space determines, for example, if the formats are linear or |
| 52 | * gamma-corrected; or whether any special operations are performed when |
| 53 | * reading or writing into a buffer in one of these formats. |
Mathias Agopian | 8d9da28 | 2013-07-25 17:07:11 -0700 | [diff] [blame] | 54 | */ |
Iliyan Malchev | 66ea357 | 2011-05-01 14:05:30 -0700 | [diff] [blame] | 55 | HAL_PIXEL_FORMAT_RGBA_8888 = 1, |
| 56 | HAL_PIXEL_FORMAT_RGBX_8888 = 2, |
| 57 | HAL_PIXEL_FORMAT_RGB_888 = 3, |
| 58 | HAL_PIXEL_FORMAT_RGB_565 = 4, |
| 59 | HAL_PIXEL_FORMAT_BGRA_8888 = 5, |
Iliyan Malchev | 66ea357 | 2011-05-01 14:05:30 -0700 | [diff] [blame] | 60 | |
Mathias Agopian | 8d9da28 | 2013-07-25 17:07:11 -0700 | [diff] [blame] | 61 | /* |
Iliyan Malchev | 66ea357 | 2011-05-01 14:05:30 -0700 | [diff] [blame] | 62 | * 0x100 - 0x1FF |
| 63 | * |
| 64 | * This range is reserved for pixel formats that are specific to the HAL |
| 65 | * implementation. Implementations can use any value in this range to |
| 66 | * communicate video pixel formats between their HAL modules. These formats |
| 67 | * must not have an alpha channel. Additionally, an EGLimage created from a |
| 68 | * gralloc buffer of one of these formats must be supported for use with the |
| 69 | * GL_OES_EGL_image_external OpenGL ES extension. |
| 70 | */ |
| 71 | |
| 72 | /* |
| 73 | * Android YUV format: |
| 74 | * |
Jamie Gennis | da1a1f6 | 2011-05-18 14:42:46 -0700 | [diff] [blame] | 75 | * This format is exposed outside of the HAL to software decoders and |
| 76 | * applications. EGLImageKHR must support it in conjunction with the |
Iliyan Malchev | 66ea357 | 2011-05-01 14:05:30 -0700 | [diff] [blame] | 77 | * OES_EGL_image_external extension. |
| 78 | * |
Jamie Gennis | da1a1f6 | 2011-05-18 14:42:46 -0700 | [diff] [blame] | 79 | * YV12 is a 4:2:0 YCrCb planar format comprised of a WxH Y plane followed |
Iliyan Malchev | 66ea357 | 2011-05-01 14:05:30 -0700 | [diff] [blame] | 80 | * by (W/2) x (H/2) Cr and Cb planes. |
| 81 | * |
| 82 | * This format assumes |
| 83 | * - an even width |
| 84 | * - an even height |
| 85 | * - a horizontal stride multiple of 16 pixels |
| 86 | * - a vertical stride equal to the height |
| 87 | * |
| 88 | * y_size = stride * height |
Jamie Gennis | 185b300 | 2012-04-30 12:50:38 -0700 | [diff] [blame] | 89 | * c_stride = ALIGN(stride/2, 16) |
| 90 | * c_size = c_stride * height/2 |
Iliyan Malchev | 66ea357 | 2011-05-01 14:05:30 -0700 | [diff] [blame] | 91 | * size = y_size + c_size * 2 |
| 92 | * cr_offset = y_size |
| 93 | * cb_offset = y_size + c_size |
| 94 | * |
Eino-Ville Talvala | 0374341 | 2015-02-17 15:34:44 -0800 | [diff] [blame] | 95 | * When used with ANativeWindow, the dataSpace field describes the color |
| 96 | * space of the buffer. |
Iliyan Malchev | 66ea357 | 2011-05-01 14:05:30 -0700 | [diff] [blame] | 97 | */ |
| 98 | HAL_PIXEL_FORMAT_YV12 = 0x32315659, // YCrCb 4:2:0 Planar |
| 99 | |
Igor Murashkin | 9e00e66 | 2013-01-31 17:17:43 -0800 | [diff] [blame] | 100 | |
| 101 | /* |
| 102 | * Android Y8 format: |
| 103 | * |
| 104 | * This format is exposed outside of the HAL to the framework. |
| 105 | * The expected gralloc usage flags are SW_* and HW_CAMERA_*, |
| 106 | * and no other HW_ flags will be used. |
| 107 | * |
| 108 | * Y8 is a YUV planar format comprised of a WxH Y plane, |
| 109 | * with each pixel being represented by 8 bits. |
| 110 | * |
| 111 | * It is equivalent to just the Y plane from YV12. |
| 112 | * |
| 113 | * This format assumes |
| 114 | * - an even width |
| 115 | * - an even height |
| 116 | * - a horizontal stride multiple of 16 pixels |
| 117 | * - a vertical stride equal to the height |
| 118 | * |
Igor Murashkin | d755b52 | 2013-02-11 11:34:53 -0800 | [diff] [blame] | 119 | * size = stride * height |
Igor Murashkin | 9e00e66 | 2013-01-31 17:17:43 -0800 | [diff] [blame] | 120 | * |
Eino-Ville Talvala | 0374341 | 2015-02-17 15:34:44 -0800 | [diff] [blame] | 121 | * When used with ANativeWindow, the dataSpace field describes the color |
| 122 | * space of the buffer. |
Igor Murashkin | 9e00e66 | 2013-01-31 17:17:43 -0800 | [diff] [blame] | 123 | */ |
| 124 | HAL_PIXEL_FORMAT_Y8 = 0x20203859, |
| 125 | |
| 126 | /* |
| 127 | * Android Y16 format: |
| 128 | * |
| 129 | * This format is exposed outside of the HAL to the framework. |
| 130 | * The expected gralloc usage flags are SW_* and HW_CAMERA_*, |
| 131 | * and no other HW_ flags will be used. |
| 132 | * |
| 133 | * Y16 is a YUV planar format comprised of a WxH Y plane, |
| 134 | * with each pixel being represented by 16 bits. |
| 135 | * |
| 136 | * It is just like Y8, but has double the bits per pixel (little endian). |
| 137 | * |
| 138 | * This format assumes |
| 139 | * - an even width |
| 140 | * - an even height |
| 141 | * - a horizontal stride multiple of 16 pixels |
| 142 | * - a vertical stride equal to the height |
| 143 | * - strides are specified in pixels, not in bytes |
| 144 | * |
Igor Murashkin | d755b52 | 2013-02-11 11:34:53 -0800 | [diff] [blame] | 145 | * size = stride * height * 2 |
Igor Murashkin | 9e00e66 | 2013-01-31 17:17:43 -0800 | [diff] [blame] | 146 | * |
Eino-Ville Talvala | 0374341 | 2015-02-17 15:34:44 -0800 | [diff] [blame] | 147 | * When used with ANativeWindow, the dataSpace field describes the color |
| 148 | * space of the buffer, except that dataSpace field |
| 149 | * HAL_DATASPACE_DEPTH indicates that this buffer contains a depth |
| 150 | * image where each sample is a distance value measured by a depth camera. |
Igor Murashkin | 9e00e66 | 2013-01-31 17:17:43 -0800 | [diff] [blame] | 151 | */ |
| 152 | HAL_PIXEL_FORMAT_Y16 = 0x20363159, |
| 153 | |
Eino-Ville Talvala | 0a85154 | 2012-04-10 15:10:50 -0700 | [diff] [blame] | 154 | /* |
| 155 | * Android RAW sensor format: |
| 156 | * |
Ruben Brunk | 535253e | 2014-02-04 18:13:34 -0800 | [diff] [blame] | 157 | * This format is exposed outside of the camera HAL to applications. |
Eino-Ville Talvala | 0a85154 | 2012-04-10 15:10:50 -0700 | [diff] [blame] | 158 | * |
Eino-Ville Talvala | 0374341 | 2015-02-17 15:34:44 -0800 | [diff] [blame] | 159 | * RAW16 is a single-channel, 16-bit, little endian format, typically |
Ruben Brunk | 535253e | 2014-02-04 18:13:34 -0800 | [diff] [blame] | 160 | * representing raw Bayer-pattern images from an image sensor, with minimal |
| 161 | * processing. |
Eino-Ville Talvala | 0a85154 | 2012-04-10 15:10:50 -0700 | [diff] [blame] | 162 | * |
| 163 | * The exact pixel layout of the data in the buffer is sensor-dependent, and |
| 164 | * needs to be queried from the camera device. |
| 165 | * |
| 166 | * Generally, not all 16 bits are used; more common values are 10 or 12 |
Ruben Brunk | 535253e | 2014-02-04 18:13:34 -0800 | [diff] [blame] | 167 | * bits. If not all bits are used, the lower-order bits are filled first. |
| 168 | * All parameters to interpret the raw data (black and white points, |
Eino-Ville Talvala | 0a85154 | 2012-04-10 15:10:50 -0700 | [diff] [blame] | 169 | * color space, etc) must be queried from the camera device. |
| 170 | * |
| 171 | * This format assumes |
| 172 | * - an even width |
| 173 | * - an even height |
Ruben Brunk | 535253e | 2014-02-04 18:13:34 -0800 | [diff] [blame] | 174 | * - a horizontal stride multiple of 16 pixels |
| 175 | * - a vertical stride equal to the height |
| 176 | * - strides are specified in pixels, not in bytes |
| 177 | * |
| 178 | * size = stride * height * 2 |
| 179 | * |
| 180 | * This format must be accepted by the gralloc module when used with the |
| 181 | * following usage flags: |
| 182 | * - GRALLOC_USAGE_HW_CAMERA_* |
| 183 | * - GRALLOC_USAGE_SW_* |
| 184 | * - GRALLOC_USAGE_RENDERSCRIPT |
Eino-Ville Talvala | 0374341 | 2015-02-17 15:34:44 -0800 | [diff] [blame] | 185 | * |
| 186 | * When used with ANativeWindow, the dataSpace should be |
| 187 | * HAL_DATASPACE_ARBITRARY, as raw image sensor buffers require substantial |
| 188 | * extra metadata to define. |
Eino-Ville Talvala | 0a85154 | 2012-04-10 15:10:50 -0700 | [diff] [blame] | 189 | */ |
Ruben Brunk | 535253e | 2014-02-04 18:13:34 -0800 | [diff] [blame] | 190 | HAL_PIXEL_FORMAT_RAW16 = 0x20, |
Ruben Brunk | 535253e | 2014-02-04 18:13:34 -0800 | [diff] [blame] | 191 | |
| 192 | /* |
Zhijun He | 72fce30 | 2014-06-23 17:14:42 -0700 | [diff] [blame] | 193 | * Android RAW10 format: |
| 194 | * |
| 195 | * This format is exposed outside of the camera HAL to applications. |
| 196 | * |
Zhijun He | c73b73a | 2014-07-25 08:07:48 -0700 | [diff] [blame] | 197 | * RAW10 is a single-channel, 10-bit per pixel, densely packed in each row, |
| 198 | * unprocessed format, usually representing raw Bayer-pattern images coming from |
| 199 | * an image sensor. |
Zhijun He | 72fce30 | 2014-06-23 17:14:42 -0700 | [diff] [blame] | 200 | * |
Zhijun He | c73b73a | 2014-07-25 08:07:48 -0700 | [diff] [blame] | 201 | * In an image buffer with this format, starting from the first pixel of each |
| 202 | * row, each 4 consecutive pixels are packed into 5 bytes (40 bits). Each one |
| 203 | * of the first 4 bytes contains the top 8 bits of each pixel, The fifth byte |
| 204 | * contains the 2 least significant bits of the 4 pixels, the exact layout data |
| 205 | * for each 4 consecutive pixels is illustrated below (Pi[j] stands for the jth |
| 206 | * bit of the ith pixel): |
Zhijun He | 72fce30 | 2014-06-23 17:14:42 -0700 | [diff] [blame] | 207 | * |
| 208 | * bit 7 bit 0 |
| 209 | * =====|=====|=====|=====|=====|=====|=====|=====| |
| 210 | * Byte 0: |P0[9]|P0[8]|P0[7]|P0[6]|P0[5]|P0[4]|P0[3]|P0[2]| |
| 211 | * |-----|-----|-----|-----|-----|-----|-----|-----| |
| 212 | * Byte 1: |P1[9]|P1[8]|P1[7]|P1[6]|P1[5]|P1[4]|P1[3]|P1[2]| |
| 213 | * |-----|-----|-----|-----|-----|-----|-----|-----| |
| 214 | * Byte 2: |P2[9]|P2[8]|P2[7]|P2[6]|P2[5]|P2[4]|P2[3]|P2[2]| |
| 215 | * |-----|-----|-----|-----|-----|-----|-----|-----| |
| 216 | * Byte 3: |P3[9]|P3[8]|P3[7]|P3[6]|P3[5]|P3[4]|P3[3]|P3[2]| |
| 217 | * |-----|-----|-----|-----|-----|-----|-----|-----| |
| 218 | * Byte 4: |P3[1]|P3[0]|P2[1]|P2[0]|P1[1]|P1[0]|P0[1]|P0[0]| |
| 219 | * =============================================== |
| 220 | * |
| 221 | * This format assumes |
| 222 | * - a width multiple of 4 pixels |
| 223 | * - an even height |
Zhijun He | 72fce30 | 2014-06-23 17:14:42 -0700 | [diff] [blame] | 224 | * - a vertical stride equal to the height |
Zhijun He | c73b73a | 2014-07-25 08:07:48 -0700 | [diff] [blame] | 225 | * - strides are specified in bytes, not in pixels |
Zhijun He | 72fce30 | 2014-06-23 17:14:42 -0700 | [diff] [blame] | 226 | * |
Zhijun He | c73b73a | 2014-07-25 08:07:48 -0700 | [diff] [blame] | 227 | * size = stride * height |
| 228 | * |
| 229 | * When stride is equal to width * (10 / 8), there will be no padding bytes at |
| 230 | * the end of each row, the entire image data is densely packed. When stride is |
| 231 | * larger than width * (10 / 8), padding bytes will be present at the end of each |
| 232 | * row (including the last row). |
Zhijun He | 72fce30 | 2014-06-23 17:14:42 -0700 | [diff] [blame] | 233 | * |
| 234 | * This format must be accepted by the gralloc module when used with the |
| 235 | * following usage flags: |
| 236 | * - GRALLOC_USAGE_HW_CAMERA_* |
| 237 | * - GRALLOC_USAGE_SW_* |
| 238 | * - GRALLOC_USAGE_RENDERSCRIPT |
Eino-Ville Talvala | 0374341 | 2015-02-17 15:34:44 -0800 | [diff] [blame] | 239 | * |
| 240 | * When used with ANativeWindow, the dataSpace field should be |
| 241 | * HAL_DATASPACE_ARBITRARY, as raw image sensor buffers require substantial |
| 242 | * extra metadata to define. |
Zhijun He | 72fce30 | 2014-06-23 17:14:42 -0700 | [diff] [blame] | 243 | */ |
| 244 | HAL_PIXEL_FORMAT_RAW10 = 0x25, |
| 245 | |
| 246 | /* |
Yin-Chia Yeh | 9a5eeba | 2015-03-20 15:43:09 -0700 | [diff] [blame^] | 247 | * Android RAW12 format: |
| 248 | * |
| 249 | * This format is exposed outside of camera HAL to applications. |
| 250 | * |
| 251 | * RAW12 is a single-channel, 12-bit per pixel, densely packed in each row, |
| 252 | * unprocessed format, usually representing raw Bayer-pattern images coming from |
| 253 | * an image sensor. |
| 254 | * |
| 255 | * In an image buffer with this format, starting from the first pixel of each |
| 256 | * row, each two consecutive pixels are packed into 3 bytes (24 bits). The first |
| 257 | * and second byte contains the top 8 bits of first and second pixel. The third |
| 258 | * byte contains the 4 least significant bits of the two pixels, the exact layout |
| 259 | * data for each two consecutive pixels is illustrated below (Pi[j] stands for |
| 260 | * the jth bit of the ith pixel): |
| 261 | * |
| 262 | * bit 7 bit 0 |
| 263 | * ======|======|======|======|======|======|======|======| |
| 264 | * Byte 0: |P0[11]|P0[10]|P0[ 9]|P0[ 8]|P0[ 7]|P0[ 6]|P0[ 5]|P0[ 4]| |
| 265 | * |------|------|------|------|------|------|------|------| |
| 266 | * Byte 1: |P1[11]|P1[10]|P1[ 9]|P1[ 8]|P1[ 7]|P1[ 6]|P1[ 5]|P1[ 4]| |
| 267 | * |------|------|------|------|------|------|------|------| |
| 268 | * Byte 2: |P1[ 3]|P1[ 2]|P1[ 1]|P1[ 0]|P0[ 3]|P0[ 2]|P0[ 1]|P0[ 0]| |
| 269 | * ======================================================= |
| 270 | * |
| 271 | * This format assumes: |
| 272 | * - a width multiple of 4 pixels |
| 273 | * - an even height |
| 274 | * - a vertical stride equal to the height |
| 275 | * - strides are specified in bytes, not in pixels |
| 276 | * |
| 277 | * size = stride * height |
| 278 | * |
| 279 | * When stride is equal to width * (12 / 8), there will be no padding bytes at |
| 280 | * the end of each row, the entire image data is densely packed. When stride is |
| 281 | * larger than width * (12 / 8), padding bytes will be present at the end of |
| 282 | * each row (including the last row). |
| 283 | * |
| 284 | * This format must be accepted by the gralloc module when used with the |
| 285 | * following usage flags: |
| 286 | * - GRALLOC_USAGE_HW_CAMERA_* |
| 287 | * - GRALLOC_USAGE_SW_* |
| 288 | * - GRALLOC_USAGE_RENDERSCRIPT |
| 289 | * |
| 290 | * When used with ANativeWindow, the dataSpace field should be |
| 291 | * HAL_DATASPACE_ARBITRARY, as raw image sensor buffers require substantial |
| 292 | * extra metadata to define. |
| 293 | */ |
| 294 | HAL_PIXEL_FORMAT_RAW12 = 0x26, |
| 295 | |
| 296 | /* |
Ruben Brunk | 535253e | 2014-02-04 18:13:34 -0800 | [diff] [blame] | 297 | * Android opaque RAW format: |
| 298 | * |
| 299 | * This format is exposed outside of the camera HAL to applications. |
| 300 | * |
| 301 | * RAW_OPAQUE is a format for unprocessed raw image buffers coming from an |
| 302 | * image sensor. The actual structure of buffers of this format is |
| 303 | * implementation-dependent. |
| 304 | * |
| 305 | * This format must be accepted by the gralloc module when used with the |
| 306 | * following usage flags: |
| 307 | * - GRALLOC_USAGE_HW_CAMERA_* |
| 308 | * - GRALLOC_USAGE_SW_* |
| 309 | * - GRALLOC_USAGE_RENDERSCRIPT |
Eino-Ville Talvala | 0374341 | 2015-02-17 15:34:44 -0800 | [diff] [blame] | 310 | * |
| 311 | * When used with ANativeWindow, the dataSpace field should be |
| 312 | * HAL_DATASPACE_ARBITRARY, as raw image sensor buffers require substantial |
| 313 | * extra metadata to define. |
Ruben Brunk | 535253e | 2014-02-04 18:13:34 -0800 | [diff] [blame] | 314 | */ |
| 315 | HAL_PIXEL_FORMAT_RAW_OPAQUE = 0x24, |
Iliyan Malchev | 66ea357 | 2011-05-01 14:05:30 -0700 | [diff] [blame] | 316 | |
Eino-Ville Talvala | 0a05248 | 2012-06-07 17:52:15 -0700 | [diff] [blame] | 317 | /* |
| 318 | * Android binary blob graphics buffer format: |
| 319 | * |
| 320 | * This format is used to carry task-specific data which does not have a |
| 321 | * standard image structure. The details of the format are left to the two |
| 322 | * endpoints. |
| 323 | * |
| 324 | * A typical use case is for transporting JPEG-compressed images from the |
| 325 | * Camera HAL to the framework or to applications. |
| 326 | * |
| 327 | * Buffers of this format must have a height of 1, and width equal to their |
| 328 | * size in bytes. |
Eino-Ville Talvala | 0374341 | 2015-02-17 15:34:44 -0800 | [diff] [blame] | 329 | * |
| 330 | * When used with ANativeWindow, the mapping of the dataSpace field to |
| 331 | * buffer contents for BLOB is as follows: |
| 332 | * |
| 333 | * dataSpace value | Buffer contents |
| 334 | * -------------------------------+----------------------------------------- |
| 335 | * HAL_DATASPACE_JFIF | An encoded JPEG image |
| 336 | * HAL_DATASPACE_DEPTH | An android_depth_points buffer |
| 337 | * Other | Unsupported |
| 338 | * |
Eino-Ville Talvala | 0a05248 | 2012-06-07 17:52:15 -0700 | [diff] [blame] | 339 | */ |
| 340 | HAL_PIXEL_FORMAT_BLOB = 0x21, |
| 341 | |
Jamie Gennis | febe9d9 | 2012-08-22 14:44:51 -0700 | [diff] [blame] | 342 | /* |
| 343 | * Android format indicating that the choice of format is entirely up to the |
| 344 | * device-specific Gralloc implementation. |
| 345 | * |
| 346 | * The Gralloc implementation should examine the usage bits passed in when |
| 347 | * allocating a buffer with this format, and it should derive the pixel |
| 348 | * format from those usage flags. This format will never be used with any |
| 349 | * of the GRALLOC_USAGE_SW_* usage flags. |
| 350 | * |
| 351 | * If a buffer of this format is to be used as an OpenGL ES texture, the |
| 352 | * framework will assume that sampling the texture will always return an |
| 353 | * alpha value of 1.0 (i.e. the buffer contains only opaque pixel values). |
| 354 | * |
Eino-Ville Talvala | 0374341 | 2015-02-17 15:34:44 -0800 | [diff] [blame] | 355 | * When used with ANativeWindow, the dataSpace field describes the color |
| 356 | * space of the buffer. |
Jamie Gennis | febe9d9 | 2012-08-22 14:44:51 -0700 | [diff] [blame] | 357 | */ |
| 358 | HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED = 0x22, |
| 359 | |
Alex Ray | e13f15a | 2013-03-19 01:41:32 -0700 | [diff] [blame] | 360 | /* |
| 361 | * Android flexible YCbCr formats |
| 362 | * |
| 363 | * This format allows platforms to use an efficient YCbCr/YCrCb buffer |
| 364 | * layout, while still describing the buffer layout in a way accessible to |
| 365 | * the CPU in a device-independent manner. While called YCbCr, it can be |
| 366 | * used to describe formats with either chromatic ordering, as well as |
| 367 | * whole planar or semiplanar layouts. |
| 368 | * |
| 369 | * struct android_ycbcr (below) is the the struct used to describe it. |
| 370 | * |
| 371 | * This format must be accepted by the gralloc module when |
| 372 | * USAGE_HW_CAMERA_WRITE and USAGE_SW_READ_* are set. |
| 373 | * |
| 374 | * This format is locked for use by gralloc's (*lock_ycbcr) method, and |
| 375 | * locking with the (*lock) method will return an error. |
Eino-Ville Talvala | 0374341 | 2015-02-17 15:34:44 -0800 | [diff] [blame] | 376 | * |
| 377 | * When used with ANativeWindow, the dataSpace field describes the color |
| 378 | * space of the buffer. |
Alex Ray | e13f15a | 2013-03-19 01:41:32 -0700 | [diff] [blame] | 379 | */ |
| 380 | HAL_PIXEL_FORMAT_YCbCr_420_888 = 0x23, |
| 381 | |
Iliyan Malchev | 66ea357 | 2011-05-01 14:05:30 -0700 | [diff] [blame] | 382 | /* Legacy formats (deprecated), used by ImageFormat.java */ |
| 383 | HAL_PIXEL_FORMAT_YCbCr_422_SP = 0x10, // NV16 |
| 384 | HAL_PIXEL_FORMAT_YCrCb_420_SP = 0x11, // NV21 |
| 385 | HAL_PIXEL_FORMAT_YCbCr_422_I = 0x14, // YUY2 |
| 386 | }; |
| 387 | |
Alex Ray | e13f15a | 2013-03-19 01:41:32 -0700 | [diff] [blame] | 388 | /* |
| 389 | * Structure for describing YCbCr formats for consumption by applications. |
| 390 | * This is used with HAL_PIXEL_FORMAT_YCbCr_*_888. |
| 391 | * |
| 392 | * Buffer chroma subsampling is defined in the format. |
| 393 | * e.g. HAL_PIXEL_FORMAT_YCbCr_420_888 has subsampling 4:2:0. |
| 394 | * |
| 395 | * Buffers must have a 8 bit depth. |
| 396 | * |
| 397 | * @y, @cb, and @cr point to the first byte of their respective planes. |
| 398 | * |
| 399 | * Stride describes the distance in bytes from the first value of one row of |
| 400 | * the image to the first value of the next row. It includes the width of the |
| 401 | * image plus padding. |
| 402 | * @ystride is the stride of the luma plane. |
| 403 | * @cstride is the stride of the chroma planes. |
| 404 | * |
| 405 | * @chroma_step is the distance in bytes from one chroma pixel value to the |
| 406 | * next. This is 2 bytes for semiplanar (because chroma values are interleaved |
| 407 | * and each chroma value is one byte) and 1 for planar. |
| 408 | */ |
| 409 | |
| 410 | struct android_ycbcr { |
| 411 | void *y; |
| 412 | void *cb; |
| 413 | void *cr; |
| 414 | size_t ystride; |
| 415 | size_t cstride; |
| 416 | size_t chroma_step; |
| 417 | |
| 418 | /** reserved for future use, set to 0 by gralloc's (*lock_ycbcr)() */ |
| 419 | uint32_t reserved[8]; |
| 420 | }; |
Iliyan Malchev | 66ea357 | 2011-05-01 14:05:30 -0700 | [diff] [blame] | 421 | |
| 422 | /** |
Eino-Ville Talvala | 0374341 | 2015-02-17 15:34:44 -0800 | [diff] [blame] | 423 | * Structure used to define depth point clouds for format HAL_PIXEL_FORMAT_BLOB |
| 424 | * with dataSpace value of HAL_DATASPACE_DEPTH. |
| 425 | * When locking a native buffer of the above format and dataSpace value, |
| 426 | * the vaddr pointer can be cast to this structure. |
| 427 | * |
| 428 | * A variable-length list of (x,y,z) 3D points, as floats. |
| 429 | * |
| 430 | * @num_points is the number of points in the list |
| 431 | * |
| 432 | * @xyz_points is the flexible array of floating-point values. |
| 433 | * It contains (num_points) * 3 floats. |
| 434 | * |
| 435 | * For example: |
| 436 | * android_depth_points d = get_depth_buffer(); |
| 437 | * struct { |
| 438 | * float x; float y; float z; |
| 439 | * } firstPoint, lastPoint; |
| 440 | * |
| 441 | * firstPoint.x = d.xyz_points[0]; |
| 442 | * firstPoint.y = d.xyz_points[1]; |
| 443 | * firstPoint.z = d.xyz_points[2]; |
| 444 | * lastPoint.x = d.xyz_points[(d.num_points - 1) * 3 + 0]; |
| 445 | * lastPoint.y = d.xyz_points[(d.num_points - 1) * 3 + 1]; |
| 446 | * lastPoint.z = d.xyz_points[(d.num_points - 1) * 3 + 2]; |
| 447 | */ |
| 448 | |
| 449 | struct android_depth_points { |
| 450 | uint32_t num_points; |
| 451 | |
| 452 | /** reserved for future use, set to 0 by gralloc's (*lock)() */ |
| 453 | uint32_t reserved[8]; |
| 454 | |
| 455 | float xyz_points[]; |
| 456 | }; |
| 457 | |
| 458 | /** |
Iliyan Malchev | 66ea357 | 2011-05-01 14:05:30 -0700 | [diff] [blame] | 459 | * Transformation definitions |
| 460 | * |
| 461 | * IMPORTANT NOTE: |
| 462 | * HAL_TRANSFORM_ROT_90 is applied CLOCKWISE and AFTER HAL_TRANSFORM_FLIP_{H|V}. |
| 463 | * |
| 464 | */ |
| 465 | |
| 466 | enum { |
| 467 | /* flip source image horizontally (around the vertical axis) */ |
| 468 | HAL_TRANSFORM_FLIP_H = 0x01, |
| 469 | /* flip source image vertically (around the horizontal axis)*/ |
| 470 | HAL_TRANSFORM_FLIP_V = 0x02, |
| 471 | /* rotate source image 90 degrees clockwise */ |
| 472 | HAL_TRANSFORM_ROT_90 = 0x04, |
| 473 | /* rotate source image 180 degrees */ |
| 474 | HAL_TRANSFORM_ROT_180 = 0x03, |
| 475 | /* rotate source image 270 degrees clockwise */ |
| 476 | HAL_TRANSFORM_ROT_270 = 0x07, |
Mathias Agopian | 96675ed | 2013-09-17 23:48:54 -0700 | [diff] [blame] | 477 | /* don't use. see system/window.h */ |
| 478 | HAL_TRANSFORM_RESERVED = 0x08, |
Iliyan Malchev | 66ea357 | 2011-05-01 14:05:30 -0700 | [diff] [blame] | 479 | }; |
| 480 | |
Alex Ray | c9f3bcf | 2013-11-26 16:50:46 -0800 | [diff] [blame] | 481 | /** |
Eino-Ville Talvala | 0374341 | 2015-02-17 15:34:44 -0800 | [diff] [blame] | 482 | * Dataspace Definitions |
Alex Ray | c9f3bcf | 2013-11-26 16:50:46 -0800 | [diff] [blame] | 483 | * ====================== |
| 484 | * |
Eino-Ville Talvala | 0374341 | 2015-02-17 15:34:44 -0800 | [diff] [blame] | 485 | * Dataspace is the definition of how pixel values should be interpreted. |
| 486 | * |
| 487 | * For many formats, this is the colorspace of the image data, which includes |
| 488 | * primaries (including white point) and the transfer characteristic function, |
| 489 | * which describes both gamma curve and numeric range (within the bit depth). |
| 490 | * |
| 491 | * Other dataspaces include depth measurement data from a depth camera. |
Alex Ray | c9f3bcf | 2013-11-26 16:50:46 -0800 | [diff] [blame] | 492 | */ |
| 493 | |
Eino-Ville Talvala | 0374341 | 2015-02-17 15:34:44 -0800 | [diff] [blame] | 494 | typedef enum android_dataspace { |
Alex Ray | c9f3bcf | 2013-11-26 16:50:46 -0800 | [diff] [blame] | 495 | /* |
Eino-Ville Talvala | 0374341 | 2015-02-17 15:34:44 -0800 | [diff] [blame] | 496 | * Default-assumption data space, when not explicitly specified. |
| 497 | * |
| 498 | * It is safest to assume the buffer is an image with sRGB primaries and |
| 499 | * encoding ranges, but the consumer and/or the producer of the data may |
| 500 | * simply be using defaults. No automatic gamma transform should be |
| 501 | * expected, except for a possible display gamma transform when drawn to a |
| 502 | * screen. |
| 503 | */ |
| 504 | HAL_DATASPACE_UNKNOWN = 0x0, |
| 505 | |
| 506 | /* |
| 507 | * Arbitrary dataspace with manually defined characteristics. Definition |
| 508 | * for colorspaces or other meaning must be communicated separately. |
Alex Ray | c9f3bcf | 2013-11-26 16:50:46 -0800 | [diff] [blame] | 509 | * |
| 510 | * This is used when specifying primaries, transfer characteristics, |
| 511 | * etc. separately. |
| 512 | * |
| 513 | * A typical use case is in video encoding parameters (e.g. for H.264), |
| 514 | * where a colorspace can have separately defined primaries, transfer |
| 515 | * characteristics, etc. |
| 516 | */ |
Eino-Ville Talvala | 0374341 | 2015-02-17 15:34:44 -0800 | [diff] [blame] | 517 | HAL_DATASPACE_ARBITRARY = 0x1, |
| 518 | |
| 519 | /* |
| 520 | * RGB Colorspaces |
| 521 | * ----------------- |
| 522 | * |
| 523 | * Primaries are given using (x,y) coordinates in the CIE 1931 definition |
| 524 | * of x and y specified by ISO 11664-1. |
| 525 | * |
| 526 | * Transfer characteristics are the opto-electronic transfer characteristic |
| 527 | * at the source as a function of linear optical intensity (luminance). |
| 528 | */ |
| 529 | |
| 530 | /* |
| 531 | * sRGB linear encoding: |
| 532 | * |
| 533 | * The red, green, and blue components are stored in sRGB space, but |
| 534 | * are linear, not gamma-encoded. |
| 535 | * The RGB primaries and the white point are the same as BT.709. |
| 536 | * |
| 537 | * The values are encoded using the full range ([0,255] for 8-bit) for all |
| 538 | * components. |
| 539 | */ |
| 540 | HAL_DATASPACE_SRGB_LINEAR = 0x200, |
| 541 | |
| 542 | /* |
| 543 | * sRGB gamma encoding: |
| 544 | * |
| 545 | * The red, green and blue components are stored in sRGB space, and |
| 546 | * converted to linear space when read, using the standard sRGB to linear |
| 547 | * equation: |
| 548 | * |
| 549 | * Clinear = Csrgb / 12.92 for Csrgb <= 0.04045 |
| 550 | * = (Csrgb + 0.055 / 1.055)^2.4 for Csrgb > 0.04045 |
| 551 | * |
| 552 | * When written the inverse transformation is performed: |
| 553 | * |
| 554 | * Csrgb = 12.92 * Clinear for Clinear <= 0.0031308 |
| 555 | * = 1.055 * Clinear^(1/2.4) - 0.055 for Clinear > 0.0031308 |
| 556 | * |
| 557 | * |
| 558 | * The alpha component, if present, is always stored in linear space and |
| 559 | * is left unmodified when read or written. |
| 560 | * |
| 561 | * The RGB primaries and the white point are the same as BT.709. |
| 562 | * |
| 563 | * The values are encoded using the full range ([0,255] for 8-bit) for all |
| 564 | * components. |
| 565 | * |
| 566 | */ |
| 567 | HAL_DATASPACE_SRGB = 0x201, |
Alex Ray | c9f3bcf | 2013-11-26 16:50:46 -0800 | [diff] [blame] | 568 | |
| 569 | /* |
| 570 | * YCbCr Colorspaces |
| 571 | * ----------------- |
| 572 | * |
| 573 | * Primaries are given using (x,y) coordinates in the CIE 1931 definition |
| 574 | * of x and y specified by ISO 11664-1. |
| 575 | * |
| 576 | * Transfer characteristics are the opto-electronic transfer characteristic |
| 577 | * at the source as a function of linear optical intensity (luminance). |
| 578 | */ |
| 579 | |
| 580 | /* |
| 581 | * JPEG File Interchange Format (JFIF) |
| 582 | * |
| 583 | * Same model as BT.601-625, but all values (Y, Cb, Cr) range from 0 to 255 |
| 584 | * |
| 585 | * Transfer characteristic curve: |
| 586 | * E = 1.099 * L ^ 0.45 - 0.099, 1.00 >= L >= 0.018 |
| 587 | * E = 4.500 L, 0.018 > L >= 0 |
| 588 | * L - luminance of image 0 <= L <= 1 for conventional colorimetry |
| 589 | * E - corresponding electrical signal |
| 590 | * |
| 591 | * Primaries: x y |
| 592 | * green 0.290 0.600 |
| 593 | * blue 0.150 0.060 |
| 594 | * red 0.640 0.330 |
| 595 | * white (D65) 0.3127 0.3290 |
| 596 | */ |
Eino-Ville Talvala | 0374341 | 2015-02-17 15:34:44 -0800 | [diff] [blame] | 597 | HAL_DATASPACE_JFIF = 0x101, |
Alex Ray | c9f3bcf | 2013-11-26 16:50:46 -0800 | [diff] [blame] | 598 | |
| 599 | /* |
| 600 | * ITU-R Recommendation 601 (BT.601) - 625-line |
| 601 | * |
| 602 | * Standard-definition television, 625 Lines (PAL) |
| 603 | * |
| 604 | * For 8-bit-depth formats: |
| 605 | * Luma (Y) samples should range from 16 to 235, inclusive |
| 606 | * Chroma (Cb, Cr) samples should range from 16 to 240, inclusive |
| 607 | * |
| 608 | * For 10-bit-depth formats: |
| 609 | * Luma (Y) samples should range from 64 to 940, inclusive |
| 610 | * Chroma (Cb, Cr) samples should range from 64 to 960, inclusive |
| 611 | * |
| 612 | * Transfer characteristic curve: |
| 613 | * E = 1.099 * L ^ 0.45 - 0.099, 1.00 >= L >= 0.018 |
| 614 | * E = 4.500 L, 0.018 > L >= 0 |
| 615 | * L - luminance of image 0 <= L <= 1 for conventional colorimetry |
| 616 | * E - corresponding electrical signal |
| 617 | * |
| 618 | * Primaries: x y |
| 619 | * green 0.290 0.600 |
| 620 | * blue 0.150 0.060 |
| 621 | * red 0.640 0.330 |
| 622 | * white (D65) 0.3127 0.3290 |
| 623 | */ |
Eino-Ville Talvala | 0374341 | 2015-02-17 15:34:44 -0800 | [diff] [blame] | 624 | HAL_DATASPACE_BT601_625 = 0x102, |
Alex Ray | c9f3bcf | 2013-11-26 16:50:46 -0800 | [diff] [blame] | 625 | |
| 626 | /* |
| 627 | * ITU-R Recommendation 601 (BT.601) - 525-line |
| 628 | * |
| 629 | * Standard-definition television, 525 Lines (NTSC) |
| 630 | * |
| 631 | * For 8-bit-depth formats: |
| 632 | * Luma (Y) samples should range from 16 to 235, inclusive |
| 633 | * Chroma (Cb, Cr) samples should range from 16 to 240, inclusive |
| 634 | * |
| 635 | * For 10-bit-depth formats: |
| 636 | * Luma (Y) samples should range from 64 to 940, inclusive |
| 637 | * Chroma (Cb, Cr) samples should range from 64 to 960, inclusive |
| 638 | * |
| 639 | * Transfer characteristic curve: |
| 640 | * E = 1.099 * L ^ 0.45 - 0.099, 1.00 >= L >= 0.018 |
| 641 | * E = 4.500 L, 0.018 > L >= 0 |
| 642 | * L - luminance of image 0 <= L <= 1 for conventional colorimetry |
| 643 | * E - corresponding electrical signal |
| 644 | * |
| 645 | * Primaries: x y |
| 646 | * green 0.310 0.595 |
| 647 | * blue 0.155 0.070 |
| 648 | * red 0.630 0.340 |
| 649 | * white (D65) 0.3127 0.3290 |
| 650 | */ |
Eino-Ville Talvala | 0374341 | 2015-02-17 15:34:44 -0800 | [diff] [blame] | 651 | HAL_DATASPACE_BT601_525 = 0x103, |
Alex Ray | c9f3bcf | 2013-11-26 16:50:46 -0800 | [diff] [blame] | 652 | |
| 653 | /* |
| 654 | * ITU-R Recommendation 709 (BT.709) |
| 655 | * |
| 656 | * High-definition television |
| 657 | * |
| 658 | * For 8-bit-depth formats: |
| 659 | * Luma (Y) samples should range from 16 to 235, inclusive |
| 660 | * Chroma (Cb, Cr) samples should range from 16 to 240, inclusive |
| 661 | * |
| 662 | * For 10-bit-depth formats: |
| 663 | * Luma (Y) samples should range from 64 to 940, inclusive |
| 664 | * Chroma (Cb, Cr) samples should range from 64 to 960, inclusive |
| 665 | * |
| 666 | * Primaries: x y |
| 667 | * green 0.300 0.600 |
| 668 | * blue 0.150 0.060 |
| 669 | * red 0.640 0.330 |
| 670 | * white (D65) 0.3127 0.3290 |
| 671 | */ |
Eino-Ville Talvala | 0374341 | 2015-02-17 15:34:44 -0800 | [diff] [blame] | 672 | HAL_DATASPACE_BT709 = 0x104, |
| 673 | |
| 674 | /* |
| 675 | * The buffer contains depth ranging measurements from a depth camera. |
| 676 | * This value is valid with formats: |
| 677 | * HAL_PIXEL_FORMAT_Y16: 16-bit single channel depth image. |
| 678 | * HAL_PIXEL_FORMAT_BLOB: A depth point cloud, as |
| 679 | * a variable-length float (x,y,z) coordinate point list. |
| 680 | * The point cloud will be represented with the android_depth_points |
| 681 | * structure. |
| 682 | */ |
| 683 | HAL_DATASPACE_DEPTH = 0x1000 |
| 684 | |
| 685 | } android_dataspace_t; |
Alex Ray | c9f3bcf | 2013-11-26 16:50:46 -0800 | [diff] [blame] | 686 | |
Mathias Agopian | c9b0695 | 2011-08-11 22:35:31 -0700 | [diff] [blame] | 687 | #ifdef __cplusplus |
| 688 | } |
| 689 | #endif |
Iliyan Malchev | 66ea357 | 2011-05-01 14:05:30 -0700 | [diff] [blame] | 690 | |
| 691 | #endif /* SYSTEM_CORE_INCLUDE_ANDROID_GRAPHICS_H */ |