blob: c3fca97bb3983c21bbc129787028f65fd50457cc [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 *
48 * The pixel formats below contain sRGB data but are otherwise treated
49 * as linear formats, i.e.: no special operation is performed when
50 * reading or writing into a buffer in one of these formats
51 */
Iliyan Malchev66ea3572011-05-01 14:05:30 -070052 HAL_PIXEL_FORMAT_RGBA_8888 = 1,
53 HAL_PIXEL_FORMAT_RGBX_8888 = 2,
54 HAL_PIXEL_FORMAT_RGB_888 = 3,
55 HAL_PIXEL_FORMAT_RGB_565 = 4,
56 HAL_PIXEL_FORMAT_BGRA_8888 = 5,
Iliyan Malchev66ea3572011-05-01 14:05:30 -070057
Mathias Agopian8d9da282013-07-25 17:07:11 -070058 /*
59 * sRGB color pixel formats:
60 *
61 * The red, green and blue components are stored in sRGB space, and converted
62 * to linear space when read, using the standard sRGB to linear equation:
63 *
64 * Clinear = Csrgb / 12.92 for Csrgb <= 0.04045
65 * = (Csrgb + 0.055 / 1.055)^2.4 for Csrgb > 0.04045
66 *
67 * When written the inverse transformation is performed:
68 *
69 * Csrgb = 12.92 * Clinear for Clinear <= 0.0031308
70 * = 1.055 * Clinear^(1/2.4) - 0.055 for Clinear > 0.0031308
71 *
72 *
73 * The alpha component, if present, is always stored in linear space and
74 * is left unmodified when read or written.
75 *
76 */
77 HAL_PIXEL_FORMAT_sRGB_A_8888 = 0xC,
Jesse Hall1e263562013-08-16 08:40:52 -070078 HAL_PIXEL_FORMAT_sRGB_X_8888 = 0xD,
Iliyan Malchev66ea3572011-05-01 14:05:30 -070079
80 /*
81 * 0x100 - 0x1FF
82 *
83 * This range is reserved for pixel formats that are specific to the HAL
84 * implementation. Implementations can use any value in this range to
85 * communicate video pixel formats between their HAL modules. These formats
86 * must not have an alpha channel. Additionally, an EGLimage created from a
87 * gralloc buffer of one of these formats must be supported for use with the
88 * GL_OES_EGL_image_external OpenGL ES extension.
89 */
90
91 /*
92 * Android YUV format:
93 *
Jamie Gennisda1a1f62011-05-18 14:42:46 -070094 * This format is exposed outside of the HAL to software decoders and
95 * applications. EGLImageKHR must support it in conjunction with the
Iliyan Malchev66ea3572011-05-01 14:05:30 -070096 * OES_EGL_image_external extension.
97 *
Jamie Gennisda1a1f62011-05-18 14:42:46 -070098 * YV12 is a 4:2:0 YCrCb planar format comprised of a WxH Y plane followed
Iliyan Malchev66ea3572011-05-01 14:05:30 -070099 * by (W/2) x (H/2) Cr and Cb planes.
100 *
101 * This format assumes
102 * - an even width
103 * - an even height
104 * - a horizontal stride multiple of 16 pixels
105 * - a vertical stride equal to the height
106 *
107 * y_size = stride * height
Jamie Gennis185b3002012-04-30 12:50:38 -0700108 * c_stride = ALIGN(stride/2, 16)
109 * c_size = c_stride * height/2
Iliyan Malchev66ea3572011-05-01 14:05:30 -0700110 * size = y_size + c_size * 2
111 * cr_offset = y_size
112 * cb_offset = y_size + c_size
113 *
114 */
115 HAL_PIXEL_FORMAT_YV12 = 0x32315659, // YCrCb 4:2:0 Planar
116
Igor Murashkin9e00e662013-01-31 17:17:43 -0800117
118 /*
119 * Android Y8 format:
120 *
121 * This format is exposed outside of the HAL to the framework.
122 * The expected gralloc usage flags are SW_* and HW_CAMERA_*,
123 * and no other HW_ flags will be used.
124 *
125 * Y8 is a YUV planar format comprised of a WxH Y plane,
126 * with each pixel being represented by 8 bits.
127 *
128 * It is equivalent to just the Y plane from YV12.
129 *
130 * This format assumes
131 * - an even width
132 * - an even height
133 * - a horizontal stride multiple of 16 pixels
134 * - a vertical stride equal to the height
135 *
Igor Murashkind755b522013-02-11 11:34:53 -0800136 * size = stride * height
Igor Murashkin9e00e662013-01-31 17:17:43 -0800137 *
138 */
139 HAL_PIXEL_FORMAT_Y8 = 0x20203859,
140
141 /*
142 * Android Y16 format:
143 *
144 * This format is exposed outside of the HAL to the framework.
145 * The expected gralloc usage flags are SW_* and HW_CAMERA_*,
146 * and no other HW_ flags will be used.
147 *
148 * Y16 is a YUV planar format comprised of a WxH Y plane,
149 * with each pixel being represented by 16 bits.
150 *
151 * It is just like Y8, but has double the bits per pixel (little endian).
152 *
153 * This format assumes
154 * - an even width
155 * - an even height
156 * - a horizontal stride multiple of 16 pixels
157 * - a vertical stride equal to the height
158 * - strides are specified in pixels, not in bytes
159 *
Igor Murashkind755b522013-02-11 11:34:53 -0800160 * size = stride * height * 2
Igor Murashkin9e00e662013-01-31 17:17:43 -0800161 *
162 */
163 HAL_PIXEL_FORMAT_Y16 = 0x20363159,
164
Eino-Ville Talvala0a851542012-04-10 15:10:50 -0700165 /*
166 * Android RAW sensor format:
167 *
Ruben Brunk535253e2014-02-04 18:13:34 -0800168 * This format is exposed outside of the camera HAL to applications.
Eino-Ville Talvala0a851542012-04-10 15:10:50 -0700169 *
Ruben Brunk535253e2014-02-04 18:13:34 -0800170 * RAW_SENSOR is a single-channel, 16-bit, little endian format, typically
171 * representing raw Bayer-pattern images from an image sensor, with minimal
172 * processing.
Eino-Ville Talvala0a851542012-04-10 15:10:50 -0700173 *
174 * The exact pixel layout of the data in the buffer is sensor-dependent, and
175 * needs to be queried from the camera device.
176 *
177 * Generally, not all 16 bits are used; more common values are 10 or 12
Ruben Brunk535253e2014-02-04 18:13:34 -0800178 * bits. If not all bits are used, the lower-order bits are filled first.
179 * All parameters to interpret the raw data (black and white points,
Eino-Ville Talvala0a851542012-04-10 15:10:50 -0700180 * color space, etc) must be queried from the camera device.
181 *
182 * This format assumes
183 * - an even width
184 * - an even height
Ruben Brunk535253e2014-02-04 18:13:34 -0800185 * - a horizontal stride multiple of 16 pixels
186 * - a vertical stride equal to the height
187 * - strides are specified in pixels, not in bytes
188 *
189 * size = stride * height * 2
190 *
191 * This format must be accepted by the gralloc module when used with the
192 * following usage flags:
193 * - GRALLOC_USAGE_HW_CAMERA_*
194 * - GRALLOC_USAGE_SW_*
195 * - GRALLOC_USAGE_RENDERSCRIPT
Eino-Ville Talvala0a851542012-04-10 15:10:50 -0700196 */
Ruben Brunk535253e2014-02-04 18:13:34 -0800197 HAL_PIXEL_FORMAT_RAW16 = 0x20,
198 HAL_PIXEL_FORMAT_RAW_SENSOR = 0x20, // TODO(rubenbrunk): Remove RAW_SENSOR.
199
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
247 */
248 HAL_PIXEL_FORMAT_RAW10 = 0x25,
249
250 /*
Ruben Brunk535253e2014-02-04 18:13:34 -0800251 * Android opaque RAW format:
252 *
253 * This format is exposed outside of the camera HAL to applications.
254 *
255 * RAW_OPAQUE is a format for unprocessed raw image buffers coming from an
256 * image sensor. The actual structure of buffers of this format is
257 * implementation-dependent.
258 *
259 * This format must be accepted by the gralloc module when used with the
260 * following usage flags:
261 * - GRALLOC_USAGE_HW_CAMERA_*
262 * - GRALLOC_USAGE_SW_*
263 * - GRALLOC_USAGE_RENDERSCRIPT
264 */
265 HAL_PIXEL_FORMAT_RAW_OPAQUE = 0x24,
Iliyan Malchev66ea3572011-05-01 14:05:30 -0700266
Eino-Ville Talvala0a052482012-06-07 17:52:15 -0700267 /*
268 * Android binary blob graphics buffer format:
269 *
270 * This format is used to carry task-specific data which does not have a
271 * standard image structure. The details of the format are left to the two
272 * endpoints.
273 *
274 * A typical use case is for transporting JPEG-compressed images from the
275 * Camera HAL to the framework or to applications.
276 *
277 * Buffers of this format must have a height of 1, and width equal to their
278 * size in bytes.
279 */
280 HAL_PIXEL_FORMAT_BLOB = 0x21,
281
Jamie Gennisfebe9d92012-08-22 14:44:51 -0700282 /*
283 * Android format indicating that the choice of format is entirely up to the
284 * device-specific Gralloc implementation.
285 *
286 * The Gralloc implementation should examine the usage bits passed in when
287 * allocating a buffer with this format, and it should derive the pixel
288 * format from those usage flags. This format will never be used with any
289 * of the GRALLOC_USAGE_SW_* usage flags.
290 *
291 * If a buffer of this format is to be used as an OpenGL ES texture, the
292 * framework will assume that sampling the texture will always return an
293 * alpha value of 1.0 (i.e. the buffer contains only opaque pixel values).
294 *
295 */
296 HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED = 0x22,
297
Alex Raye13f15a2013-03-19 01:41:32 -0700298 /*
299 * Android flexible YCbCr formats
300 *
301 * This format allows platforms to use an efficient YCbCr/YCrCb buffer
302 * layout, while still describing the buffer layout in a way accessible to
303 * the CPU in a device-independent manner. While called YCbCr, it can be
304 * used to describe formats with either chromatic ordering, as well as
305 * whole planar or semiplanar layouts.
306 *
307 * struct android_ycbcr (below) is the the struct used to describe it.
308 *
309 * This format must be accepted by the gralloc module when
310 * USAGE_HW_CAMERA_WRITE and USAGE_SW_READ_* are set.
311 *
312 * This format is locked for use by gralloc's (*lock_ycbcr) method, and
313 * locking with the (*lock) method will return an error.
314 */
315 HAL_PIXEL_FORMAT_YCbCr_420_888 = 0x23,
316
Iliyan Malchev66ea3572011-05-01 14:05:30 -0700317 /* Legacy formats (deprecated), used by ImageFormat.java */
318 HAL_PIXEL_FORMAT_YCbCr_422_SP = 0x10, // NV16
319 HAL_PIXEL_FORMAT_YCrCb_420_SP = 0x11, // NV21
320 HAL_PIXEL_FORMAT_YCbCr_422_I = 0x14, // YUY2
321};
322
Alex Raye13f15a2013-03-19 01:41:32 -0700323/*
324 * Structure for describing YCbCr formats for consumption by applications.
325 * This is used with HAL_PIXEL_FORMAT_YCbCr_*_888.
326 *
327 * Buffer chroma subsampling is defined in the format.
328 * e.g. HAL_PIXEL_FORMAT_YCbCr_420_888 has subsampling 4:2:0.
329 *
330 * Buffers must have a 8 bit depth.
331 *
332 * @y, @cb, and @cr point to the first byte of their respective planes.
333 *
334 * Stride describes the distance in bytes from the first value of one row of
335 * the image to the first value of the next row. It includes the width of the
336 * image plus padding.
337 * @ystride is the stride of the luma plane.
338 * @cstride is the stride of the chroma planes.
339 *
340 * @chroma_step is the distance in bytes from one chroma pixel value to the
341 * next. This is 2 bytes for semiplanar (because chroma values are interleaved
342 * and each chroma value is one byte) and 1 for planar.
343 */
344
345struct android_ycbcr {
346 void *y;
347 void *cb;
348 void *cr;
349 size_t ystride;
350 size_t cstride;
351 size_t chroma_step;
352
353 /** reserved for future use, set to 0 by gralloc's (*lock_ycbcr)() */
354 uint32_t reserved[8];
355};
Iliyan Malchev66ea3572011-05-01 14:05:30 -0700356
357/**
358 * Transformation definitions
359 *
360 * IMPORTANT NOTE:
361 * HAL_TRANSFORM_ROT_90 is applied CLOCKWISE and AFTER HAL_TRANSFORM_FLIP_{H|V}.
362 *
363 */
364
365enum {
366 /* flip source image horizontally (around the vertical axis) */
367 HAL_TRANSFORM_FLIP_H = 0x01,
368 /* flip source image vertically (around the horizontal axis)*/
369 HAL_TRANSFORM_FLIP_V = 0x02,
370 /* rotate source image 90 degrees clockwise */
371 HAL_TRANSFORM_ROT_90 = 0x04,
372 /* rotate source image 180 degrees */
373 HAL_TRANSFORM_ROT_180 = 0x03,
374 /* rotate source image 270 degrees clockwise */
375 HAL_TRANSFORM_ROT_270 = 0x07,
Mathias Agopian96675ed2013-09-17 23:48:54 -0700376 /* don't use. see system/window.h */
377 HAL_TRANSFORM_RESERVED = 0x08,
Iliyan Malchev66ea3572011-05-01 14:05:30 -0700378};
379
Alex Rayc9f3bcf2013-11-26 16:50:46 -0800380/**
381 * Colorspace Definitions
382 * ======================
383 *
384 * Colorspace is the definition of how pixel values should be interpreted.
385 * It includes primaries (including white point) and the transfer
386 * characteristic function, which describes both gamma curve and numeric
387 * range (within the bit depth).
388 */
389
390enum {
391 /*
392 * Arbitrary colorspace with manually defined characteristics.
393 * Colorspace definition must be communicated separately.
394 *
395 * This is used when specifying primaries, transfer characteristics,
396 * etc. separately.
397 *
398 * A typical use case is in video encoding parameters (e.g. for H.264),
399 * where a colorspace can have separately defined primaries, transfer
400 * characteristics, etc.
401 */
402 HAL_COLORSPACE_ARBITRARY = 0x1,
403
404 /*
405 * YCbCr Colorspaces
406 * -----------------
407 *
408 * Primaries are given using (x,y) coordinates in the CIE 1931 definition
409 * of x and y specified by ISO 11664-1.
410 *
411 * Transfer characteristics are the opto-electronic transfer characteristic
412 * at the source as a function of linear optical intensity (luminance).
413 */
414
415 /*
416 * JPEG File Interchange Format (JFIF)
417 *
418 * Same model as BT.601-625, but all values (Y, Cb, Cr) range from 0 to 255
419 *
420 * Transfer characteristic curve:
421 * E = 1.099 * L ^ 0.45 - 0.099, 1.00 >= L >= 0.018
422 * E = 4.500 L, 0.018 > L >= 0
423 * L - luminance of image 0 <= L <= 1 for conventional colorimetry
424 * E - corresponding electrical signal
425 *
426 * Primaries: x y
427 * green 0.290 0.600
428 * blue 0.150 0.060
429 * red 0.640 0.330
430 * white (D65) 0.3127 0.3290
431 */
432 HAL_COLORSPACE_JFIF = 0x101,
433
434 /*
435 * ITU-R Recommendation 601 (BT.601) - 625-line
436 *
437 * Standard-definition television, 625 Lines (PAL)
438 *
439 * For 8-bit-depth formats:
440 * Luma (Y) samples should range from 16 to 235, inclusive
441 * Chroma (Cb, Cr) samples should range from 16 to 240, inclusive
442 *
443 * For 10-bit-depth formats:
444 * Luma (Y) samples should range from 64 to 940, inclusive
445 * Chroma (Cb, Cr) samples should range from 64 to 960, inclusive
446 *
447 * Transfer characteristic curve:
448 * E = 1.099 * L ^ 0.45 - 0.099, 1.00 >= L >= 0.018
449 * E = 4.500 L, 0.018 > L >= 0
450 * L - luminance of image 0 <= L <= 1 for conventional colorimetry
451 * E - corresponding electrical signal
452 *
453 * Primaries: x y
454 * green 0.290 0.600
455 * blue 0.150 0.060
456 * red 0.640 0.330
457 * white (D65) 0.3127 0.3290
458 */
459 HAL_COLORSPACE_BT601_625 = 0x102,
460
461 /*
462 * ITU-R Recommendation 601 (BT.601) - 525-line
463 *
464 * Standard-definition television, 525 Lines (NTSC)
465 *
466 * For 8-bit-depth formats:
467 * Luma (Y) samples should range from 16 to 235, inclusive
468 * Chroma (Cb, Cr) samples should range from 16 to 240, inclusive
469 *
470 * For 10-bit-depth formats:
471 * Luma (Y) samples should range from 64 to 940, inclusive
472 * Chroma (Cb, Cr) samples should range from 64 to 960, inclusive
473 *
474 * Transfer characteristic curve:
475 * E = 1.099 * L ^ 0.45 - 0.099, 1.00 >= L >= 0.018
476 * E = 4.500 L, 0.018 > L >= 0
477 * L - luminance of image 0 <= L <= 1 for conventional colorimetry
478 * E - corresponding electrical signal
479 *
480 * Primaries: x y
481 * green 0.310 0.595
482 * blue 0.155 0.070
483 * red 0.630 0.340
484 * white (D65) 0.3127 0.3290
485 */
486 HAL_COLORSPACE_BT601_525 = 0x103,
487
488 /*
489 * ITU-R Recommendation 709 (BT.709)
490 *
491 * High-definition television
492 *
493 * For 8-bit-depth formats:
494 * Luma (Y) samples should range from 16 to 235, inclusive
495 * Chroma (Cb, Cr) samples should range from 16 to 240, inclusive
496 *
497 * For 10-bit-depth formats:
498 * Luma (Y) samples should range from 64 to 940, inclusive
499 * Chroma (Cb, Cr) samples should range from 64 to 960, inclusive
500 *
501 * Primaries: x y
502 * green 0.300 0.600
503 * blue 0.150 0.060
504 * red 0.640 0.330
505 * white (D65) 0.3127 0.3290
506 */
507 HAL_COLORSPACE_BT709 = 0x104,
508};
509
Mathias Agopianc9b06952011-08-11 22:35:31 -0700510#ifdef __cplusplus
511}
512#endif
Iliyan Malchev66ea3572011-05-01 14:05:30 -0700513
514#endif /* SYSTEM_CORE_INCLUDE_ANDROID_GRAPHICS_H */