blob: efd48cb0e1387c5d2ed870595f41ace11775dc6a [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
Alex Raye13f15a2013-03-19 01:41:32 -070020#include <stdint.h>
21
Mathias Agopianc9b06952011-08-11 22:35:31 -070022#ifdef __cplusplus
23extern "C" {
24#endif
Iliyan Malchev66ea3572011-05-01 14:05:30 -070025
Mathias Agopian5c9be402011-08-09 18:55:44 -070026/*
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 Malchev66ea3572011-05-01 14:05:30 -070040/**
41 * pixel format definitions
42 */
43
44enum {
Mathias Agopian8d9da282013-07-25 17:07:11 -070045 /*
46 * "linear" color pixel formats:
47 *
Eino-Ville Talvala772b9002015-02-17 15:34:44 -080048 * 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 Agopian8d9da282013-07-25 17:07:11 -070054 */
Iliyan Malchev66ea3572011-05-01 14:05:30 -070055 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 Malchev66ea3572011-05-01 14:05:30 -070060
Eino-Ville Talvala772b9002015-02-17 15:34:44 -080061 // Deprecated sRGB formats for source code compatibility
62 // Not for use in new code
Mathias Agopian8d9da282013-07-25 17:07:11 -070063 HAL_PIXEL_FORMAT_sRGB_A_8888 = 0xC,
Jesse Hall1e263562013-08-16 08:40:52 -070064 HAL_PIXEL_FORMAT_sRGB_X_8888 = 0xD,
Iliyan Malchev66ea3572011-05-01 14:05:30 -070065
66 /*
67 * 0x100 - 0x1FF
68 *
69 * This range is reserved for pixel formats that are specific to the HAL
70 * implementation. Implementations can use any value in this range to
71 * communicate video pixel formats between their HAL modules. These formats
72 * must not have an alpha channel. Additionally, an EGLimage created from a
73 * gralloc buffer of one of these formats must be supported for use with the
74 * GL_OES_EGL_image_external OpenGL ES extension.
75 */
76
77 /*
78 * Android YUV format:
79 *
Jamie Gennisda1a1f62011-05-18 14:42:46 -070080 * This format is exposed outside of the HAL to software decoders and
81 * applications. EGLImageKHR must support it in conjunction with the
Iliyan Malchev66ea3572011-05-01 14:05:30 -070082 * OES_EGL_image_external extension.
83 *
Jamie Gennisda1a1f62011-05-18 14:42:46 -070084 * YV12 is a 4:2:0 YCrCb planar format comprised of a WxH Y plane followed
Iliyan Malchev66ea3572011-05-01 14:05:30 -070085 * by (W/2) x (H/2) Cr and Cb planes.
86 *
87 * This format assumes
88 * - an even width
89 * - an even height
90 * - a horizontal stride multiple of 16 pixels
91 * - a vertical stride equal to the height
92 *
93 * y_size = stride * height
Jamie Gennis185b3002012-04-30 12:50:38 -070094 * c_stride = ALIGN(stride/2, 16)
95 * c_size = c_stride * height/2
Iliyan Malchev66ea3572011-05-01 14:05:30 -070096 * size = y_size + c_size * 2
97 * cr_offset = y_size
98 * cb_offset = y_size + c_size
99 *
Eino-Ville Talvala772b9002015-02-17 15:34:44 -0800100 * When used with ANativeWindow, the dataSpace field describes the color
101 * space of the buffer.
Iliyan Malchev66ea3572011-05-01 14:05:30 -0700102 */
103 HAL_PIXEL_FORMAT_YV12 = 0x32315659, // YCrCb 4:2:0 Planar
104
Igor Murashkin9e00e662013-01-31 17:17:43 -0800105
106 /*
107 * Android Y8 format:
108 *
109 * This format is exposed outside of the HAL to the framework.
110 * The expected gralloc usage flags are SW_* and HW_CAMERA_*,
111 * and no other HW_ flags will be used.
112 *
113 * Y8 is a YUV planar format comprised of a WxH Y plane,
114 * with each pixel being represented by 8 bits.
115 *
116 * It is equivalent to just the Y plane from YV12.
117 *
118 * This format assumes
119 * - an even width
120 * - an even height
121 * - a horizontal stride multiple of 16 pixels
122 * - a vertical stride equal to the height
123 *
Igor Murashkind755b522013-02-11 11:34:53 -0800124 * size = stride * height
Igor Murashkin9e00e662013-01-31 17:17:43 -0800125 *
Eino-Ville Talvala772b9002015-02-17 15:34:44 -0800126 * When used with ANativeWindow, the dataSpace field describes the color
127 * space of the buffer.
Igor Murashkin9e00e662013-01-31 17:17:43 -0800128 */
129 HAL_PIXEL_FORMAT_Y8 = 0x20203859,
130
131 /*
132 * Android Y16 format:
133 *
134 * This format is exposed outside of the HAL to the framework.
135 * The expected gralloc usage flags are SW_* and HW_CAMERA_*,
136 * and no other HW_ flags will be used.
137 *
138 * Y16 is a YUV planar format comprised of a WxH Y plane,
139 * with each pixel being represented by 16 bits.
140 *
141 * It is just like Y8, but has double the bits per pixel (little endian).
142 *
143 * This format assumes
144 * - an even width
145 * - an even height
146 * - a horizontal stride multiple of 16 pixels
147 * - a vertical stride equal to the height
148 * - strides are specified in pixels, not in bytes
149 *
Igor Murashkind755b522013-02-11 11:34:53 -0800150 * size = stride * height * 2
Igor Murashkin9e00e662013-01-31 17:17:43 -0800151 *
Eino-Ville Talvala772b9002015-02-17 15:34:44 -0800152 * When used with ANativeWindow, the dataSpace field describes the color
153 * space of the buffer, except that dataSpace field
154 * HAL_DATASPACE_DEPTH indicates that this buffer contains a depth
155 * image where each sample is a distance value measured by a depth camera.
Igor Murashkin9e00e662013-01-31 17:17:43 -0800156 */
157 HAL_PIXEL_FORMAT_Y16 = 0x20363159,
158
Eino-Ville Talvala0a851542012-04-10 15:10:50 -0700159 /*
160 * Android RAW sensor format:
161 *
Ruben Brunk535253e2014-02-04 18:13:34 -0800162 * This format is exposed outside of the camera HAL to applications.
Eino-Ville Talvala0a851542012-04-10 15:10:50 -0700163 *
Eino-Ville Talvala772b9002015-02-17 15:34:44 -0800164 * RAW16 is a single-channel, 16-bit, little endian format, typically
Ruben Brunk535253e2014-02-04 18:13:34 -0800165 * representing raw Bayer-pattern images from an image sensor, with minimal
166 * processing.
Eino-Ville Talvala0a851542012-04-10 15:10:50 -0700167 *
168 * The exact pixel layout of the data in the buffer is sensor-dependent, and
169 * needs to be queried from the camera device.
170 *
171 * Generally, not all 16 bits are used; more common values are 10 or 12
Ruben Brunk535253e2014-02-04 18:13:34 -0800172 * bits. If not all bits are used, the lower-order bits are filled first.
173 * All parameters to interpret the raw data (black and white points,
Eino-Ville Talvala0a851542012-04-10 15:10:50 -0700174 * color space, etc) must be queried from the camera device.
175 *
176 * This format assumes
177 * - an even width
178 * - an even height
Ruben Brunk535253e2014-02-04 18:13:34 -0800179 * - a horizontal stride multiple of 16 pixels
180 * - a vertical stride equal to the height
181 * - strides are specified in pixels, not in bytes
182 *
183 * size = stride * height * 2
184 *
185 * This format must be accepted by the gralloc module when used with the
186 * following usage flags:
187 * - GRALLOC_USAGE_HW_CAMERA_*
188 * - GRALLOC_USAGE_SW_*
189 * - GRALLOC_USAGE_RENDERSCRIPT
Eino-Ville Talvala772b9002015-02-17 15:34:44 -0800190 *
191 * When used with ANativeWindow, the dataSpace should be
192 * HAL_DATASPACE_ARBITRARY, as raw image sensor buffers require substantial
193 * extra metadata to define.
Eino-Ville Talvala0a851542012-04-10 15:10:50 -0700194 */
Ruben Brunk535253e2014-02-04 18:13:34 -0800195 HAL_PIXEL_FORMAT_RAW16 = 0x20,
Eino-Ville Talvala772b9002015-02-17 15:34:44 -0800196
197 // Temporary alias for source code compatibility; do not use in new code
198 HAL_PIXEL_FORMAT_RAW_SENSOR = HAL_PIXEL_FORMAT_RAW16,
Ruben Brunk535253e2014-02-04 18:13:34 -0800199
200 /*
Zhijun He72fce302014-06-23 17:14:42 -0700201 * Android RAW10 format:
202 *
203 * This format is exposed outside of the camera HAL to applications.
204 *
Zhijun Hec73b73a2014-07-25 08:07:48 -0700205 * RAW10 is a single-channel, 10-bit per pixel, densely packed in each row,
206 * unprocessed format, usually representing raw Bayer-pattern images coming from
207 * an image sensor.
Zhijun He72fce302014-06-23 17:14:42 -0700208 *
Zhijun Hec73b73a2014-07-25 08:07:48 -0700209 * In an image buffer with this format, starting from the first pixel of each
210 * row, each 4 consecutive pixels are packed into 5 bytes (40 bits). Each one
211 * of the first 4 bytes contains the top 8 bits of each pixel, The fifth byte
212 * contains the 2 least significant bits of the 4 pixels, the exact layout data
213 * for each 4 consecutive pixels is illustrated below (Pi[j] stands for the jth
214 * bit of the ith pixel):
Zhijun He72fce302014-06-23 17:14:42 -0700215 *
216 * bit 7 bit 0
217 * =====|=====|=====|=====|=====|=====|=====|=====|
218 * Byte 0: |P0[9]|P0[8]|P0[7]|P0[6]|P0[5]|P0[4]|P0[3]|P0[2]|
219 * |-----|-----|-----|-----|-----|-----|-----|-----|
220 * Byte 1: |P1[9]|P1[8]|P1[7]|P1[6]|P1[5]|P1[4]|P1[3]|P1[2]|
221 * |-----|-----|-----|-----|-----|-----|-----|-----|
222 * Byte 2: |P2[9]|P2[8]|P2[7]|P2[6]|P2[5]|P2[4]|P2[3]|P2[2]|
223 * |-----|-----|-----|-----|-----|-----|-----|-----|
224 * Byte 3: |P3[9]|P3[8]|P3[7]|P3[6]|P3[5]|P3[4]|P3[3]|P3[2]|
225 * |-----|-----|-----|-----|-----|-----|-----|-----|
226 * Byte 4: |P3[1]|P3[0]|P2[1]|P2[0]|P1[1]|P1[0]|P0[1]|P0[0]|
227 * ===============================================
228 *
229 * This format assumes
230 * - a width multiple of 4 pixels
231 * - an even height
Zhijun He72fce302014-06-23 17:14:42 -0700232 * - a vertical stride equal to the height
Zhijun Hec73b73a2014-07-25 08:07:48 -0700233 * - strides are specified in bytes, not in pixels
Zhijun He72fce302014-06-23 17:14:42 -0700234 *
Zhijun Hec73b73a2014-07-25 08:07:48 -0700235 * size = stride * height
236 *
237 * When stride is equal to width * (10 / 8), there will be no padding bytes at
238 * the end of each row, the entire image data is densely packed. When stride is
239 * larger than width * (10 / 8), padding bytes will be present at the end of each
240 * row (including the last row).
Zhijun He72fce302014-06-23 17:14:42 -0700241 *
242 * This format must be accepted by the gralloc module when used with the
243 * following usage flags:
244 * - GRALLOC_USAGE_HW_CAMERA_*
245 * - GRALLOC_USAGE_SW_*
246 * - GRALLOC_USAGE_RENDERSCRIPT
Eino-Ville Talvala772b9002015-02-17 15:34:44 -0800247 *
248 * When used with ANativeWindow, the dataSpace field should be
249 * HAL_DATASPACE_ARBITRARY, as raw image sensor buffers require substantial
250 * extra metadata to define.
Zhijun He72fce302014-06-23 17:14:42 -0700251 */
252 HAL_PIXEL_FORMAT_RAW10 = 0x25,
253
254 /*
Ruben Brunk535253e2014-02-04 18:13:34 -0800255 * Android opaque RAW format:
256 *
257 * This format is exposed outside of the camera HAL to applications.
258 *
259 * RAW_OPAQUE is a format for unprocessed raw image buffers coming from an
260 * image sensor. The actual structure of buffers of this format is
261 * implementation-dependent.
262 *
263 * This format must be accepted by the gralloc module when used with the
264 * following usage flags:
265 * - GRALLOC_USAGE_HW_CAMERA_*
266 * - GRALLOC_USAGE_SW_*
267 * - GRALLOC_USAGE_RENDERSCRIPT
Eino-Ville Talvala772b9002015-02-17 15:34:44 -0800268 *
269 * When used with ANativeWindow, the dataSpace field should be
270 * HAL_DATASPACE_ARBITRARY, as raw image sensor buffers require substantial
271 * extra metadata to define.
Ruben Brunk535253e2014-02-04 18:13:34 -0800272 */
273 HAL_PIXEL_FORMAT_RAW_OPAQUE = 0x24,
Iliyan Malchev66ea3572011-05-01 14:05:30 -0700274
Eino-Ville Talvala0a052482012-06-07 17:52:15 -0700275 /*
276 * Android binary blob graphics buffer format:
277 *
278 * This format is used to carry task-specific data which does not have a
279 * standard image structure. The details of the format are left to the two
280 * endpoints.
281 *
282 * A typical use case is for transporting JPEG-compressed images from the
283 * Camera HAL to the framework or to applications.
284 *
285 * Buffers of this format must have a height of 1, and width equal to their
286 * size in bytes.
Eino-Ville Talvala772b9002015-02-17 15:34:44 -0800287 *
288 * When used with ANativeWindow, the mapping of the dataSpace field to
289 * buffer contents for BLOB is as follows:
290 *
291 * dataSpace value | Buffer contents
292 * -------------------------------+-----------------------------------------
293 * HAL_DATASPACE_JFIF | An encoded JPEG image
294 * HAL_DATASPACE_DEPTH | An android_depth_points buffer
295 * Other | Unsupported
296 *
Eino-Ville Talvala0a052482012-06-07 17:52:15 -0700297 */
298 HAL_PIXEL_FORMAT_BLOB = 0x21,
299
Jamie Gennisfebe9d92012-08-22 14:44:51 -0700300 /*
301 * Android format indicating that the choice of format is entirely up to the
302 * device-specific Gralloc implementation.
303 *
304 * The Gralloc implementation should examine the usage bits passed in when
305 * allocating a buffer with this format, and it should derive the pixel
306 * format from those usage flags. This format will never be used with any
307 * of the GRALLOC_USAGE_SW_* usage flags.
308 *
309 * If a buffer of this format is to be used as an OpenGL ES texture, the
310 * framework will assume that sampling the texture will always return an
311 * alpha value of 1.0 (i.e. the buffer contains only opaque pixel values).
312 *
Eino-Ville Talvala772b9002015-02-17 15:34:44 -0800313 * When used with ANativeWindow, the dataSpace field describes the color
314 * space of the buffer.
Jamie Gennisfebe9d92012-08-22 14:44:51 -0700315 */
316 HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED = 0x22,
317
Alex Raye13f15a2013-03-19 01:41:32 -0700318 /*
319 * Android flexible YCbCr formats
320 *
321 * This format allows platforms to use an efficient YCbCr/YCrCb buffer
322 * layout, while still describing the buffer layout in a way accessible to
323 * the CPU in a device-independent manner. While called YCbCr, it can be
324 * used to describe formats with either chromatic ordering, as well as
325 * whole planar or semiplanar layouts.
326 *
327 * struct android_ycbcr (below) is the the struct used to describe it.
328 *
329 * This format must be accepted by the gralloc module when
330 * USAGE_HW_CAMERA_WRITE and USAGE_SW_READ_* are set.
331 *
332 * This format is locked for use by gralloc's (*lock_ycbcr) method, and
333 * locking with the (*lock) method will return an error.
Eino-Ville Talvala772b9002015-02-17 15:34:44 -0800334 *
335 * When used with ANativeWindow, the dataSpace field describes the color
336 * space of the buffer.
Alex Raye13f15a2013-03-19 01:41:32 -0700337 */
338 HAL_PIXEL_FORMAT_YCbCr_420_888 = 0x23,
339
Iliyan Malchev66ea3572011-05-01 14:05:30 -0700340 /* Legacy formats (deprecated), used by ImageFormat.java */
341 HAL_PIXEL_FORMAT_YCbCr_422_SP = 0x10, // NV16
342 HAL_PIXEL_FORMAT_YCrCb_420_SP = 0x11, // NV21
343 HAL_PIXEL_FORMAT_YCbCr_422_I = 0x14, // YUY2
344};
345
Alex Raye13f15a2013-03-19 01:41:32 -0700346/*
347 * Structure for describing YCbCr formats for consumption by applications.
348 * This is used with HAL_PIXEL_FORMAT_YCbCr_*_888.
349 *
350 * Buffer chroma subsampling is defined in the format.
351 * e.g. HAL_PIXEL_FORMAT_YCbCr_420_888 has subsampling 4:2:0.
352 *
353 * Buffers must have a 8 bit depth.
354 *
355 * @y, @cb, and @cr point to the first byte of their respective planes.
356 *
357 * Stride describes the distance in bytes from the first value of one row of
358 * the image to the first value of the next row. It includes the width of the
359 * image plus padding.
360 * @ystride is the stride of the luma plane.
361 * @cstride is the stride of the chroma planes.
362 *
363 * @chroma_step is the distance in bytes from one chroma pixel value to the
364 * next. This is 2 bytes for semiplanar (because chroma values are interleaved
365 * and each chroma value is one byte) and 1 for planar.
366 */
367
368struct android_ycbcr {
369 void *y;
370 void *cb;
371 void *cr;
372 size_t ystride;
373 size_t cstride;
374 size_t chroma_step;
375
376 /** reserved for future use, set to 0 by gralloc's (*lock_ycbcr)() */
377 uint32_t reserved[8];
378};
Iliyan Malchev66ea3572011-05-01 14:05:30 -0700379
380/**
Eino-Ville Talvala772b9002015-02-17 15:34:44 -0800381 * Structure used to define depth point clouds for format HAL_PIXEL_FORMAT_BLOB
382 * with dataSpace value of HAL_DATASPACE_DEPTH.
383 * When locking a native buffer of the above format and dataSpace value,
384 * the vaddr pointer can be cast to this structure.
385 *
386 * A variable-length list of (x,y,z) 3D points, as floats.
387 *
388 * @num_points is the number of points in the list
389 *
390 * @xyz_points is the flexible array of floating-point values.
391 * It contains (num_points) * 3 floats.
392 *
393 * For example:
394 * android_depth_points d = get_depth_buffer();
395 * struct {
396 * float x; float y; float z;
397 * } firstPoint, lastPoint;
398 *
399 * firstPoint.x = d.xyz_points[0];
400 * firstPoint.y = d.xyz_points[1];
401 * firstPoint.z = d.xyz_points[2];
402 * lastPoint.x = d.xyz_points[(d.num_points - 1) * 3 + 0];
403 * lastPoint.y = d.xyz_points[(d.num_points - 1) * 3 + 1];
404 * lastPoint.z = d.xyz_points[(d.num_points - 1) * 3 + 2];
405 */
406
407struct android_depth_points {
408 uint32_t num_points;
409
410 /** reserved for future use, set to 0 by gralloc's (*lock)() */
411 uint32_t reserved[8];
412
413 float xyz_points[];
414};
415
416/**
Iliyan Malchev66ea3572011-05-01 14:05:30 -0700417 * Transformation definitions
418 *
419 * IMPORTANT NOTE:
420 * HAL_TRANSFORM_ROT_90 is applied CLOCKWISE and AFTER HAL_TRANSFORM_FLIP_{H|V}.
421 *
422 */
423
424enum {
425 /* flip source image horizontally (around the vertical axis) */
426 HAL_TRANSFORM_FLIP_H = 0x01,
427 /* flip source image vertically (around the horizontal axis)*/
428 HAL_TRANSFORM_FLIP_V = 0x02,
429 /* rotate source image 90 degrees clockwise */
430 HAL_TRANSFORM_ROT_90 = 0x04,
431 /* rotate source image 180 degrees */
432 HAL_TRANSFORM_ROT_180 = 0x03,
433 /* rotate source image 270 degrees clockwise */
434 HAL_TRANSFORM_ROT_270 = 0x07,
Mathias Agopian96675ed2013-09-17 23:48:54 -0700435 /* don't use. see system/window.h */
436 HAL_TRANSFORM_RESERVED = 0x08,
Iliyan Malchev66ea3572011-05-01 14:05:30 -0700437};
438
Alex Rayc9f3bcf2013-11-26 16:50:46 -0800439/**
Eino-Ville Talvala772b9002015-02-17 15:34:44 -0800440 * Dataspace Definitions
Alex Rayc9f3bcf2013-11-26 16:50:46 -0800441 * ======================
442 *
Eino-Ville Talvala772b9002015-02-17 15:34:44 -0800443 * Dataspace is the definition of how pixel values should be interpreted.
444 *
445 * For many formats, this is the colorspace of the image data, which includes
446 * primaries (including white point) and the transfer characteristic function,
447 * which describes both gamma curve and numeric range (within the bit depth).
448 *
449 * Other dataspaces include depth measurement data from a depth camera.
Alex Rayc9f3bcf2013-11-26 16:50:46 -0800450 */
451
Eino-Ville Talvala772b9002015-02-17 15:34:44 -0800452typedef enum android_dataspace {
Alex Rayc9f3bcf2013-11-26 16:50:46 -0800453 /*
Eino-Ville Talvala772b9002015-02-17 15:34:44 -0800454 * Default-assumption data space, when not explicitly specified.
455 *
456 * It is safest to assume the buffer is an image with sRGB primaries and
457 * encoding ranges, but the consumer and/or the producer of the data may
458 * simply be using defaults. No automatic gamma transform should be
459 * expected, except for a possible display gamma transform when drawn to a
460 * screen.
461 */
462 HAL_DATASPACE_UNKNOWN = 0x0,
463
464 /*
465 * Arbitrary dataspace with manually defined characteristics. Definition
466 * for colorspaces or other meaning must be communicated separately.
Alex Rayc9f3bcf2013-11-26 16:50:46 -0800467 *
468 * This is used when specifying primaries, transfer characteristics,
469 * etc. separately.
470 *
471 * A typical use case is in video encoding parameters (e.g. for H.264),
472 * where a colorspace can have separately defined primaries, transfer
473 * characteristics, etc.
474 */
Eino-Ville Talvala772b9002015-02-17 15:34:44 -0800475 HAL_DATASPACE_ARBITRARY = 0x1,
476
477 /*
478 * RGB Colorspaces
479 * -----------------
480 *
481 * Primaries are given using (x,y) coordinates in the CIE 1931 definition
482 * of x and y specified by ISO 11664-1.
483 *
484 * Transfer characteristics are the opto-electronic transfer characteristic
485 * at the source as a function of linear optical intensity (luminance).
486 */
487
488 /*
489 * sRGB linear encoding:
490 *
491 * The red, green, and blue components are stored in sRGB space, but
492 * are linear, not gamma-encoded.
493 * The RGB primaries and the white point are the same as BT.709.
494 *
495 * The values are encoded using the full range ([0,255] for 8-bit) for all
496 * components.
497 */
498 HAL_DATASPACE_SRGB_LINEAR = 0x200,
499
500 /*
501 * sRGB gamma encoding:
502 *
503 * The red, green and blue components are stored in sRGB space, and
504 * converted to linear space when read, using the standard sRGB to linear
505 * equation:
506 *
507 * Clinear = Csrgb / 12.92 for Csrgb <= 0.04045
508 * = (Csrgb + 0.055 / 1.055)^2.4 for Csrgb > 0.04045
509 *
510 * When written the inverse transformation is performed:
511 *
512 * Csrgb = 12.92 * Clinear for Clinear <= 0.0031308
513 * = 1.055 * Clinear^(1/2.4) - 0.055 for Clinear > 0.0031308
514 *
515 *
516 * The alpha component, if present, is always stored in linear space and
517 * is left unmodified when read or written.
518 *
519 * The RGB primaries and the white point are the same as BT.709.
520 *
521 * The values are encoded using the full range ([0,255] for 8-bit) for all
522 * components.
523 *
524 */
525 HAL_DATASPACE_SRGB = 0x201,
Alex Rayc9f3bcf2013-11-26 16:50:46 -0800526
527 /*
528 * YCbCr Colorspaces
529 * -----------------
530 *
531 * Primaries are given using (x,y) coordinates in the CIE 1931 definition
532 * of x and y specified by ISO 11664-1.
533 *
534 * Transfer characteristics are the opto-electronic transfer characteristic
535 * at the source as a function of linear optical intensity (luminance).
536 */
537
538 /*
539 * JPEG File Interchange Format (JFIF)
540 *
541 * Same model as BT.601-625, but all values (Y, Cb, Cr) range from 0 to 255
542 *
543 * Transfer characteristic curve:
544 * E = 1.099 * L ^ 0.45 - 0.099, 1.00 >= L >= 0.018
545 * E = 4.500 L, 0.018 > L >= 0
546 * L - luminance of image 0 <= L <= 1 for conventional colorimetry
547 * E - corresponding electrical signal
548 *
549 * Primaries: x y
550 * green 0.290 0.600
551 * blue 0.150 0.060
552 * red 0.640 0.330
553 * white (D65) 0.3127 0.3290
554 */
Eino-Ville Talvala772b9002015-02-17 15:34:44 -0800555 HAL_DATASPACE_JFIF = 0x101,
Alex Rayc9f3bcf2013-11-26 16:50:46 -0800556
557 /*
558 * ITU-R Recommendation 601 (BT.601) - 625-line
559 *
560 * Standard-definition television, 625 Lines (PAL)
561 *
562 * For 8-bit-depth formats:
563 * Luma (Y) samples should range from 16 to 235, inclusive
564 * Chroma (Cb, Cr) samples should range from 16 to 240, inclusive
565 *
566 * For 10-bit-depth formats:
567 * Luma (Y) samples should range from 64 to 940, inclusive
568 * Chroma (Cb, Cr) samples should range from 64 to 960, inclusive
569 *
570 * Transfer characteristic curve:
571 * E = 1.099 * L ^ 0.45 - 0.099, 1.00 >= L >= 0.018
572 * E = 4.500 L, 0.018 > L >= 0
573 * L - luminance of image 0 <= L <= 1 for conventional colorimetry
574 * E - corresponding electrical signal
575 *
576 * Primaries: x y
577 * green 0.290 0.600
578 * blue 0.150 0.060
579 * red 0.640 0.330
580 * white (D65) 0.3127 0.3290
581 */
Eino-Ville Talvala772b9002015-02-17 15:34:44 -0800582 HAL_DATASPACE_BT601_625 = 0x102,
Alex Rayc9f3bcf2013-11-26 16:50:46 -0800583
584 /*
585 * ITU-R Recommendation 601 (BT.601) - 525-line
586 *
587 * Standard-definition television, 525 Lines (NTSC)
588 *
589 * For 8-bit-depth formats:
590 * Luma (Y) samples should range from 16 to 235, inclusive
591 * Chroma (Cb, Cr) samples should range from 16 to 240, inclusive
592 *
593 * For 10-bit-depth formats:
594 * Luma (Y) samples should range from 64 to 940, inclusive
595 * Chroma (Cb, Cr) samples should range from 64 to 960, inclusive
596 *
597 * Transfer characteristic curve:
598 * E = 1.099 * L ^ 0.45 - 0.099, 1.00 >= L >= 0.018
599 * E = 4.500 L, 0.018 > L >= 0
600 * L - luminance of image 0 <= L <= 1 for conventional colorimetry
601 * E - corresponding electrical signal
602 *
603 * Primaries: x y
604 * green 0.310 0.595
605 * blue 0.155 0.070
606 * red 0.630 0.340
607 * white (D65) 0.3127 0.3290
608 */
Eino-Ville Talvala772b9002015-02-17 15:34:44 -0800609 HAL_DATASPACE_BT601_525 = 0x103,
Alex Rayc9f3bcf2013-11-26 16:50:46 -0800610
611 /*
612 * ITU-R Recommendation 709 (BT.709)
613 *
614 * High-definition television
615 *
616 * For 8-bit-depth formats:
617 * Luma (Y) samples should range from 16 to 235, inclusive
618 * Chroma (Cb, Cr) samples should range from 16 to 240, inclusive
619 *
620 * For 10-bit-depth formats:
621 * Luma (Y) samples should range from 64 to 940, inclusive
622 * Chroma (Cb, Cr) samples should range from 64 to 960, inclusive
623 *
624 * Primaries: x y
625 * green 0.300 0.600
626 * blue 0.150 0.060
627 * red 0.640 0.330
628 * white (D65) 0.3127 0.3290
629 */
Eino-Ville Talvala772b9002015-02-17 15:34:44 -0800630 HAL_DATASPACE_BT709 = 0x104,
631
632 /*
633 * The buffer contains depth ranging measurements from a depth camera.
634 * This value is valid with formats:
635 * HAL_PIXEL_FORMAT_Y16: 16-bit single channel depth image.
636 * HAL_PIXEL_FORMAT_BLOB: A depth point cloud, as
637 * a variable-length float (x,y,z) coordinate point list.
638 * The point cloud will be represented with the android_depth_points
639 * structure.
640 */
641 HAL_DATASPACE_DEPTH = 0x1000
642
643} android_dataspace_t;
Alex Rayc9f3bcf2013-11-26 16:50:46 -0800644
Mathias Agopianc9b06952011-08-11 22:35:31 -0700645#ifdef __cplusplus
646}
647#endif
Iliyan Malchev66ea3572011-05-01 14:05:30 -0700648
649#endif /* SYSTEM_CORE_INCLUDE_ANDROID_GRAPHICS_H */