HTLiuCL

3-光斑测试

6 min read

1、尽量使用#ifdef WITH_DSP，（不使用#ifndef，可能性会比较多） 2、内存的申请和释放是耗时操作，放到init和uninit里（op的成员变量） 3、代码格式化后过CI 4、考虑如果输入图已经是在设备内存上的情况（不需要再用hpc的接口申请内存和copy）

最终跑的环境过来的数据可能已经直接在设备内存上了（timalloc的），因为前面还有前处理op会把yuv转rgb

把这个op写成两个文件吧 blob_rect_process_op_ti_cpu.cpp blob_rect_process_op_ti_dsp.cpp 在cmake里用宏控制需要编译哪个

CUDA那些宏也就不用了 x86 nvidia的我们后面再写 blob_rect_process_op_nvidia_x86.cpp blob_rect_process_op_nvidia_aarch64.cpp

可以再改/写一个测试用例，pipeline前面再加一个yuv转rgb的操作，这样输入就是timalloc的了

ti上内存本身是不分设备的，但是在dsp上跑需要大页内存，timalloc带大页参数出来的就是。 前处理是用dsp做的，它的输入输出也得是大页

总结目标

  • 修改代码，改为cpu和dsp两个文件，去除代码内的宏，也去掉malloc和free，无法去掉的，写在成员变量中，在init做初始化（uninit）。修改后用宏指定编译对应版本文件
  • 改一个测试用例，pipeline前面再加一个yuv转rgb的操作，测试新的dsp代码
  • 代码测试完成后，格式化代码，提交topic，过CI
  • 等待review

需要在op里开的timalloc buffer

Histogram output buffer：histogram_hpc

size: 256 * sizeof(int)

MedianBlur input buffer: img_temp
size: in_height_* in_width_* sizeof(uint8_t) output buffer: img_temp_out
size: in_height_* in_width_* sizeof(uint8_t) 用于重新构造img_temp DiffRG output buffer : image_gray_tail.data
size: height_roi_tail * in_width_ * sizeof(uint8_t)

问题：

  • yuv的输入为1920*1080，询问是否需要更改
    • 需要改为1024x576，
  • yuv是什么格式，怎么使用，有没有分辨率
  • CI是什么、CI的流程
  • yuv转rgb后，与原图有差异
  • diffRG结果有问题
    • 原因是img_data_ptr的内存问题，改为tiMalloc后恢复正常（问题：传进来的不是已经是大页内存了吗？）
      • 没有注意到hwc2chw里面返回的还是Mat的默认内存
  • AdaptiveThreshold输出结果异常，thresh结果对比，dsp的thresh_out全为0，查找原因。
    • 已解决：类型转换的问题，原Mat的histogram为float类型，与nPixSum相除后仍为float类型，而DSP的histogram中元素为int类型，相除后会损失精度，造成差异
    • 另外，两个histogram的最后一个元素值不相同，但并未影响结果
//CPU
nProDis[i] = static_cast<float>(histogram.at<float>(i) / nPixSum);
//DSP
nProDis[i] = static_cast<float>(histogram[i] * 1.0 / nPixSum );

代码文件修改

  1. blob_rect_process_op.cpp变为： blob_rect_process_op_ti_cpu.cpp blob_rect_process_op_ti_dsp.cpp
  2. blob_rect_process_op.hpp文件添加4个成员变量，去掉了析构函数的default
  3. blob_det_utils.cpp分为 blob_det_utils_ti_cpu.cpp、blob_det_utils_ti_dsp.cpp两个文件
  4. blob_det_utils.hpp文件中添加了AdaptiveThresholdDSP的函数声明，其中加入了histogram buffer作为参数，以及ppl头文件
  5. senseauto-hozon-perception/perception_sdk/perception_camera下的CmakeLists.txt添加了WITH_DSP与WITH_CPU两个宏，并为DSP添加了HPC_INCLUDE_DIR与HPC_LIB_DIR
  6. 头文件和库
  7. 测试文件与测试图片
find . -regex '.*\.\(hpp\|h\)' -type f -exec clang-format-4.0 -style=file -i {} \;    # 对h/hpp文件进行格式化
find . -regex '.*\.\(cpp\|c\)' -type f -exec clang-format-4.0 -style=file -i {} \;

进度

merged：

  • hpc的头文件和库 - 3rdparty
  • hpc的三个算子 - camera
  • unittest_facula_yuv、test_image.yuv - interface
  • makefile ADCU -DBLOB_CAL_TYPE=“dsp” - perception

todo 测试光斑 分辨率问题 测试问题 json里面添加facula的配置 blob_rect…op没有unint，tiFree写在了op的析构函数中

REDO

问题

  1. 目前看来，pipeline没有正常工作，log一点也没输出，很奇怪、很迷惑 原因在于，新的代码不生成unittest所需的libs，因此我所做的任何改动，都根本没有影响到运行的库，一直用的是旧的库并且每次编译不会替换……（白搞了一天
  2. facula unittest崩溃，在frame.cpp或generic_proxy.hpp附近 自己搞半天真的不如先问一问，原来是车辆标定更新了😮‍💨

dsp耗时

histogram 326 us MedianBlur 1084 us ImageChannelDiffRG_CHW 348 us camera_pipeline Process cost: 15 ms.

std::cout << “thresh_out: ” << *thresh_out <<std::endl;

结果对齐

cpu的代码也变成这样了，应该是别的地方的问题 thresh_out: 200 thresh_out: 0 thresh_out: 40 -----7-----blob_num: 0

为什么yuv输入的cpu代码结果是正确的？？？

  • 原因是，代码写错了，都没读图片😂

Graph View