sensor 上电，通过 MIPI协议传输，得到RAW图像数据。
RAW图像数据经过ISP处理，得到YUV图像数据。
YUV图像数据再经过DMA传输到DDR内存中，DDR内存也就是上图中标识的HOST。
每个厂家的 ISP原理和功能大致相同，像Auto Control(AEC、AF、AWB)都是在ISP里面做的，ISP里面还有 Raw Processing、Yuv Processing、Rgb Processing、Offline Processing（一般是去噪功能）。
每一个ISP里面都有一个MCU，MCU可以理解为一个处理器。ISP中的MCU需要上电工作，首先需要 load firmware。
sensor只会出一路数据，但是经过 ISP之后，同时会存在至少三路数据 preview_stream 、snapshot_stream、video_stream。怎么样从sensor的一路数据变成至少三路数据呢？这个就是 ISP内部做的事情，ISP内部可以将 sneosr出的一路数据拷贝分发成至少三路数据。
上图主要有三个部分组成：sensor、ISP、DDR。

ISP Pipeline diagram

以上流程图为 ISP工作处理流程图，每个厂商工作原理都差不多。
如果输入数据为 8bit，为了提高精度，会做一个 DC(data convert) 将8位数据转化为10位数据。
对于软件流程来说，我们最关心的是在什么阶段，图像数据是什么格式的？在DC之前，是Raw数据，在Demosaic之后是RGB数据，在CSC之后是YUV数据。在Linux/Andriod系统中 YUV数据是可以直接显示的，所以我们最关心的是 YUV数据。
在ISP里面，图像数据的转化为：RAW数据 --> RGB数据 --> YUV数据。

Simple Model

• only have mainly function nodes.

来具体看一个最简单的camera模型。sensor -> IIFE -> IPE -> Target(输出)。
sensor处理的是 RAW图像数据，作为HAL层，不能直接处理RAW图像数据，所以必须要经过IFE的处理，将RAW数据转化为YUV的数据。
经过IFE处理之后，又会经过一个IPE的模块，IPE的功能主要是：做去噪 + SAT图像裁切。
Target可以理解为：上层，FrameWork层想要的数据。比如：预览模式，Target就需要预览数据，拍照模式,Target就需要拍照数据，录像模式，Target就需要录像数据。
IFE、IPE 这些模块都是称为一个 node，每个node都有很多输入 port，也有很多输出 port。如果一个node的输出 port 连接到 Target，那么这个 port 就可以称为 SinkPort。如果一个 Node的输出 port连接到不是 Target，那么这个输出 port 就称为 NorSinkPort。
NorSinkPort 需要的 buffer 是我们自己申请的，SinkPort 需要的buffer 是 app层给的。

chi-cdk是客户自定义的所需要的功能。camx是高通的底层框架，一般手机厂商不会修改。如果用户需要新增功能，在chi-cdk中新增即可。
camx模块是一个 camera.qcom.so，chi-cdk模块也是一个 com.qti.chi.override.so。这两个so之间可以互相提供多个回调函数，通过 dlopen 进行相互调用。
frameworks 和 HAL层怎么通信的？framework给HAL下发一个 request，HAL需要回一个 notify(shutter)，3个result，其中2个 result 是 metadata，一个 result 是 imagebuffer。
framework下发一个 request -> camx -> chi-cdk -> camx -> kernel -> camx -> chi-cdk -> camx -> framework

如上图所示，上图是一个简单的apk，只有2路数据，一路数据是 preview数据，一路数据是 video数据。

如上图所示，Topology of Camera Formats 就是上图 apk所描述的2路流数据。sensor通过MIPI协议出一路 RAW数据，经过 IPE之后，变成了2路数据。一路是 preview流，另外一路是 video流。这就是 IPE 的拷贝分发功能。
Node的输出和输出 port 是通过 link 连接起来的。这种 link 关系是通过 XML来描述的。