 ZXCLI
|
948c9d5d3d
|
tools: 照片差异定位三件套（帧剖面 / NUC 直出 / 条纹量化）+ 忽略 .tmp-* 对比目录
为"我们的照片与官方照片到底差在哪"提供可量化的手段，而不是靠肉眼看图：
- FrameProfile：对 160x120 载荷算行/列均值的步进与 3 抽头高频，并给出
「列高频 / 行高频」比值——列固定图案噪声会表现为该比值显著 >1，场景内容则接近 1。
同时对压缩块与"官方布局"（DDT 头 + 884B BasePara + 帧）都能定位载荷。
- NucDump：把 NUC 块按线性映射直出 PNG，用来判断成品图里的结构是"数据里有"
还是"显示级引入的"。
- StripeCheck：在成品图的平坦区域量列抖动，并给出它占局部量程的百分比。
实测结论（本轮）：我们的原始帧列高频 675 counts（列噪声主导，符合未校正预期），
而我们的 NUC 块只有 4.1 counts、行/列比 1.25，且成品图上平坦区列抖动仅为局部量程的
0.1% —— 即**校正后没有残留列噪声**，肉眼以为的竖纹是场景纹理。官方的成品帧（其文件
存的是校正后数据）同样干净（colHF 5.5、比值 1.39），两边校正质量等价。
.tmp-*/ 加入忽略：对比用的用户照片与中间产物放在那里，不入库。
|
2026-10-06 00:46:27 +08:00 |
|
|
ZXCLI
|
4a60011ed9
|
tools: 新增 MdtInspect —— 对比本 App 与官方照片的差异定位工具
用户反馈"这个 App 拍出来的照片和官方软件还是有区别"，即将提供两张对照照片。
先把这个工具准备好，文件到手即可定位差异出在哪一层，而不是凭肉眼猜。
按三层从外到内报告：
1. 容器层：是否厂商 MDT（JPEG + DDT 块 + 尾）、有哪些块、各多大、RENDER 参数
（翻转/旋转）——先排除结构性差异；校准文件（magic 5AA5000x）会被识别并说明
它描述的是传感器而非场景。
2. 数据层：FRAME（原始测量帧）与 NUC 块的 min/mean/max/spread。**这一层若不同，
差异来自采集（传感器状态/FFC/标定），不是我们的配色映射**。
3. 图像层：JPEG 亮度分位数、均值、Laplacian 锐度。两个文件尺寸一致时还给出
逐项对比（亮度差、对比宽度差、锐度比）。
实测校验：对仓库内两张真机照片输出正常（960x720 rot=0 与 720x960 rot=90，
各块与极值/测点都能读出）；对两个标定文件正确识别为"非照片"并跳过对比。
.class 加入 .gitignore（原来是 manual_images 专用的）。
|
2026-10-05 23:01:31 +08:00 |
|
|
ZXCLI
|
6d0805af90
|
android: 恢复脚本+APK产物
|
2026-09-06 20:41:41 +08:00 |
|
|
ZXCLI
|
0bfb926892
|
完成官方管线全量逆向与 demo3 v5 复刻，清理仓库
- 逆向：Ghidra/IDA 全量反编译 CoreSDKLib.dll/ThermalSDK.dll/libthermalSDK.so/
libcoresdk.so(ARM64)/libmagcore.so，导出 analysis/ida/export/
- 解码官方渲染管线：DDT 校准表加载->快门端点选择->Q12 插值->ref(4x type1 帧
均值)->NUC 查表->盲元补偿->窗口->LUT1024 重建->2x 升采样->调色板
- 逐像素验证：NUC+盲元 0/19200、插值 0 误差、2x 0/76800、窗口一致
- demo3 v5：完整复刻官方管线（含 DDT 解析、FFC 状态机、快门温度驱动），
修复 load_ddt 表错位导致的零像素问题
- 鬼影根因分析写入 analysis/reverse_20260813_full.md
- 心跳/恢复机制：analysis/session_state.md + tools/resume_rev.ps1
- 新增 tsdk_pair3 增强采集工具；历史工具归档 csdk/tools/legacy/；
根目录抓帧残留删除，历史文档归档 analysis/history/
- csdk/README.md 完整使用文档；.gitignore/.gitattributes 补 LFS 规则
|
2026-08-13 23:16:12 +08:00 |
|