blob: ae10fa095c8cbb04c5f3935b55be94b8b90d270f [file] [log] [blame]
Iliyan Malchev66ea3572011-05-01 14:05:30 -07001/*
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
Mattias Nissler9cf80c62016-02-03 22:20:06 +010020#include <stddef.h>
Alex Raye13f15a2013-03-19 01:41:32 -070021#include <stdint.h>
22
Mathias Agopianc9b06952011-08-11 22:35:31 -070023#ifdef __cplusplus
24extern "C" {
25#endif
Iliyan Malchev66ea3572011-05-01 14:05:30 -070026
Mathias Agopian5c9be402011-08-09 18:55:44 -070027/*
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
Iliyan Malchev66ea3572011-05-01 14:05:30 -070041/**
42 * pixel format definitions
43 */
44
Dan Stoza48cd3402015-12-17 13:58:19 -080045typedef enum android_pixel_format {
Mathias Agopian8d9da282013-07-25 17:07:11 -070046 /*
47 * "linear" color pixel formats:
48 *
Eino-Ville Talvala03743412015-02-17 15:34:44 -080049 * 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.
Mathias Agopian8d9da282013-07-25 17:07:11 -070055 */
Iliyan Malchev66ea3572011-05-01 14:05:30 -070056 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,
Iliyan Malchev66ea3572011-05-01 14:05:30 -070061
Mathias Agopian8d9da282013-07-25 17:07:11 -070062 /*
Iliyan Malchev66ea3572011-05-01 14:05:30 -070063 * 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 *
Jamie Gennisda1a1f62011-05-18 14:42:46 -070076 * This format is exposed outside of the HAL to software decoders and
77 * applications. EGLImageKHR must support it in conjunction with the
Iliyan Malchev66ea3572011-05-01 14:05:30 -070078 * OES_EGL_image_external extension.
79 *
Jamie Gennisda1a1f62011-05-18 14:42:46 -070080 * YV12 is a 4:2:0 YCrCb planar format comprised of a WxH Y plane followed
Iliyan Malchev66ea3572011-05-01 14:05:30 -070081 * 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
Jamie Gennis185b3002012-04-30 12:50:38 -070090 * c_stride = ALIGN(stride/2, 16)
91 * c_size = c_stride * height/2
Iliyan Malchev66ea3572011-05-01 14:05:30 -070092 * size = y_size + c_size * 2
93 * cr_offset = y_size
94 * cb_offset = y_size + c_size
95 *
Eino-Ville Talvala03743412015-02-17 15:34:44 -080096 * When used with ANativeWindow, the dataSpace field describes the color
97 * space of the buffer.
Iliyan Malchev66ea3572011-05-01 14:05:30 -070098 */
99 HAL_PIXEL_FORMAT_YV12 = 0x32315659, // YCrCb 4:2:0 Planar
100
Igor Murashkin9e00e662013-01-31 17:17:43 -0800101
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 *
Igor Murashkind755b522013-02-11 11:34:53 -0800120 * size = stride * height
Igor Murashkin9e00e662013-01-31 17:17:43 -0800121 *
Eino-Ville Talvala03743412015-02-17 15:34:44 -0800122 * When used with ANativeWindow, the dataSpace field describes the color
123 * space of the buffer.
Igor Murashkin9e00e662013-01-31 17:17:43 -0800124 */
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 *
Igor Murashkind755b522013-02-11 11:34:53 -0800146 * size = stride * height * 2
Igor Murashkin9e00e662013-01-31 17:17:43 -0800147 *
Eino-Ville Talvala03743412015-02-17 15:34:44 -0800148 * 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
Eino-Ville Talvala20651b52015-05-21 15:17:05 -0700151 * image where each sample is a distance value measured by a depth camera,
152 * plus an associated confidence value.
Igor Murashkin9e00e662013-01-31 17:17:43 -0800153 */
154 HAL_PIXEL_FORMAT_Y16 = 0x20363159,
155
Eino-Ville Talvala0a851542012-04-10 15:10:50 -0700156 /*
157 * Android RAW sensor format:
158 *
Ruben Brunk535253e2014-02-04 18:13:34 -0800159 * This format is exposed outside of the camera HAL to applications.
Eino-Ville Talvala0a851542012-04-10 15:10:50 -0700160 *
Eino-Ville Talvala03743412015-02-17 15:34:44 -0800161 * RAW16 is a single-channel, 16-bit, little endian format, typically
Ruben Brunk535253e2014-02-04 18:13:34 -0800162 * representing raw Bayer-pattern images from an image sensor, with minimal
163 * processing.
Eino-Ville Talvala0a851542012-04-10 15:10:50 -0700164 *
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
Ruben Brunk535253e2014-02-04 18:13:34 -0800169 * 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,
Eino-Ville Talvala0a851542012-04-10 15:10:50 -0700171 * color space, etc) must be queried from the camera device.
172 *
173 * This format assumes
174 * - an even width
175 * - an even height
Ruben Brunk535253e2014-02-04 18:13:34 -0800176 * - 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
Eino-Ville Talvala03743412015-02-17 15:34:44 -0800187 *
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.
Eino-Ville Talvala0a851542012-04-10 15:10:50 -0700191 */
Ruben Brunk535253e2014-02-04 18:13:34 -0800192 HAL_PIXEL_FORMAT_RAW16 = 0x20,
Ruben Brunk535253e2014-02-04 18:13:34 -0800193
194 /*
Zhijun He72fce302014-06-23 17:14:42 -0700195 * Android RAW10 format:
196 *
197 * This format is exposed outside of the camera HAL to applications.
198 *
Zhijun Hec73b73a2014-07-25 08:07:48 -0700199 * 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.
Zhijun He72fce302014-06-23 17:14:42 -0700202 *
Zhijun Hec73b73a2014-07-25 08:07:48 -0700203 * 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):
Zhijun He72fce302014-06-23 17:14:42 -0700209 *
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
Zhijun He72fce302014-06-23 17:14:42 -0700226 * - a vertical stride equal to the height
Zhijun Hec73b73a2014-07-25 08:07:48 -0700227 * - strides are specified in bytes, not in pixels
Zhijun He72fce302014-06-23 17:14:42 -0700228 *
Zhijun Hec73b73a2014-07-25 08:07:48 -0700229 * 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).
Zhijun He72fce302014-06-23 17:14:42 -0700235 *
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
Eino-Ville Talvala03743412015-02-17 15:34:44 -0800241 *
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.
Zhijun He72fce302014-06-23 17:14:42 -0700245 */
246 HAL_PIXEL_FORMAT_RAW10 = 0x25,
247
248 /*
Yin-Chia Yeh9a5eeba2015-03-20 15:43:09 -0700249 * 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 /*
Ruben Brunk535253e2014-02-04 18:13:34 -0800299 * 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
Eino-Ville Talvala03743412015-02-17 15:34:44 -0800312 *
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.
Ruben Brunk535253e2014-02-04 18:13:34 -0800316 */
317 HAL_PIXEL_FORMAT_RAW_OPAQUE = 0x24,
Iliyan Malchev66ea3572011-05-01 14:05:30 -0700318
Eino-Ville Talvala0a052482012-06-07 17:52:15 -0700319 /*
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.
Eino-Ville Talvala03743412015-02-17 15:34:44 -0800331 *
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 *
Eino-Ville Talvala0a052482012-06-07 17:52:15 -0700341 */
342 HAL_PIXEL_FORMAT_BLOB = 0x21,
343
Jamie Gennisfebe9d92012-08-22 14:44:51 -0700344 /*
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 *
Eino-Ville Talvala03743412015-02-17 15:34:44 -0800357 * When used with ANativeWindow, the dataSpace field describes the color
358 * space of the buffer.
Jamie Gennisfebe9d92012-08-22 14:44:51 -0700359 */
360 HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED = 0x22,
361
Alex Raye13f15a2013-03-19 01:41:32 -0700362 /*
Lajos Molnare632c1b2015-04-23 16:17:32 -0700363 * Android flexible YCbCr 4:2:0 formats
Alex Raye13f15a2013-03-19 01:41:32 -0700364 *
Lajos Molnare632c1b2015-04-23 16:17:32 -0700365 * 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
Alex Raye13f15a2013-03-19 01:41:32 -0700368 * 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
Yin-Chia Yehe49b6962015-07-14 12:15:29 -0700374 * USAGE_SW_WRITE_* or USAGE_SW_READ_* are set.
Alex Raye13f15a2013-03-19 01:41:32 -0700375 *
376 * This format is locked for use by gralloc's (*lock_ycbcr) method, and
377 * locking with the (*lock) method will return an error.
Eino-Ville Talvala03743412015-02-17 15:34:44 -0800378 *
379 * When used with ANativeWindow, the dataSpace field describes the color
380 * space of the buffer.
Alex Raye13f15a2013-03-19 01:41:32 -0700381 */
382 HAL_PIXEL_FORMAT_YCbCr_420_888 = 0x23,
383
Lajos Molnare632c1b2015-04-23 16:17:32 -0700384 /*
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
Iliyan Malchev66ea3572011-05-01 14:05:30 -0700440 /* 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
Dan Stoza48cd3402015-12-17 13:58:19 -0800444} android_pixel_format_t;
Iliyan Malchev66ea3572011-05-01 14:05:30 -0700445
Alex Raye13f15a2013-03-19 01:41:32 -0700446/*
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 *
Colin Cross7c7990e2016-09-15 18:04:04 -0700455 * y, cb, and cr point to the first byte of their respective planes.
Alex Raye13f15a2013-03-19 01:41:32 -0700456 *
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.
Colin Cross7c7990e2016-09-15 18:04:04 -0700460 * ystride is the stride of the luma plane.
461 * cstride is the stride of the chroma planes.
Alex Raye13f15a2013-03-19 01:41:32 -0700462 *
Colin Cross7c7990e2016-09-15 18:04:04 -0700463 * chroma_step is the distance in bytes from one chroma pixel value to the
Alex Raye13f15a2013-03-19 01:41:32 -0700464 * 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
468struct 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};
Iliyan Malchev66ea3572011-05-01 14:05:30 -0700479
Lajos Molnar0e10df42016-04-08 21:18:12 -0700480/*
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
512typedef 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
531typedef 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
554typedef 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
564typedef 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
Iliyan Malchev66ea3572011-05-01 14:05:30 -0700576/**
Eino-Ville Talvala03743412015-02-17 15:34:44 -0800577 * 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 *
Eino-Ville Talvala20651b52015-05-21 15:17:05 -0700582 * 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.
Eino-Ville Talvala03743412015-02-17 15:34:44 -0800587 *
Colin Cross7c7990e2016-09-15 18:04:04 -0700588 * num_points is the number of points in the list
Eino-Ville Talvala03743412015-02-17 15:34:44 -0800589 *
Colin Cross7c7990e2016-09-15 18:04:04 -0700590 * xyz_points is the flexible array of floating-point values.
Eino-Ville Talvala20651b52015-05-21 15:17:05 -0700591 * It contains (num_points) * 4 floats.
Eino-Ville Talvala03743412015-02-17 15:34:44 -0800592 *
593 * For example:
594 * android_depth_points d = get_depth_buffer();
595 * struct {
Eino-Ville Talvala20651b52015-05-21 15:17:05 -0700596 * float x; float y; float z; float confidence;
Eino-Ville Talvala03743412015-02-17 15:34:44 -0800597 * } firstPoint, lastPoint;
598 *
Eino-Ville Talvala20651b52015-05-21 15:17:05 -0700599 * 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];
Eino-Ville Talvala03743412015-02-17 15:34:44 -0800607 */
608
609struct 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
Colin Cross7c7990e2016-09-15 18:04:04 -0700615#if defined(__clang__)
616#pragma clang diagnostic push
617#pragma clang diagnostic ignored "-Wc99-extensions"
618#endif
Eino-Ville Talvala20651b52015-05-21 15:17:05 -0700619 float xyzc_points[];
Colin Cross7c7990e2016-09-15 18:04:04 -0700620#if defined(__clang__)
621#pragma clang diagnostic pop
622#endif
Eino-Ville Talvala03743412015-02-17 15:34:44 -0800623};
624
625/**
Iliyan Malchev66ea3572011-05-01 14:05:30 -0700626 * Transformation definitions
627 *
628 * IMPORTANT NOTE:
629 * HAL_TRANSFORM_ROT_90 is applied CLOCKWISE and AFTER HAL_TRANSFORM_FLIP_{H|V}.
630 *
631 */
632
Dan Stoza48cd3402015-12-17 13:58:19 -0800633typedef enum android_transform {
Iliyan Malchev66ea3572011-05-01 14:05:30 -0700634 /* flip source image horizontally (around the vertical axis) */
635 HAL_TRANSFORM_FLIP_H = 0x01,
636 /* flip source image vertically (around the horizontal axis)*/
637 HAL_TRANSFORM_FLIP_V = 0x02,
638 /* rotate source image 90 degrees clockwise */
639 HAL_TRANSFORM_ROT_90 = 0x04,
640 /* rotate source image 180 degrees */
641 HAL_TRANSFORM_ROT_180 = 0x03,
642 /* rotate source image 270 degrees clockwise */
643 HAL_TRANSFORM_ROT_270 = 0x07,
Mathias Agopian96675ed2013-09-17 23:48:54 -0700644 /* don't use. see system/window.h */
645 HAL_TRANSFORM_RESERVED = 0x08,
Dan Stoza48cd3402015-12-17 13:58:19 -0800646} android_transform_t;
Iliyan Malchev66ea3572011-05-01 14:05:30 -0700647
Alex Rayc9f3bcf2013-11-26 16:50:46 -0800648/**
Eino-Ville Talvala03743412015-02-17 15:34:44 -0800649 * Dataspace Definitions
Alex Rayc9f3bcf2013-11-26 16:50:46 -0800650 * ======================
651 *
Eino-Ville Talvala03743412015-02-17 15:34:44 -0800652 * Dataspace is the definition of how pixel values should be interpreted.
653 *
654 * For many formats, this is the colorspace of the image data, which includes
655 * primaries (including white point) and the transfer characteristic function,
656 * which describes both gamma curve and numeric range (within the bit depth).
657 *
658 * Other dataspaces include depth measurement data from a depth camera.
Lajos Molnar91369222016-01-15 15:42:41 -0800659 *
660 * A dataspace is comprised of a number of fields.
661 *
662 * Version
663 * --------
664 * The top 2 bits represent the revision of the field specification. This is
665 * currently always 0.
666 *
667 *
668 * bits 31-30 29 - 0
669 * +-----+----------------------------------------------------+
670 * fields | Rev | Revision specific fields |
671 * +-----+----------------------------------------------------+
672 *
673 * Field layout for version = 0:
674 * ----------------------------
675 *
676 * A dataspace is comprised of the following fields:
677 * Standard
678 * Transfer function
679 * Range
680 *
681 * bits 31-30 29-27 26 - 22 21 - 16 15 - 0
682 * +-----+-----+--------+--------+----------------------------+
683 * fields | 0 |Range|Transfer|Standard| Legacy and custom |
684 * +-----+-----+--------+--------+----------------------------+
685 * VV RRR TTTTT SSSSSS LLLLLLLL LLLLLLLL
686 *
687 * If range, transfer and standard fields are all 0 (e.g. top 16 bits are
688 * all zeroes), the bottom 16 bits contain either a legacy dataspace value,
689 * or a custom value.
Alex Rayc9f3bcf2013-11-26 16:50:46 -0800690 */
691
Eino-Ville Talvala03743412015-02-17 15:34:44 -0800692typedef enum android_dataspace {
Alex Rayc9f3bcf2013-11-26 16:50:46 -0800693 /*
Eino-Ville Talvala03743412015-02-17 15:34:44 -0800694 * Default-assumption data space, when not explicitly specified.
695 *
696 * It is safest to assume the buffer is an image with sRGB primaries and
697 * encoding ranges, but the consumer and/or the producer of the data may
698 * simply be using defaults. No automatic gamma transform should be
699 * expected, except for a possible display gamma transform when drawn to a
700 * screen.
701 */
702 HAL_DATASPACE_UNKNOWN = 0x0,
703
704 /*
705 * Arbitrary dataspace with manually defined characteristics. Definition
706 * for colorspaces or other meaning must be communicated separately.
Alex Rayc9f3bcf2013-11-26 16:50:46 -0800707 *
708 * This is used when specifying primaries, transfer characteristics,
709 * etc. separately.
710 *
711 * A typical use case is in video encoding parameters (e.g. for H.264),
712 * where a colorspace can have separately defined primaries, transfer
713 * characteristics, etc.
714 */
Eino-Ville Talvala03743412015-02-17 15:34:44 -0800715 HAL_DATASPACE_ARBITRARY = 0x1,
716
717 /*
Lajos Molnar91369222016-01-15 15:42:41 -0800718 * Color-description aspects
Eino-Ville Talvala03743412015-02-17 15:34:44 -0800719 *
Lajos Molnar91369222016-01-15 15:42:41 -0800720 * The following aspects define various characteristics of the color
721 * specification. These represent bitfields, so that a data space value
722 * can specify each of them independently.
723 */
724
725 HAL_DATASPACE_STANDARD_SHIFT = 16,
726
727 /*
728 * Standard aspect
729 *
730 * Defines the chromaticity coordinates of the source primaries in terms of
731 * the CIE 1931 definition of x and y specified in ISO 11664-1.
732 */
733 HAL_DATASPACE_STANDARD_MASK = 63 << HAL_DATASPACE_STANDARD_SHIFT, // 0x3F
734
735 /*
736 * Chromacity coordinates are unknown or are determined by the application.
737 * Implementations shall use the following suggested standards:
738 *
739 * All YCbCr formats: BT709 if size is 720p or larger (since most video
740 * content is letterboxed this corresponds to width is
741 * 1280 or greater, or height is 720 or greater).
742 * BT601_625 if size is smaller than 720p or is JPEG.
743 * All RGB formats: BT709.
744 *
745 * For all other formats standard is undefined, and implementations should use
746 * an appropriate standard for the data represented.
747 */
748 HAL_DATASPACE_STANDARD_UNSPECIFIED = 0 << HAL_DATASPACE_STANDARD_SHIFT,
749
750 /*
751 * Primaries: x y
752 * green 0.300 0.600
753 * blue 0.150 0.060
754 * red 0.640 0.330
755 * white (D65) 0.3127 0.3290
756 *
757 * Use the unadjusted KR = 0.2126, KB = 0.0722 luminance interpretation
758 * for RGB conversion.
759 */
760 HAL_DATASPACE_STANDARD_BT709 = 1 << HAL_DATASPACE_STANDARD_SHIFT,
761
762 /*
763 * Primaries: x y
764 * green 0.290 0.600
765 * blue 0.150 0.060
766 * red 0.640 0.330
767 * white (D65) 0.3127 0.3290
768 *
769 * KR = 0.299, KB = 0.114. This adjusts the luminance interpretation
770 * for RGB conversion from the one purely determined by the primaries
771 * to minimize the color shift into RGB space that uses BT.709
772 * primaries.
773 */
774 HAL_DATASPACE_STANDARD_BT601_625 = 2 << HAL_DATASPACE_STANDARD_SHIFT,
775
776 /*
777 * Primaries: x y
778 * green 0.290 0.600
779 * blue 0.150 0.060
780 * red 0.640 0.330
781 * white (D65) 0.3127 0.3290
782 *
783 * Use the unadjusted KR = 0.222, KB = 0.071 luminance interpretation
784 * for RGB conversion.
785 */
786 HAL_DATASPACE_STANDARD_BT601_625_UNADJUSTED = 3 << HAL_DATASPACE_STANDARD_SHIFT,
787
788 /*
789 * Primaries: x y
790 * green 0.310 0.595
791 * blue 0.155 0.070
792 * red 0.630 0.340
793 * white (D65) 0.3127 0.3290
794 *
795 * KR = 0.299, KB = 0.114. This adjusts the luminance interpretation
796 * for RGB conversion from the one purely determined by the primaries
797 * to minimize the color shift into RGB space that uses BT.709
798 * primaries.
799 */
800 HAL_DATASPACE_STANDARD_BT601_525 = 4 << HAL_DATASPACE_STANDARD_SHIFT,
801
802 /*
803 * Primaries: x y
804 * green 0.310 0.595
805 * blue 0.155 0.070
806 * red 0.630 0.340
807 * white (D65) 0.3127 0.3290
808 *
809 * Use the unadjusted KR = 0.212, KB = 0.087 luminance interpretation
810 * for RGB conversion (as in SMPTE 240M).
811 */
812 HAL_DATASPACE_STANDARD_BT601_525_UNADJUSTED = 5 << HAL_DATASPACE_STANDARD_SHIFT,
813
814 /*
815 * Primaries: x y
816 * green 0.170 0.797
817 * blue 0.131 0.046
818 * red 0.708 0.292
819 * white (D65) 0.3127 0.3290
820 *
821 * Use the unadjusted KR = 0.2627, KB = 0.0593 luminance interpretation
822 * for RGB conversion.
823 */
824 HAL_DATASPACE_STANDARD_BT2020 = 6 << HAL_DATASPACE_STANDARD_SHIFT,
825
826 /*
827 * Primaries: x y
828 * green 0.170 0.797
829 * blue 0.131 0.046
830 * red 0.708 0.292
831 * white (D65) 0.3127 0.3290
832 *
833 * Use the unadjusted KR = 0.2627, KB = 0.0593 luminance interpretation
834 * for RGB conversion using the linear domain.
835 */
836 HAL_DATASPACE_STANDARD_BT2020_CONSTANT_LUMINANCE = 7 << HAL_DATASPACE_STANDARD_SHIFT,
837
838 /*
839 * Primaries: x y
840 * green 0.21 0.71
841 * blue 0.14 0.08
842 * red 0.67 0.33
843 * white (C) 0.310 0.316
844 *
845 * Use the unadjusted KR = 0.30, KB = 0.11 luminance interpretation
846 * for RGB conversion.
847 */
848 HAL_DATASPACE_STANDARD_BT470M = 8 << HAL_DATASPACE_STANDARD_SHIFT,
849
850 /*
851 * Primaries: x y
852 * green 0.243 0.692
853 * blue 0.145 0.049
854 * red 0.681 0.319
855 * white (C) 0.310 0.316
856 *
857 * Use the unadjusted KR = 0.254, KB = 0.068 luminance interpretation
858 * for RGB conversion.
859 */
860 HAL_DATASPACE_STANDARD_FILM = 9 << HAL_DATASPACE_STANDARD_SHIFT,
861
862 HAL_DATASPACE_TRANSFER_SHIFT = 22,
863
864 /*
865 * Transfer aspect
Eino-Ville Talvala03743412015-02-17 15:34:44 -0800866 *
867 * Transfer characteristics are the opto-electronic transfer characteristic
868 * at the source as a function of linear optical intensity (luminance).
Lajos Molnar91369222016-01-15 15:42:41 -0800869 *
870 * For digital signals, E corresponds to the recorded value. Normally, the
871 * transfer function is applied in RGB space to each of the R, G and B
872 * components independently. This may result in color shift that can be
873 * minized by applying the transfer function in Lab space only for the L
874 * component. Implementation may apply the transfer function in RGB space
875 * for all pixel formats if desired.
876 */
877
878 HAL_DATASPACE_TRANSFER_MASK = 31 << HAL_DATASPACE_TRANSFER_SHIFT, // 0x1F
879
880 /*
881 * Transfer characteristics are unknown or are determined by the
882 * application.
883 *
884 * Implementations should use the following transfer functions:
885 *
886 * For YCbCr formats: use HAL_DATASPACE_TRANSFER_SMPTE_170M
887 * For RGB formats: use HAL_DATASPACE_TRANSFER_SRGB
888 *
889 * For all other formats transfer function is undefined, and implementations
890 * should use an appropriate standard for the data represented.
891 */
892 HAL_DATASPACE_TRANSFER_UNSPECIFIED = 0 << HAL_DATASPACE_TRANSFER_SHIFT,
893
894 /*
895 * Transfer characteristic curve:
896 * E = L
897 * L - luminance of image 0 <= L <= 1 for conventional colorimetry
898 * E - corresponding electrical signal
899 */
900 HAL_DATASPACE_TRANSFER_LINEAR = 1 << HAL_DATASPACE_TRANSFER_SHIFT,
901
902 /*
903 * Transfer characteristic curve:
904 *
905 * E = 1.055 * L^(1/2.4) - 0.055 for 0.0031308 <= L <= 1
906 * = 12.92 * L for 0 <= L < 0.0031308
907 * L - luminance of image 0 <= L <= 1 for conventional colorimetry
908 * E - corresponding electrical signal
909 */
910 HAL_DATASPACE_TRANSFER_SRGB = 2 << HAL_DATASPACE_TRANSFER_SHIFT,
911
912 /*
913 * BT.601 525, BT.601 625, BT.709, BT.2020
914 *
915 * Transfer characteristic curve:
916 * E = 1.099 * L ^ 0.45 - 0.099 for 0.018 <= L <= 1
917 * = 4.500 * L for 0 <= L < 0.018
918 * L - luminance of image 0 <= L <= 1 for conventional colorimetry
919 * E - corresponding electrical signal
920 */
921 HAL_DATASPACE_TRANSFER_SMPTE_170M = 3 << HAL_DATASPACE_TRANSFER_SHIFT,
922
923 /*
924 * Assumed display gamma 2.2.
925 *
926 * Transfer characteristic curve:
927 * E = L ^ (1/2.2)
928 * L - luminance of image 0 <= L <= 1 for conventional colorimetry
929 * E - corresponding electrical signal
930 */
931 HAL_DATASPACE_TRANSFER_GAMMA2_2 = 4 << HAL_DATASPACE_TRANSFER_SHIFT,
932
933 /*
934 * display gamma 2.8.
935 *
936 * Transfer characteristic curve:
937 * E = L ^ (1/2.8)
938 * L - luminance of image 0 <= L <= 1 for conventional colorimetry
939 * E - corresponding electrical signal
940 */
941 HAL_DATASPACE_TRANSFER_GAMMA2_8 = 5 << HAL_DATASPACE_TRANSFER_SHIFT,
942
943 /*
944 * SMPTE ST 2084
945 *
946 * Transfer characteristic curve:
947 * E = ((c1 + c2 * L^n) / (1 + c3 * L^n)) ^ m
948 * c1 = c3 - c2 + 1 = 3424 / 4096 = 0.8359375
949 * c2 = 32 * 2413 / 4096 = 18.8515625
950 * c3 = 32 * 2392 / 4096 = 18.6875
951 * m = 128 * 2523 / 4096 = 78.84375
952 * n = 0.25 * 2610 / 4096 = 0.1593017578125
953 * L - luminance of image 0 <= L <= 1 for HDR colorimetry.
954 * L = 1 corresponds to 10000 cd/m2
955 * E - corresponding electrical signal
956 */
957 HAL_DATASPACE_TRANSFER_ST2084 = 6 << HAL_DATASPACE_TRANSFER_SHIFT,
958
959 /*
960 * ARIB STD-B67 Hybrid Log Gamma
961 *
962 * Transfer characteristic curve:
963 * E = r * L^0.5 for 0 <= L <= 1
964 * = a * ln(L - b) + c for 1 < L
965 * a = 0.17883277
966 * b = 0.28466892
967 * c = 0.55991073
968 * r = 0.5
969 * L - luminance of image 0 <= L for HDR colorimetry. L = 1 corresponds
970 * to reference white level of 100 cd/m2
971 * E - corresponding electrical signal
972 */
973 HAL_DATASPACE_TRANSFER_HLG = 7 << HAL_DATASPACE_TRANSFER_SHIFT,
974
975 HAL_DATASPACE_RANGE_SHIFT = 27,
976
977 /*
978 * Range aspect
979 *
980 * Defines the range of values corresponding to the unit range of 0-1.
981 * This is defined for YCbCr only, but can be expanded to RGB space.
982 */
983 HAL_DATASPACE_RANGE_MASK = 7 << HAL_DATASPACE_RANGE_SHIFT, // 0x7
984
985 /*
986 * Range is unknown or are determined by the application. Implementations
987 * shall use the following suggested ranges:
988 *
989 * All YCbCr formats: limited range.
990 * All RGB or RGBA formats (including RAW and Bayer): full range.
991 * All Y formats: full range
992 *
993 * For all other formats range is undefined, and implementations should use
994 * an appropriate range for the data represented.
995 */
996 HAL_DATASPACE_RANGE_UNSPECIFIED = 0 << HAL_DATASPACE_RANGE_SHIFT,
997
998 /*
999 * Full range uses all values for Y, Cb and Cr from
1000 * 0 to 2^b-1, where b is the bit depth of the color format.
1001 */
1002 HAL_DATASPACE_RANGE_FULL = 1 << HAL_DATASPACE_RANGE_SHIFT,
1003
1004 /*
1005 * Limited range uses values 16/256*2^b to 235/256*2^b for Y, and
1006 * 1/16*2^b to 15/16*2^b for Cb, Cr, R, G and B, where b is the bit depth of
1007 * the color format.
1008 *
1009 * E.g. For 8-bit-depth formats:
1010 * Luma (Y) samples should range from 16 to 235, inclusive
1011 * Chroma (Cb, Cr) samples should range from 16 to 240, inclusive
1012 *
1013 * For 10-bit-depth formats:
1014 * Luma (Y) samples should range from 64 to 940, inclusive
1015 * Chroma (Cb, Cr) samples should range from 64 to 960, inclusive
1016 */
1017 HAL_DATASPACE_RANGE_LIMITED = 2 << HAL_DATASPACE_RANGE_SHIFT,
1018
1019 /*
1020 * Legacy dataspaces
Eino-Ville Talvala03743412015-02-17 15:34:44 -08001021 */
1022
1023 /*
1024 * sRGB linear encoding:
1025 *
1026 * The red, green, and blue components are stored in sRGB space, but
1027 * are linear, not gamma-encoded.
1028 * The RGB primaries and the white point are the same as BT.709.
1029 *
1030 * The values are encoded using the full range ([0,255] for 8-bit) for all
1031 * components.
1032 */
Lajos Molnar88a5ad32016-02-24 13:36:52 -08001033 HAL_DATASPACE_SRGB_LINEAR = 0x200, // deprecated, use HAL_DATASPACE_V0_SRGB_LINEAR
Lajos Molnar91369222016-01-15 15:42:41 -08001034
Lajos Molnar88a5ad32016-02-24 13:36:52 -08001035 HAL_DATASPACE_V0_SRGB_LINEAR = HAL_DATASPACE_STANDARD_BT709 |
Lajos Molnar91369222016-01-15 15:42:41 -08001036 HAL_DATASPACE_TRANSFER_LINEAR | HAL_DATASPACE_RANGE_FULL,
1037
Eino-Ville Talvala03743412015-02-17 15:34:44 -08001038
1039 /*
1040 * sRGB gamma encoding:
1041 *
1042 * The red, green and blue components are stored in sRGB space, and
Lajos Molnar91369222016-01-15 15:42:41 -08001043 * converted to linear space when read, using the SRGB transfer function
1044 * for each of the R, G and B components. When written, the inverse
1045 * transformation is performed.
Eino-Ville Talvala03743412015-02-17 15:34:44 -08001046 *
1047 * The alpha component, if present, is always stored in linear space and
1048 * is left unmodified when read or written.
1049 *
Lajos Molnar91369222016-01-15 15:42:41 -08001050 * Use full range and BT.709 standard.
Eino-Ville Talvala03743412015-02-17 15:34:44 -08001051 */
Lajos Molnar88a5ad32016-02-24 13:36:52 -08001052 HAL_DATASPACE_SRGB = 0x201, // deprecated, use HAL_DATASPACE_V0_SRGB
Lajos Molnar91369222016-01-15 15:42:41 -08001053
Lajos Molnar88a5ad32016-02-24 13:36:52 -08001054 HAL_DATASPACE_V0_SRGB = HAL_DATASPACE_STANDARD_BT709 |
Lajos Molnar91369222016-01-15 15:42:41 -08001055 HAL_DATASPACE_TRANSFER_SRGB | HAL_DATASPACE_RANGE_FULL,
1056
Alex Rayc9f3bcf2013-11-26 16:50:46 -08001057
1058 /*
1059 * YCbCr Colorspaces
1060 * -----------------
1061 *
1062 * Primaries are given using (x,y) coordinates in the CIE 1931 definition
1063 * of x and y specified by ISO 11664-1.
1064 *
1065 * Transfer characteristics are the opto-electronic transfer characteristic
1066 * at the source as a function of linear optical intensity (luminance).
1067 */
1068
1069 /*
1070 * JPEG File Interchange Format (JFIF)
1071 *
1072 * Same model as BT.601-625, but all values (Y, Cb, Cr) range from 0 to 255
1073 *
Lajos Molnar91369222016-01-15 15:42:41 -08001074 * Use full range, BT.601 transfer and BT.601_625 standard.
Alex Rayc9f3bcf2013-11-26 16:50:46 -08001075 */
Lajos Molnar88a5ad32016-02-24 13:36:52 -08001076 HAL_DATASPACE_JFIF = 0x101, // deprecated, use HAL_DATASPACE_V0_JFIF
Lajos Molnar91369222016-01-15 15:42:41 -08001077
Lajos Molnar88a5ad32016-02-24 13:36:52 -08001078 HAL_DATASPACE_V0_JFIF = HAL_DATASPACE_STANDARD_BT601_625 |
Lajos Molnar91369222016-01-15 15:42:41 -08001079 HAL_DATASPACE_TRANSFER_SMPTE_170M | HAL_DATASPACE_RANGE_FULL,
Alex Rayc9f3bcf2013-11-26 16:50:46 -08001080
1081 /*
1082 * ITU-R Recommendation 601 (BT.601) - 625-line
1083 *
1084 * Standard-definition television, 625 Lines (PAL)
1085 *
Lajos Molnar91369222016-01-15 15:42:41 -08001086 * Use limited range, BT.601 transfer and BT.601_625 standard.
Alex Rayc9f3bcf2013-11-26 16:50:46 -08001087 */
Lajos Molnar88a5ad32016-02-24 13:36:52 -08001088 HAL_DATASPACE_BT601_625 = 0x102, // deprecated, use HAL_DATASPACE_V0_BT601_625
Lajos Molnar91369222016-01-15 15:42:41 -08001089
Lajos Molnar88a5ad32016-02-24 13:36:52 -08001090 HAL_DATASPACE_V0_BT601_625 = HAL_DATASPACE_STANDARD_BT601_625 |
Lajos Molnar91369222016-01-15 15:42:41 -08001091 HAL_DATASPACE_TRANSFER_SMPTE_170M | HAL_DATASPACE_RANGE_LIMITED,
1092
Alex Rayc9f3bcf2013-11-26 16:50:46 -08001093
1094 /*
1095 * ITU-R Recommendation 601 (BT.601) - 525-line
1096 *
1097 * Standard-definition television, 525 Lines (NTSC)
1098 *
Lajos Molnar91369222016-01-15 15:42:41 -08001099 * Use limited range, BT.601 transfer and BT.601_525 standard.
Alex Rayc9f3bcf2013-11-26 16:50:46 -08001100 */
Lajos Molnar88a5ad32016-02-24 13:36:52 -08001101 HAL_DATASPACE_BT601_525 = 0x103, // deprecated, use HAL_DATASPACE_V0_BT601_525
Lajos Molnar91369222016-01-15 15:42:41 -08001102
Lajos Molnar88a5ad32016-02-24 13:36:52 -08001103 HAL_DATASPACE_V0_BT601_525 = HAL_DATASPACE_STANDARD_BT601_525 |
Lajos Molnar91369222016-01-15 15:42:41 -08001104 HAL_DATASPACE_TRANSFER_SMPTE_170M | HAL_DATASPACE_RANGE_LIMITED,
Alex Rayc9f3bcf2013-11-26 16:50:46 -08001105
1106 /*
1107 * ITU-R Recommendation 709 (BT.709)
1108 *
1109 * High-definition television
1110 *
Lajos Molnar91369222016-01-15 15:42:41 -08001111 * Use limited range, BT.709 transfer and BT.709 standard.
Alex Rayc9f3bcf2013-11-26 16:50:46 -08001112 */
Lajos Molnar88a5ad32016-02-24 13:36:52 -08001113 HAL_DATASPACE_BT709 = 0x104, // deprecated, use HAL_DATASPACE_V0_BT709
Lajos Molnar91369222016-01-15 15:42:41 -08001114
Lajos Molnar88a5ad32016-02-24 13:36:52 -08001115 HAL_DATASPACE_V0_BT709 = HAL_DATASPACE_STANDARD_BT709 |
Lajos Molnar91369222016-01-15 15:42:41 -08001116 HAL_DATASPACE_TRANSFER_SMPTE_170M | HAL_DATASPACE_RANGE_LIMITED,
1117
1118 /*
1119 * Data spaces for non-color formats
1120 */
Eino-Ville Talvala03743412015-02-17 15:34:44 -08001121
1122 /*
1123 * The buffer contains depth ranging measurements from a depth camera.
1124 * This value is valid with formats:
Eino-Ville Talvala20651b52015-05-21 15:17:05 -07001125 * HAL_PIXEL_FORMAT_Y16: 16-bit samples, consisting of a depth measurement
1126 * and an associated confidence value. The 3 MSBs of the sample make
1127 * up the confidence value, and the low 13 LSBs of the sample make up
1128 * the depth measurement.
1129 * For the confidence section, 0 means 100% confidence, 1 means 0%
1130 * confidence. The mapping to a linear float confidence value between
1131 * 0.f and 1.f can be obtained with
1132 * float confidence = (((depthSample >> 13) - 1) & 0x7) / 7.0f;
1133 * The depth measurement can be extracted simply with
1134 * uint16_t range = (depthSample & 0x1FFF);
Eino-Ville Talvala03743412015-02-17 15:34:44 -08001135 * HAL_PIXEL_FORMAT_BLOB: A depth point cloud, as
Eino-Ville Talvala20651b52015-05-21 15:17:05 -07001136 * a variable-length float (x,y,z, confidence) coordinate point list.
Eino-Ville Talvala03743412015-02-17 15:34:44 -08001137 * The point cloud will be represented with the android_depth_points
1138 * structure.
1139 */
1140 HAL_DATASPACE_DEPTH = 0x1000
1141
1142} android_dataspace_t;
Alex Rayc9f3bcf2013-11-26 16:50:46 -08001143
Dan Stozabb1deda2016-03-24 10:38:46 -07001144/*
Courtney Goeltzenleuchtera2e874e2016-06-20 14:49:39 -06001145 * Color modes that may be supported by a display.
1146 *
1147 * Definitions:
1148 * Rendering intent generally defines the goal in mapping a source (input)
1149 * color to a destination device color for a given color mode.
1150 *
1151 * It is important to keep in mind three cases where mapping may be applied:
1152 * 1. The source gamut is much smaller than the destination (display) gamut
1153 * 2. The source gamut is much larger than the destination gamut (this will
1154 * ordinarily be handled using colorimetric rendering, below)
1155 * 3. The source and destination gamuts are roughly equal, although not
1156 * completely overlapping
1157 * Also, a common requirement for mappings is that skin tones should be
1158 * preserved, or at least remain natural in appearance.
1159 *
1160 * Colorimetric Rendering Intent (All cases):
1161 * Colorimetric indicates that colors should be preserved. In the case
1162 * that the source gamut lies wholly within the destination gamut or is
1163 * about the same (#1, #3), this will simply mean that no manipulations
1164 * (no saturation boost, for example) are applied. In the case where some
1165 * source colors lie outside the destination gamut (#2, #3), those will
1166 * need to be mapped to colors that are within the destination gamut,
1167 * while the already in-gamut colors remain unchanged.
1168 *
1169 * Non-colorimetric transforms can take many forms. There are no hard
1170 * rules and it's left to the implementation to define.
1171 * Two common intents are described below.
1172 *
1173 * Stretched-Gamut Enhancement Intent (Source < Destination):
1174 * When the destination gamut is much larger than the source gamut (#1), the
1175 * source primaries may be redefined to reflect the full extent of the
1176 * destination space, or to reflect an intermediate gamut.
1177 * Skin-tone preservation would likely be applied. An example might be sRGB
1178 * input displayed on a DCI-P3 capable device, with skin-tone preservation.
1179 *
1180 * Within-Gamut Enhancement Intent (Source >= Destination):
1181 * When the device (destination) gamut is not larger than the source gamut
1182 * (#2 or #3), but the appearance of a larger gamut is desired, techniques
1183 * such as saturation boost may be applied to the source colors. Skin-tone
1184 * preservation may be applied. There is no unique method for within-gamut
1185 * enhancement; it would be defined within a flexible color mode.
1186 *
1187 */
1188typedef enum android_color_mode {
1189
1190 /*
1191 * HAL_COLOR_MODE_DEFAULT is the "native" gamut of the display.
1192 * White Point: Vendor/OEM defined
1193 * Panel Gamma: Vendor/OEM defined (typically 2.2)
1194 * Rendering Intent: Vendor/OEM defined (typically 'enhanced')
1195 */
1196 HAL_COLOR_MODE_NATIVE = 0,
1197
1198 /*
1199 * HAL_COLOR_MODE_STANDARD_BT601_625 corresponds with display
1200 * settings that implement the ITU-R Recommendation BT.601
1201 * or Rec 601. Using 625 line version
1202 * Rendering Intent: Colorimetric
1203 * Primaries:
1204 * x y
1205 * green 0.290 0.600
1206 * blue 0.150 0.060
1207 * red 0.640 0.330
1208 * white (D65) 0.3127 0.3290
1209 *
1210 * KR = 0.299, KB = 0.114. This adjusts the luminance interpretation
1211 * for RGB conversion from the one purely determined by the primaries
1212 * to minimize the color shift into RGB space that uses BT.709
1213 * primaries.
1214 *
1215 * Gamma Correction (GC):
1216 *
1217 * if Vlinear < 0.018
1218 * Vnonlinear = 4.500 * Vlinear
1219 * else
1220 * Vnonlinear = 1.099 * (Vlinear)^(0.45) – 0.099
1221 */
1222 HAL_COLOR_MODE_STANDARD_BT601_625 = 1,
1223
1224 /*
1225 * Primaries:
1226 * x y
1227 * green 0.290 0.600
1228 * blue 0.150 0.060
1229 * red 0.640 0.330
1230 * white (D65) 0.3127 0.3290
1231 *
1232 * Use the unadjusted KR = 0.222, KB = 0.071 luminance interpretation
1233 * for RGB conversion.
1234 *
1235 * Gamma Correction (GC):
1236 *
1237 * if Vlinear < 0.018
1238 * Vnonlinear = 4.500 * Vlinear
1239 * else
1240 * Vnonlinear = 1.099 * (Vlinear)^(0.45) – 0.099
1241 */
1242 HAL_COLOR_MODE_STANDARD_BT601_625_UNADJUSTED = 2,
1243
1244 /*
1245 * Primaries:
1246 * x y
1247 * green 0.310 0.595
1248 * blue 0.155 0.070
1249 * red 0.630 0.340
1250 * white (D65) 0.3127 0.3290
1251 *
1252 * KR = 0.299, KB = 0.114. This adjusts the luminance interpretation
1253 * for RGB conversion from the one purely determined by the primaries
1254 * to minimize the color shift into RGB space that uses BT.709
1255 * primaries.
1256 *
1257 * Gamma Correction (GC):
1258 *
1259 * if Vlinear < 0.018
1260 * Vnonlinear = 4.500 * Vlinear
1261 * else
1262 * Vnonlinear = 1.099 * (Vlinear)^(0.45) – 0.099
1263 */
1264 HAL_COLOR_MODE_STANDARD_BT601_525 = 3,
1265
1266 /*
1267 * Primaries:
1268 * x y
1269 * green 0.310 0.595
1270 * blue 0.155 0.070
1271 * red 0.630 0.340
1272 * white (D65) 0.3127 0.3290
1273 *
1274 * Use the unadjusted KR = 0.212, KB = 0.087 luminance interpretation
1275 * for RGB conversion (as in SMPTE 240M).
1276 *
1277 * Gamma Correction (GC):
1278 *
1279 * if Vlinear < 0.018
1280 * Vnonlinear = 4.500 * Vlinear
1281 * else
1282 * Vnonlinear = 1.099 * (Vlinear)^(0.45) – 0.099
1283 */
1284 HAL_COLOR_MODE_STANDARD_BT601_525_UNADJUSTED = 4,
1285
1286 /*
1287 * HAL_COLOR_MODE_REC709 corresponds with display settings that implement
1288 * the ITU-R Recommendation BT.709 / Rec. 709 for high-definition television.
1289 * Rendering Intent: Colorimetric
1290 * Primaries:
1291 * x y
1292 * green 0.300 0.600
1293 * blue 0.150 0.060
1294 * red 0.640 0.330
1295 * white (D65) 0.3127 0.3290
1296 *
1297 * HDTV REC709 Inverse Gamma Correction (IGC): V represents normalized
1298 * (with [0 to 1] range) value of R, G, or B.
1299 *
1300 * if Vnonlinear < 0.081
1301 * Vlinear = Vnonlinear / 4.5
1302 * else
1303 * Vlinear = ((Vnonlinear + 0.099) / 1.099) ^ (1/0.45)
1304 *
1305 * HDTV REC709 Gamma Correction (GC):
1306 *
1307 * if Vlinear < 0.018
1308 * Vnonlinear = 4.5 * Vlinear
1309 * else
1310 * Vnonlinear = 1.099 * (Vlinear) ^ 0.45 – 0.099
1311 */
1312 HAL_COLOR_MODE_STANDARD_BT709 = 5,
1313
1314 /*
1315 * HAL_COLOR_MODE_DCI_P3 corresponds with display settings that implement
1316 * SMPTE EG 432-1 and SMPTE RP 431-2
1317 * Rendering Intent: Colorimetric
1318 * Primaries:
1319 * x y
1320 * green 0.265 0.690
1321 * blue 0.150 0.060
1322 * red 0.680 0.320
1323 * white (D65) 0.3127 0.3290
1324 *
1325 * Gamma: 2.2
1326 */
1327 HAL_COLOR_MODE_DCI_P3 = 6,
1328
1329 /*
1330 * HAL_COLOR_MODE_SRGB corresponds with display settings that implement
1331 * the sRGB color space. Uses the same primaries as ITU-R Recommendation
1332 * BT.709
1333 * Rendering Intent: Colorimetric
1334 * Primaries:
1335 * x y
1336 * green 0.300 0.600
1337 * blue 0.150 0.060
1338 * red 0.640 0.330
1339 * white (D65) 0.3127 0.3290
1340 *
1341 * PC/Internet (sRGB) Inverse Gamma Correction (IGC):
1342 *
1343 * if Vnonlinear ≤ 0.03928
1344 * Vlinear = Vnonlinear / 12.92
1345 * else
1346 * Vlinear = ((Vnonlinear + 0.055)/1.055) ^ 2.4
1347 *
1348 * PC/Internet (sRGB) Gamma Correction (GC):
1349 *
1350 * if Vlinear ≤ 0.0031308
1351 * Vnonlinear = 12.92 * Vlinear
1352 * else
1353 * Vnonlinear = 1.055 * (Vlinear)^(1/2.4) – 0.055
1354 */
1355 HAL_COLOR_MODE_SRGB = 7,
1356
1357 /*
1358 * HAL_COLOR_MODE_ADOBE_RGB corresponds with the RGB color space developed
1359 * by Adobe Systems, Inc. in 1998.
1360 * Rendering Intent: Colorimetric
1361 * Primaries:
1362 * x y
1363 * green 0.210 0.710
1364 * blue 0.150 0.060
1365 * red 0.640 0.330
1366 * white (D65) 0.3127 0.3290
1367 *
1368 * Gamma: 2.2
1369 */
1370 HAL_COLOR_MODE_ADOBE_RGB = 8
1371
1372} android_color_mode_t;
1373
1374/*
Dan Stozabb1deda2016-03-24 10:38:46 -07001375 * Color transforms that may be applied by hardware composer to the whole
1376 * display.
1377 */
1378typedef enum android_color_transform {
1379 /* Applies no transform to the output color */
1380 HAL_COLOR_TRANSFORM_IDENTITY = 0,
1381
1382 /* Applies an arbitrary transform defined by a 4x4 affine matrix */
1383 HAL_COLOR_TRANSFORM_ARBITRARY_MATRIX = 1,
1384
1385 /* Applies a transform that inverts the value or luminance of the color, but
1386 * does not modify hue or saturation */
1387 HAL_COLOR_TRANSFORM_VALUE_INVERSE = 2,
1388
1389 /* Applies a transform that maps all colors to shades of gray */
1390 HAL_COLOR_TRANSFORM_GRAYSCALE = 3,
1391
1392 /* Applies a transform which corrects for protanopic color blindness */
1393 HAL_COLOR_TRANSFORM_CORRECT_PROTANOPIA = 4,
1394
1395 /* Applies a transform which corrects for deuteranopic color blindness */
1396 HAL_COLOR_TRANSFORM_CORRECT_DEUTERANOPIA = 5,
1397
1398 /* Applies a transform which corrects for tritanopic color blindness */
1399 HAL_COLOR_TRANSFORM_CORRECT_TRITANOPIA = 6
1400} android_color_transform_t;
1401
Dan Stoza7f7c1c52016-03-24 10:35:37 -07001402/*
1403 * Supported HDR formats. Must be kept in sync with equivalents in Display.java.
1404 */
1405typedef enum android_hdr {
1406 /* Device supports Dolby Vision HDR */
1407 HAL_HDR_DOLBY_VISION = 1,
1408
1409 /* Device supports HDR10 */
1410 HAL_HDR_HDR10 = 2,
1411
1412 /* Device supports hybrid log-gamma HDR */
1413 HAL_HDR_HLG = 3
1414} android_hdr_t;
1415
Mathias Agopianc9b06952011-08-11 22:35:31 -07001416#ifdef __cplusplus
1417}
1418#endif
Iliyan Malchev66ea3572011-05-01 14:05:30 -07001419
1420#endif /* SYSTEM_CORE_INCLUDE_ANDROID_GRAPHICS_H */