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