【Camera专题】Qcom-你应该掌握的Camera调试技巧2

Posted 2023-04-30

参考技术A

系列文章
【Camera专题】Qcom-你应该掌握的Camera调试技巧1
【Camera专题】Qcom-你应该掌握的Camera调试技巧2

数量：
adb shell setprop persist.vendor.camera.isp.dump_cnt 20

增加性能日志：Tag：[KPI_CAMERA]
日志打印：

kernel/arch/arm/boot/dts/qcom/msm8909.dtsi

I2C资料：80-NU767-1，参考68-69页

举个例子：
i2c速率（I2C_FS_CLK ）：400k
I2C_CLK：24M
占空比改成：50%

I2C_FS_CLK = I2C_CLK/(fs_div+hs_div+6)
fs_div + hs_div = 24M/400k - 6 = 60-6=54
如果占空比为50%
则
fs_div=hs_div=54/2=27

kernel/arch/arm/boot/dts/qcom/msm8909.dtsi

I2C节点解释：
kernel/Documentation/devicetree/bindings/i2c/i2c-msm-v2.txt

git diff > a.patch
patch -p1 < a.patch

查看pd lib库
adb shell setprop persist.vendor.camera.pdaf_logging 1
then reset device. version will be print out like "PDLib Version: Major: %d Minor: %d Revision: %d"

lib库和校准工具对应关系
PD_lib_version Calibration_Version
3.3 J
4.2 J,L3
4.4 J,L3
4.5 J,L3,L4
4.6 J,L3,L4
4.7 J,L3,L4
5.0 L3,L4
5.1 L3,L4
5.2 L3,L4
5.3 L3,L4

关键log

注意，如果pdaf版本库在4.5-5.3之间，OV的sensor left map和right map 和高通是相反的
即：

op_pixel_clk = (传感器总数据传输速率) / 每个像素的位数
op_pixel_clk = sensor_MIPI_speed*lanes/每个像素的位数

传感器总数据传输速率 = sensor_MIPI_speed*lanes

vt_pixel_clk= HTS（0x380c/0x380d）* VTS(0x380e/0x380f)*FPS
op_pixel_clk=sensor_MIPI_speed*lanes/bits-per-pixel

adb shell dumpsys window | findstr mCurrentFocus

adb shell dmesg > kernel.log

1.对焦速度 af_haf_util_end_search

adb root
adb shell setprop persist.vendor.camera.stats.is.debug 5

关键log: eis2_process

经过odex 的apk ，这样apk 是不完整的。
相机 mk 里加上 LOCAL_DEX_PREOPT := false

module_sensor_load_chromatix_stream_on

1.最终的 AF ROI 坐标和大小，如何从 log 中获取？
key word:

0.200000f, /* H Clip Ratio Normal Light /
0.200000f, / V Clip Ratio Normal Light /
0.500000f, / H Clip Ratio Lowlight /
0.500000f, / V Clip Ratio Lowlight */

1、请问 Calculated new ROI 的大小是怎么计算的？
ctr_x = image_width / 2;
ctr_y = image_height / 2;
dx = image_width * h_ratio * zoom_factor;
dy = image_height * v_ratio * zoom_factor;
x = ctr_x < (roi_out->dx / 2) ? 0 : (ctr_x - (roi_out->dx / 2));
y = ctr_y < (roi_out->dy / 2) ? 0 : (ctr_y - (roi_out->dy / 2));
2、假设 CAF 默认以中心为 ROI，那么 APP 有接口可以修改 ROI 的位置吗？
As you can see from 1(formula), no parameters are passed to change this value.

adb shell setprop persist.vendor.camera.cal.dump 1
数据路径："/data/misc/camera/" 或者"/data/vendor/camera/"

8909：

新:

1.开机log里面搜索fdt
OF: fdt:Machine model: Qualcomm Technologies, Inc. SDM429 QRD Spyro DVT Overlay
2.搜索"Qualcomm Technologies, Inc. SDM429 QRD Spyro DVT Overlay"

3.打开kernel/msm-4.9/arch/arm64/boot/dts/qcom/sdm429-spyro-qrd-dvt-overlay.dts

adb shell debuggerd -b <camera process PID>

persist.vendor.debug.set.fixedfps

adb logcat -c && adb logcat -G 256M && adb logcat -v threadtime -b main -b crash -b kernel 1 > log.txt

aec_settle

ISO = (analog_gain*100)/ISO_100_gain。
效果参数中 ISO_100_gain =1

adb shell dumpsys media.camera

adb shell setprop persist.vendor.camera.HAL3.enabled 1

当我们用mmm编译时，可能找不到某些依赖，又不想又mmma编译。
比如：
mmm packages/apps/Camera2

再编译 mmm packages/apps/Camera2

<uses-feature android:name="android.hardware.type.watch" />

adb shell input keyevent 27
//拍照键

关键字：alg_status
01-02 09:02:12.920 235 2894 D ae_lib : 2429, ae1_calculateEX: alg_status:146 stab: 0, status: 0, flicker: 0, fps: 1.07, effect-(s 34464(0.935698s), g 128, dmy 0), final to sensor: idx: 271, (3683(0.099993s), 0, 581), cur_lum: 133, bv:520, tar_lum [62, 66]

adb shell stop media
adb shell start media

adb shell stop cameraserver

adb shell kill -9 进程ID

frameworks/av/services/camera/libcameraservice/CameraService.cpp

hardware/qcom/camera/QCamera2/HAL/QCamera2HWICallbacks.cpp

typedef int64_t nsecs_t;

例如：
kernel/drivers/misc/sprd_camera/dcam/dcam_if_r4p0/dcam_ioctrl.
要在makefile中添加你要的调用的路径

adb root
adb shell
读： lookat -l 1 0x40388D2C
写： lookat -s 0x00000081 0x40388D2C

frameworks/av/camera/CameraParameters.cpp

adb shell setprop debug.camera.mf 2
adb shell setprop debug.camera.mf_pos 100

#define VAR_UNUSED(x) (void)(x)

原因：

so后面多了个空格，吐血了！！！
删掉空格后就ok了：

hardware/qcom/camera/QCamera2/HAL/test
vendor/bin/dual_camera_test

kernel/msm-4.9/arch/arm64/boot/dts/qcom/msm8937-pinctrl.dtsi
kernel/msm-4.9/arch/arm64/boot/dts/qcom/sdm429-spyro-qrd-evt-camera.dtsi

Camera ISP-知识大纲

随着工作时限的增长，与工作相关的知识点已经开始慢慢的从一个个孤立的点向着还尚未成型的网进化而去，虽然还未完全成型，但是基本的轮廓已然影影绰绰。为了对知识面进行一个总结归纳，也为了巩固并拓展目前的知识面，所以准备开一个新的专题，就是 Camera 的 ISP 知识专题，这个专题应该会成为一个长期更新的专题。

到现在为止 Camera ISP 仍然在总体上还是一个偏经验的东西，就是说它不是一个标准化的流程，ISP 全称：Image Signal Processor。它不是一个具体的什么模块，而是一个流程，目的就是把 Camera 图像传感器收集到的图像从电平信号转换为可存储的像素数据，并且要使得输出图像效果要符合每家厂商的主观审美。而市面上会生产 ISP 软硬件的消费品公司我们熟知的就是手机和数码相机，而众所周知，各家的图像效果又是不一样的，这个不一样不是某几块不一样，而是整个整体观感都是不一样的，所以从这个角度来看也可以说它不是一个标准化的流程，而是有着极大的创作灵活度的。

而在 ISP 这个庞大的流程当中，自然也不可能全是不可捉摸的经验，还是有很多很多的基础理论的，这些理论本质上是标准化的，只是说应用的时候大家用法不太一样。而这个系列就打算穿插这些统一的理论和一部分不一样的应用来对自己的工作进行复习巩固和拓展。基本上内容可以分为下面几个大的方面：

1. ISP 的基础理论，比如说色彩原理、像素定义、基本概念等等。
2. 部分的 ISP 实时渲染处理以及后处理相关的知识，比如说 Gamma 矫正，色彩矫正、镜头阴影矫正、降噪、色调映射等等。
3. 图像的仿射变换、翘曲等等。
4. 人工智能在 ISP 处理当中的应用。

ISP 基础理论

这个其实没有明确的定义，反正按照我自己的归类去写了，具体来说大概就是色彩原理，曝光、摄影基本概念等等，会大量参考：https://www.cambridgeincolour.com/learn-photography-concepts.htm 这里的文章。这些基本上是属于完全的理论知识部分，怎么说呢，就有点像是内功心法这个感觉，但又不完全是，相当于是一个入门的概念解析吧。

这部分我也没有全部看过，都是在工作当中的被动学习以及少部分主动了解的，属于是一种无意识的知识接纳，所以这块对于我自己来说也是一个归整的时机，让自己更多的去了解一个基础的概念性质的知识点，相信对自己还是有不少帮助的。

实时处理、后处理

后处理这部分应该是涵盖范围最广的，Image Warp 也可以归入此类，不过我就分出来了，作为两个部分去写，属于我自己的分类喜好。这部分的处理主要是对图像的质量进行矫正，比如说噪声消除、色彩矫正、亮度对比度调整、色调映射等等。

下一篇计划写的就是 Gamma 这部分，广义上的 Gamma 矫正应该占到了差不多百分之二三十的后处理，包括局部色调映射和全局色调映射应该都是可以算做叫 Gamma 矫正的。剩下一大部分就是降噪和 HDR，然后还有一部分色彩映射边缘增强之类的，其中的重点就是降噪和 HDR，降噪又分为空域降噪和时域降噪，分别有不同的优缺点，这点后面也会提及。而 HDR 则是今年比较关注的部分，因为现在夜景的拍照和视频已经卷到了一定的程度，尤其是华为的夜景起了个卷王的开头，后面手机影像有很大一部分也是关于夜景的比拼了。

这部分我觉得应该会分为：Gamma，LTM，GTM，HDR，降噪等这几个大的部分去写写。

图像变换

这里主要就是说图像的翘曲变换，可以做的常规功能有畸变校正、Roll shutter 矫正、图像防抖、多摄变焦对齐等，这部分的功能复杂度比较高，应该说相对于降噪和 HDR 来说算是复杂度更高一层的图像处理了，有点偏向于计算机视觉的感觉，当然，手机里面的翘曲变换受限于硬件算力等等，并没有计算机视觉里面那么变态。

这部分变换有一个特点就是需要对图像进行标定来获取镜头、sensor 的几何参数，然后再进行进一步的计算，所涉及到的运算有很大一部分都是线性代数、插值运算。图像变换除了多摄变焦对齐和 Roll shutter 矫正目前看起来必须软件算法参与之外，畸变校正和图像防抖一定程度上都是可以被硬件替代的，比如无畸变镜头、光学机械防抖，这些从硬件去做可以达到更好的效果，软件处理必不可少的已经丢失了一部分原始数据信息，再加上算法并不是完美的，得到的效果总是不如硬件方式来得好，不过受限于硬件的规格，软件算法处理这部分现在也是必须的辅助手段，不可缺少。

AI ISP

AI 现在已经有点想用一个 AI 节点处理所有 Raw 到 Jpeg/YUV 域的 ISP 流程，也就是说传统的 ISP pipeline 那么一长串在一定的条件下只需要一个 AI node 就可以替换出相似的效果，这个如果乍一看是有点吓人的，ISP 发展了这么多年就这么被一个 AI 节点给替代了，也代表着数万人的失业。目前为止传统的 ISP 还由于下面几个因素并没有被替换掉：

1. AI 的计算涉及到大量的硬件算力，目前还无法集成到手机实时影像处理的节点。
2. AI 并不能处理所有的场景，传统的 ISP 也是需要庞大的节点和 pipeline 才能够勉强覆盖到大多数场景。
3. 影像是一个比较偏向于主观感觉的东西，AI 调出来的画面目前并不具备完善的 tuning 参数来进行精细化控制，无法完成差异化的成像需求。

目前 AI ISP 也是想着把一部分传统 ISP 的节点用 AI 来进行替换，就有点儿类似把一个 AI 节点拆成一个个的特定 AI 模块，听起来是不是跟传统 ISP pipeline 一模一样了，现在就是这种状态，传统的 ISP 朝着 AI 的方向进化，相当于是把一整个 AI 节点拆分的过程逆化了，不知道最后能不能做到一个 AI 节点处理一切。