android camera HAL v3.0详细介绍（一）

1. Requests

Application framework层向camera子系统发出一系列捕获数据的请求。一个请求对应于结果中的一个单元。请求封装了这些结果关于捕获数据和处理数据的所有配置信息。这些信息包括：分辨率，像素格式，sensor调整，镜头和闪光灯控制，3A操作模式，RAW转YUV处理，统计信息产生，等等。这里考虑了很多关于对结果数据的输出和处理的控制。多个请求可以一次性发出，提交请求是非阻塞模式。这些请求总是按照被接收到的顺序来处理。



[align=left] [/align]

Figure1. Camera model

2. The HAL and camera subsystem

Camera子系统包括camera流水线上各个组件的实现，比如3A算法及其处理控制。Camera HAL层为你实现这些组件提供了接口。为了保持对多个设备制造商和图像信号处理器（ISP，或者camera sensor）供应商之间的跨平台兼容性，camera流水线模块是虚拟的，并没有直接对应任何真实的ISP。但是，它与真实的处理流水线很相似，以便你能够高效地将它映射到你的硬件。另外，它很抽象，在质量，性能或者跨设备兼容性方面，不需要任何妥协就可以支持多个不同算法和操作指令。

The camera pipeline also supports triggersthat the app framework can initiate to turn on things such as auto-focus. Italso sends notifications back to the app framework, notifying apps of eventssuch
as an auto-focus lock or errors.

Camera流水线也支持触发器，app framework能够初始化并打开它，比如自动聚焦。它也能向app framework发送通知，通知app关于自动聚焦被锁或者错误的事件。



[align=left] [/align]
Figure2. Camera pipeline

请注意，在最初发布的版本中，上述图表中的一些图像处理模块并没有被很好地定义。Camera流水线做了如下的假设：
· 输出的RAW Bayer数据在ISP内部没有经过任何处理；
· 生成的统计数据是基于raw sensor的输出数据；
· ISP中，将raw sensor的输出数据转换为YUV格式的各个处理模块没有严格的先后次序；
· 虽然展示了多个缩放和裁剪单元，但是所有的缩放单元共用一个输出区域控制（比如数字变焦）。但是每个单元可以有不同的输出分辨率和像素格式。
注：数字变焦是根据变焦倍数，从原始图像中裁剪一部分，然后放大到原始分辨率。由于是使用缩放算法直接放大的，所以其图像质量会降低。上图有三个缩放/裁剪单元，但它们共用一个输出控制器，即request
control，由它来决定输出到外部缓冲区。根据application framework层的需求，最上面的缩放/裁剪单元会对从raw
sensor采集的数据进行裁剪和缩放，最后输出到外边缓冲区。中间和下面的缩放/裁剪单元都是对ISP处理之后的YUV数据进行处理。中间的单元对YUV进行裁剪并缩放后，调用JPEG编码器对其进行编码，输出JPEG图像。下面的单元对YUV进行裁剪并缩放后，输出不同分辨率的YUV数据。这三个缩放/裁剪单元对输入数据也可以不进行裁剪和缩放处理。
API使用总结
这是android camera API使用步骤的简单总结。查看“ Startup
and expected operation sequence”可以获得这些步骤的详细分解，以及API的调用。
1. 监听并枚举所有camera设备；
2. 打开设备并连接监听器；
3. 配置目标用例所需的输出信息（比如静态图片，视频录制等）
4. 根据目标用例创建请求；
5. 发送或者重复发送这些请求；
6. 接收输出的元数据和图像数据；
7. 切换用例，则跳转到第3步；
HAL层操作总结
· Framework层发送捕获数据的异步请求。
· HAL层设备必须按照次序处理请求。对于每个请求，HAL层需要输出元数据和一个或者多个图像数据。
· 对于请求和结果都需要遵循先进先出的原则；这个数据流将被后续的请求所参考。
· 对于同一个请求，所有输出数据的时间戳必须相同，以便framework层同步输出数据，如果需要的话。
· 在请求和结果数据总，所有捕获数据的配置和状态（除了3A处理），都需要封装起来。



[align=left] [/align]
Figure3. Camera HAL overview
（未完待续）