简介：索尼 IMX664-AAQR1-C CMOS 图像传感器官方数据手册，面向安防摄像机硬件设计、驱动开发与图像调试人员，可用于选型评估、电路设计、寄存器配置和规格核对，也可作为低功耗高清成像方案的参考依据。压缩包内仅含 1 个 PDF 文件，约 1.26MB，系统整理器件结构、绝对最大额定值、像素阵列、读取模式、帧率、HDR、同步传感器、变速快门、转换增益切换、CDS/PGA 及 CSI-2 接口等内容。正文给出 1/1.8 英寸、约 416 万有效像素、推荐记录像素 2688×1520、全像素扫描 12bit 90fps 与 10bit 120fps 等关键指标，并说明三重电源供电、HCG/LCG 模式、0～72dB 增益控制、窗口裁剪、水平/垂直 2/2-line binning、正反读取方式及 24MHz 至 74.25MHz 输入频率，同时覆盖 AR 涂层、低暗电流和无涂抹特性，便于快速确认设计边界、评估成像性能与定位调试方向。已有 258 人学习，尤其适合安防监控与宽动态视频捕捉场景中需要一手规格依据的硬件与嵌入式工程师查阅。

1. 4.08M 像素、90 fps、12 bit：三个数字背后是一条被压到极限的读出链路

翻开这份 imx664 datasheet，多数人先被 416 万像素和 1/1.8 英寸这两个数字吸引，真正值钱的却是另一行：12 bit 下 90 fps、10 bit 下 120 fps。同一颗 2.9 μm 方形像素的芯片，把位深做成了可以拿来换帧率的旋钮，而不是焊死的固定规格。这一行往下追，会牵出四种读出模式、一套片上时序发生器、两条完全不同的 HDR 路线和三路彼此独立的电源域。规格书把答案摊在几十页表格和时序图里，却几乎不解释为什么。下面按“这个数字怎么来的、为什么这么设计、实现上会在哪里出错”的顺序，把它拆开看一遍。

2. 像素与读出模式：2.9 μm 的方形像素怎么在四种扫描方式间切换

2.1 从 2704 到 2688：有效像素、主动像素、推荐记录像素的三级裁剪

规格书里同时给了四个数字：总像素 2704×1560（约 4.22 M）、有效像素 2704×1540（约 4.16 M）、主动像素 2704×1536（约 4.15 M）、推荐记录像素 2688×1520（约 4.08 M）。新手最容易犯的错是把它们当成同一件事的不同说法，实际上这是同一条读出链路上的四道裁剪，每收缩一级都对应一个具体的硬件理由。

先看垂直方向。总数 1560 行比有效像素 1540 行多出 20 行，规格书在光学黑像素那一项里写明“垂直方向：前沿 20 像素，后沿 0 像素”。这 20 行像素被遮光，输出的是纯粹的暗电平，后端用它做黑电平钳位和暗电流的温度补偿。安防摄像头长期工作在户外，暗电流随温度按指数规律变化，没有这 20 行参考，黑电平会随昼夜温差漂移，画面早晚两个时段看起来完全不是一个颜色。

再看水平方向。规格书写的是“前沿 0 像素，后沿 0 像素”，也就是水平方向根本没有光学黑像素。这意味着黑电平的参考只能取垂直那 20 行，或者干脆靠数字钳位。做长曝光或者高温场景时，这一点必须提前算进方案——很多开发者拿到的第一版图像左右两侧亮度不均，追到最后发现是没有做水平方向的自适应黑电平校正，而芯片本身不提供这个参考。

最后从主动像素 2704×1536 收窄到推荐记录像素 2688×1520，水平去掉 16 列、垂直去掉 16 行。去马赛克需要邻居像素，镜头边缘还有照度跌落和色差，边界像素的成像质量本来就不可用。推荐记录区等于把这圈不可靠的像素让出来，交给后端做插值和畸变校正。

# 像素账：从总面积到推荐记录区域的三级收缩 TOTAL = (2704, 1560) # 含 dummy / 光学黑的总像素 EFFECT = (2704, 1540) # 有效像素：垂直方向扣掉前沿 20 行光学黑 ACTIVE = (2704, 1536) # 主动像素：再去掉 4 行边界 RECORD = (2688, 1520) # 推荐记录像素：左右各留 8 列、上下再收 8 行 OB_ROWS = 20 # 规格书：垂直前沿 20 行光学黑，后沿 0 行 def mp(w, h): return w * h / 1e6 print(mp(*TOTAL)) # 4.218 约 4.22 M print(mp(*EFFECT)) # 4.164 约 4.16 M print(mp(*ACTIVE)) # 4.153 约 4.15 M print(mp(*RECORD)) # 4.086 约 4.08 M # 记录区相对主动区的偏移：水平居中；垂直居中还是贴边取决于读出方向 off_x = (ACTIVE[0] - RECORD[0]) // 2 # 8 off_y = (ACTIVE[1] - RECORD[1]) // 2 # 8 print(off_x, off_y)

这段代码的意义不在算力，而在建立一个坐标系。后面所有裁剪、合并、镜像的寄存器配置，都要落在“从哪一级算起”的约定上。把推荐记录区的左上角当成 (0,0)，和把主动区左上角当成 (0,0)，差了 8 行 8 列，画面会整体偏移一小格——肉眼几乎看不出，但在多目拼接里就是接缝对不上。

2.2 2/2 行合并为什么能把灵敏度翻四倍却只掉一半分辨率

规格书列的第一种非全像素读出模式是“水平/垂直 2/2 行合并”。2688×1520 经过 2×2 合并变成 1344×760，约 1.02 M 像素，像素数掉到四分之一，但每个输出像素对应 4 个物理像素的感光面积。

灵敏度账是这么算的：4 个像素的电荷相加，信号变成 4S；光子散粒噪声按平方根增长，变成 2√S；信噪比提升 2 倍，也就是 6 dB。这在安防场景里是救命级别的改善——夜间路灯下的车牌，全像素模式下噪点满屏，binning 之后细节虽然糊了，但轮廓和颜色能立住。

有意思的是帧率。理论上行数减半、列数减半，行时间与帧时间同时减半，帧率能提升 4 倍。但这颗芯片的接口带宽已经先撞墙了，全像素 12 bit 90 fps 的净荷就压在 4.4 Gbps 上，binning 省下来的带宽如果全拿去换帧率，链路根本扛不住。所以在这颗传感器上，2/2 合并的现实收益主要是三件事：暗光下的信噪比、后端 ISP 的负载（数据量降到四分之一）、以及在 2 lane 配置下还能跑得动的余量。帧率提升反而排在后面。

提示：合并发生在电荷域还是数字域，噪声表现不一样。电荷域合并只经一次读出电路，数字域合并要把 4 个像素各自读出再相加，读出噪声叠 4 次。规格书只写“行合并模式”，具体在哪一级做，要看寄存器表里对应的读出路径配置。

2.3 窗口裁剪与正反读：ROI 与镜像的坐标系对齐

窗口裁剪模式是给“我只关心画面中间那一块”的场景准备的。裁剪掉的行不再被读出，帧时间按比例缩短，帧率线性上升。安防里的典型用法是：白天全视野监控，夜间只对出入口做高帧率抓拍，同一个模组切两套窗口参数。

但裁剪有两个硬约束。第一，变速快门的分辨率是 2H 单位，也就是曝光时间的调整步进等于 2 个行周期，所以窗口的起点和高度最好按 2 的整数倍对齐，否则曝光计算会出现半行误差。第二，正/反读模式会把读出方向翻过来，坐标系跟着翻转——从右下角开始读，你原来填的裁剪起点语义就变了。吊装摄像头必须开反读，这一条如果没在驱动里同步处理，出图就是上下颠倒而且裁剪位置也不对。

def align_crop(x, y, w, h, step=2): """按 2 像素对齐裁剪窗口，匹配 2H 的快门分辨率单位""" x = (x // step) * step y = (y // step) * step w = (w // step) * step h = (h // step) * step return x, y, w, h def fps_after_crop(h_win, v_win, h_full=2688, v_total=1600, fps_full=90): """粗略估算：行时间随每行像素数线性变化，帧时间随行数线性变化""" line_scale = h_win / h_full frame_scale = v_win / v_total return fps_full / (line_scale * frame_scale) print(align_crop(513, 257, 1920, 1080)) # (512, 256, 1920, 1080) print(fps_after_crop(1920, 1080)) # 约 163 fps，受链路带宽封顶

这里的v_total取 1600 行是估算值，真实值取决于帧消隐配置，代码只用来判断“裁剪能不能把帧率拉到我需要的量级”。算出来 163 fps 明显超出接口能力，说明实际会被 4.4 Gbps 的链路卡在 90 fps 附近——裁剪在高帧率场景下真正的价值是降低单帧数据量，而不是无限提帧率。

3. 带宽与帧率：90 fps 是怎么被算出来的，主从同步又靠哪几根线

3.1 12 bit 90 fps 与 10 bit 120 fps 的净荷算术

把推荐记录像素、位深、帧率乘一遍，就能得到这颗芯片的数据出口压力。这不是理论练习，链路规划错了，后面所有参数调整都是白费。

W, H = 2688, 1520 for bits, fps in ((12, 90), (10, 120)): payload = W * H * bits * fps print(f"{bits}bit @ {fps}fps -> {payload/1e9:.3f} Gbps 净荷") for lane in (2, 4): print(f" {lane} lane: {payload/lane/1e9:.3f} Gbps/lane")

输出是：12 bit 90 fps 约 4.413 Gbps，10 bit 120 fps 约 4.903 Gbps。按 4 lane 摊，每 lane 的净荷分别是 1.103 Gbps 和 1.226 Gbps；加上 CSI-2 的包头包尾、行尾填充和 EoT，经验系数取 1.1～1.2，实际线速率会落在 1.35～1.47 Gbps/lane 这个区间——这是 D-PHY 非常好做的档位，功耗和信号完整性都舒服。

反直觉的地方在这里：帧率从 90 提到 120，涨了 33%，带宽只涨了 11%。原因很简单，位深从 12 降到 10，单像素数据量少了六分之一，正好抵掉大部分帧率增幅。这也解释了规格书为什么要把这两个数字并排写——它们不是两个独立规格，而是同一条链路上的两种等价配置。

3.2 CSI-2 的 2 lane 与 4 lane：什么时候 2 lane 就是不够用

规格书支持 2 lane 和 4 lane 两种 CSI-2 输出，RAW10 和 RAW12 两种打包格式。乍看 2 lane 更省引脚、更省布线，成本也更低，但把上面那张表第三列翻出来看：2 lane 在 10 bit 120 fps 下每 lane 要扛 2.451 Gbps 净荷，加上协议开销接近 2.8 Gbps。这个速率在短走线、好板材上勉强能跑，一旦模组要过排线、过连接器，眼图就废了，误码表现为随机的行错位或者整帧丢失。

所以 2 lane 的真实定位是“降配场景”：binning 输出、裁剪输出、或者帧率不拉满的常驻预览。4 lane 才是全像素 90/120 fps 的默认配置。选型时先算净荷，再决定 lane 数，不要反过来——先定 2 lane 再去找能跑的模式，最后往往被迫降帧率，而帧率是安防里最不该妥协的参数之一。

3.3 XMASTER、XVS/XHS 与 XCLR：主从模式的时序约定

输入时钟给了五档：24 MHz、27 MHz、37.125 MHz、72 MHz、74.25 MHz。这几个数字不是随便挑的。24 和 27 是通用晶振和 MCU 时钟体系的常见档位，方便直接用系统已有 clock 省一颗晶振；37.125 与 74.25 正好是 2 倍关系，而 74.25 MHz 又是高清视频像素时钟体系里的常见档位。换句话说，这颗芯片可以直接接收后端视频时钟域的时钟，不需要额外的时钟发生芯片，多设备同源也就顺带解决了。

同步是另一套机制。XMASTER 引脚为高时芯片工作在从模式，接收外部送进来的 XVS/XHS；为低时工作在主模式，自己输出 XVS/XHS。多传感器系统里，一颗主片输出帧同步和行同步，其余从片接收，做到逐帧对齐。这套机制解决的是“多目同时曝光”的问题——如果靠软件发命令去对齐，命令传输的抖动就有几十微秒，两个摄像头的曝光窗口错开，拼接画面里运动目标就会出现撕裂。

XCLR 是系统复位。它的释放时机很关键：必须在输入时钟稳定之后，否则芯片内部的时序调整电路锁到一个不干净的时钟上，寄存器状态会变得不可预期。常见的实现思路是“电源建立 → 时钟稳定 → 等若干毫秒 → 释放 XCLR → 等内部初始化完成 → 再发 I2C”，中间每一步的间隔都能在规格书的时序图里找到最小值，照抄即可，不要凭感觉压时间。

4. HDR 的两条路线：数字重叠 HDR 与 Clear HDR 各自把动态范围花在哪

4.1 数字重叠 HDR：多曝光合成的时序账

数字重叠 HDR 的思路是把不同曝光长度的多帧在时间上部分重叠地读出来，再在数字域合成。片上时序发生器负责产生长短曝光的读出序列，输出多路数据交给后端。

它的好处是动态范围可以堆得很高。两曝光合成通常能到 100 dB 以上，三曝光还能再往上。代价是采样时刻不一致：长曝光在 t0 到 t1 积分，短曝光在 t1 到 t2 积分，同一个运动目标在两个曝光里位置不同，合成后边缘就会出现重影。安防场景里这个伪影特别明显——夜间门口走过一个人，轮廓上会挂一圈半透明的“鬼影”。

还有一个隐患是光源闪烁。在 50 Hz 工频光源下，长短曝光的积分窗口落在不同的纹波相位上，合成后画面会出现横向的明暗条纹。血泪经验是把曝光时间取成工频周期的整数倍或半整数倍，让每个曝光窗口覆盖完整的纹波周期。这一条规格书不会写，但现场调试绕不开。

4.2 Clear HDR：单次曝光内做分段的代价

Clear HDR 走的是另一条路：在一次曝光里，同一时刻在像素内部保留高、低两个转换增益的电荷，读出时得到两路信号。因为两路信号来自同一个时间点，运动伪影这个问题从根上就不存在，工频闪烁也不再有相位差。

代价有两块。第一，动态范围受限于像素内部两个电荷存储节点的容量比，提升幅度比多曝光合成保守；第二，像素结构更复杂，2.9 μm 的单元尺寸里要挤出额外的电容，填充因子和暗电流都要做妥协。规格书把转换增益切换单独列成一条特性（HCG / LCG 模式），就是在暗示这条路径依赖像素内的电容切换。

选型时的判断很直接：拍静态场景、追求极限动态范围，选数字重叠；拍运动目标、对伪影零容忍（卡口抓拍、道闸识别），选 Clear HDR。两者不是新旧替代关系，是两个不同的工程取舍。

4.3 HCG/LCG 与 CDS/PGA：增益链上的每一级到底在救什么

规格书里那段增益描述值得逐字读：“0 dB 到 30 dB：模拟增益，步进 0.3 dB；30.3 dB 到 72 dB：模拟增益 30 dB + 数字增益 0.3 dB 到 42 dB，步进 0.3 dB”。前半段和后半段是完全不同的东西，很多开发者把 72 dB 当成“72 dB 的模拟增益”，然后抱怨暗光下噪点大得没法看。

也就是说，30 dB 是模拟链路的物理上限，再往上拉的 42 dB 全是数字乘法，相当于在 ISP 里调亮度。暗光下真正有效的手段只有三个：切到 HCG 提高转换增益、延长积分时间、开 2/2 合并增加感光面积。把增益从 40 dB 拉到 60 dB，画面确实亮了，但那只是把噪声一起放大了 20 dB。

再往前一级是 CDS。相关双采样先读复位电平、再读信号电平，两者相减，把复位噪声和像素固定模式噪声压掉。这是 CMOS 传感器能做出低暗电流、低固定模式噪声的基础，没有 CDS，后面所有增益都是在一个脏信号上做乘法。

HCG 和 LCG 的物理含义是转换增益：HCG 用小电容，一个电子换来的电压更大，读出噪声折算到输入端的等效电子数更低，适合低照度；LCG 用大电容，满阱容量更大，高光不过曝。这条切换通常和 HDR 模式绑定使用——低照度段走 HCG，高光段走 LCG，相当于把动态范围从两端各拉一截。

5. 调试避坑：三类翻车现场与寄存器级排查

5.1 电源域：DVDD 的绝对最大值只有 2.0 V

现象：板子上电后 I2C 完全没有应答，芯片发烫。

原因：这颗芯片是三路电源——模拟 3.3 V、接口 1.8 V、数字 1.1 V。绝对最大额定值里，AVDD 和 OVDD 都是 -0.3 到 3.65 V，而 DVDD 只有 -0.3 到 2.0 V。数字域是 1.1 V 工艺，栅氧最薄，把 1.8 V 甚至 3.3 V 误接到 DVDD 上，一次上电就击穿。应用条件写得更紧：AVDD 3.20/3.30/3.40 V，OVDD 1.70/1.80/1.90 V，DVDD 1.00/

本文还有配套的精品资源，点击获取