blob: c0f03faa7b8a61f520fceb87deb8f98c84e4c4d3 [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 Talvala03743412015-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
Mathias Agopian8d9da282013-07-25 17:07:11 -070061 /*
Iliyan Malchev66ea3572011-05-01 14:05:30 -070062 * 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 Gennisda1a1f62011-05-18 14:42:46 -070075 * This format is exposed outside of the HAL to software decoders and
76 * applications. EGLImageKHR must support it in conjunction with the
Iliyan Malchev66ea3572011-05-01 14:05:30 -070077 * OES_EGL_image_external extension.
78 *
Jamie Gennisda1a1f62011-05-18 14:42:46 -070079 * YV12 is a 4:2:0 YCrCb planar format comprised of a WxH Y plane followed
Iliyan Malchev66ea3572011-05-01 14:05:30 -070080 * 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 Gennis185b3002012-04-30 12:50:38 -070089 * c_stride = ALIGN(stride/2, 16)
90 * c_size = c_stride * height/2
Iliyan Malchev66ea3572011-05-01 14:05:30 -070091 * size = y_size + c_size * 2
92 * cr_offset = y_size
93 * cb_offset = y_size + c_size
94 *
Eino-Ville Talvala03743412015-02-17 15:34:44 -080095 * When used with ANativeWindow, the dataSpace field describes the color
96 * space of the buffer.
Iliyan Malchev66ea3572011-05-01 14:05:30 -070097 */
98 HAL_PIXEL_FORMAT_YV12 = 0x32315659, // YCrCb 4:2:0 Planar
99
Igor Murashkin9e00e662013-01-31 17:17:43 -0800100
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 Murashkind755b522013-02-11 11:34:53 -0800119 * size = stride * height
Igor Murashkin9e00e662013-01-31 17:17:43 -0800120 *
Eino-Ville Talvala03743412015-02-17 15:34:44 -0800121 * When used with ANativeWindow, the dataSpace field describes the color
122 * space of the buffer.
Igor Murashkin9e00e662013-01-31 17:17:43 -0800123 */
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 Murashkind755b522013-02-11 11:34:53 -0800145 * size = stride * height * 2
Igor Murashkin9e00e662013-01-31 17:17:43 -0800146 *
Eino-Ville Talvala03743412015-02-17 15:34:44 -0800147 * 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 Murashkin9e00e662013-01-31 17:17:43 -0800151 */
152 HAL_PIXEL_FORMAT_Y16 = 0x20363159,
153
Eino-Ville Talvala0a851542012-04-10 15:10:50 -0700154 /*
155 * Android RAW sensor format:
156 *
Ruben Brunk535253e2014-02-04 18:13:34 -0800157 * This format is exposed outside of the camera HAL to applications.
Eino-Ville Talvala0a851542012-04-10 15:10:50 -0700158 *
Eino-Ville Talvala03743412015-02-17 15:34:44 -0800159 * RAW16 is a single-channel, 16-bit, little endian format, typically
Ruben Brunk535253e2014-02-04 18:13:34 -0800160 * representing raw Bayer-pattern images from an image sensor, with minimal
161 * processing.
Eino-Ville Talvala0a851542012-04-10 15:10:50 -0700162 *
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 Brunk535253e2014-02-04 18:13:34 -0800167 * 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 Talvala0a851542012-04-10 15:10:50 -0700169 * color space, etc) must be queried from the camera device.
170 *
171 * This format assumes
172 * - an even width
173 * - an even height
Ruben Brunk535253e2014-02-04 18:13:34 -0800174 * - 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 Talvala03743412015-02-17 15:34:44 -0800185 *
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 Talvala0a851542012-04-10 15:10:50 -0700189 */
Ruben Brunk535253e2014-02-04 18:13:34 -0800190 HAL_PIXEL_FORMAT_RAW16 = 0x20,
Ruben Brunk535253e2014-02-04 18:13:34 -0800191
192 /*
Zhijun He72fce302014-06-23 17:14:42 -0700193 * Android RAW10 format:
194 *
195 * This format is exposed outside of the camera HAL to applications.
196 *
Zhijun Hec73b73a2014-07-25 08:07:48 -0700197 * 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 He72fce302014-06-23 17:14:42 -0700200 *
Zhijun Hec73b73a2014-07-25 08:07:48 -0700201 * 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 He72fce302014-06-23 17:14:42 -0700207 *
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 He72fce302014-06-23 17:14:42 -0700224 * - a vertical stride equal to the height
Zhijun Hec73b73a2014-07-25 08:07:48 -0700225 * - strides are specified in bytes, not in pixels
Zhijun He72fce302014-06-23 17:14:42 -0700226 *
Zhijun Hec73b73a2014-07-25 08:07:48 -0700227 * 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 He72fce302014-06-23 17:14:42 -0700233 *
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 Talvala03743412015-02-17 15:34:44 -0800239 *
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 He72fce302014-06-23 17:14:42 -0700243 */
244 HAL_PIXEL_FORMAT_RAW10 = 0x25,
245
246 /*
Yin-Chia Yeh9a5eeba2015-03-20 15:43:09 -0700247 * 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 Brunk535253e2014-02-04 18:13:34 -0800297 * 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 Talvala03743412015-02-17 15:34:44 -0800310 *
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 Brunk535253e2014-02-04 18:13:34 -0800314 */
315 HAL_PIXEL_FORMAT_RAW_OPAQUE = 0x24,
Iliyan Malchev66ea3572011-05-01 14:05:30 -0700316
Eino-Ville Talvala0a052482012-06-07 17:52:15 -0700317 /*
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 Talvala03743412015-02-17 15:34:44 -0800329 *
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 Talvala0a052482012-06-07 17:52:15 -0700339 */
340 HAL_PIXEL_FORMAT_BLOB = 0x21,
341
Jamie Gennisfebe9d92012-08-22 14:44:51 -0700342 /*
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 Talvala03743412015-02-17 15:34:44 -0800355 * When used with ANativeWindow, the dataSpace field describes the color
356 * space of the buffer.
Jamie Gennisfebe9d92012-08-22 14:44:51 -0700357 */
358 HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED = 0x22,
359
Alex Raye13f15a2013-03-19 01:41:32 -0700360 /*
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 Talvala03743412015-02-17 15:34:44 -0800376 *
377 * When used with ANativeWindow, the dataSpace field describes the color
378 * space of the buffer.
Alex Raye13f15a2013-03-19 01:41:32 -0700379 */
380 HAL_PIXEL_FORMAT_YCbCr_420_888 = 0x23,
381
Iliyan Malchev66ea3572011-05-01 14:05:30 -0700382 /* 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 Raye13f15a2013-03-19 01:41:32 -0700388/*
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
410struct 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 Malchev66ea3572011-05-01 14:05:30 -0700421
422/**
Eino-Ville Talvala03743412015-02-17 15:34:44 -0800423 * 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
449struct 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 Malchev66ea3572011-05-01 14:05:30 -0700459 * Transformation definitions
460 *
461 * IMPORTANT NOTE:
462 * HAL_TRANSFORM_ROT_90 is applied CLOCKWISE and AFTER HAL_TRANSFORM_FLIP_{H|V}.
463 *
464 */
465
466enum {
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 Agopian96675ed2013-09-17 23:48:54 -0700477 /* don't use. see system/window.h */
478 HAL_TRANSFORM_RESERVED = 0x08,
Iliyan Malchev66ea3572011-05-01 14:05:30 -0700479};
480
Alex Rayc9f3bcf2013-11-26 16:50:46 -0800481/**
Eino-Ville Talvala03743412015-02-17 15:34:44 -0800482 * Dataspace Definitions
Alex Rayc9f3bcf2013-11-26 16:50:46 -0800483 * ======================
484 *
Eino-Ville Talvala03743412015-02-17 15:34:44 -0800485 * 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 Rayc9f3bcf2013-11-26 16:50:46 -0800492 */
493
Eino-Ville Talvala03743412015-02-17 15:34:44 -0800494typedef enum android_dataspace {
Alex Rayc9f3bcf2013-11-26 16:50:46 -0800495 /*
Eino-Ville Talvala03743412015-02-17 15:34:44 -0800496 * 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 Rayc9f3bcf2013-11-26 16:50:46 -0800509 *
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 Talvala03743412015-02-17 15:34:44 -0800517 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 Rayc9f3bcf2013-11-26 16:50:46 -0800568
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 Talvala03743412015-02-17 15:34:44 -0800597 HAL_DATASPACE_JFIF = 0x101,
Alex Rayc9f3bcf2013-11-26 16:50:46 -0800598
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 Talvala03743412015-02-17 15:34:44 -0800624 HAL_DATASPACE_BT601_625 = 0x102,
Alex Rayc9f3bcf2013-11-26 16:50:46 -0800625
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 Talvala03743412015-02-17 15:34:44 -0800651 HAL_DATASPACE_BT601_525 = 0x103,
Alex Rayc9f3bcf2013-11-26 16:50:46 -0800652
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 Talvala03743412015-02-17 15:34:44 -0800672 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 Rayc9f3bcf2013-11-26 16:50:46 -0800686
Mathias Agopianc9b06952011-08-11 22:35:31 -0700687#ifdef __cplusplus
688}
689#endif
Iliyan Malchev66ea3572011-05-01 14:05:30 -0700690
691#endif /* SYSTEM_CORE_INCLUDE_ANDROID_GRAPHICS_H */