android: 照片改为竖屏方向 + 标注风格重做(去白底,准星+描边字)+ 录像 3x 编码
照片方向(推翻上一轮的"传感器朝向"决定,用户明确否掉): 把显示旋转(锁定 90° + 手动旋转)与手动翻转一起烘进 JPEG,竖屏持机拍出来就是 竖屏 720x960,顺序与实时渲染器一致(先镜像再旋转)。温度数据不跟着转——probes/ NUC/extremes 仍在原始传感器空间,旋转只存在于呈现层;BLOCK_RENDER 升到 version 2 多存 rotDeg,旧文件(8B v1 块)解析为 rot=0,符合它们确实是传感器朝向的事实。 分析页映射改为直接复用 PhotoSaver.sensorToPhoto(...,1,1),杜绝两处各算一套。 标注风格(参考 FLIR/Testo 的仪表做法): - 图标改为细线方形准星 + 四短臂(原为圆环+圆点):方框限定测量区域、四臂指明确切 像素、中心镂空不遮挡被测点。 - 文字白字+深色描边(先描边后填充),去掉白色底板——白底挡住被测画面且像消费级 App; 描边让文字在黑冷端和白色热端都读得清。 - 极值改用 MAX/MIN 大写 + 引线把读数连到自己的准星;颜色仍取白色(彩色标点在铁虹 橙黄区会糊掉,区分靠文字)。 标注尺寸统一:AnnotSpec 的 320 单位是图像长边,实时界面原用 viewport.width()(竖屏 时是短边)去除 320,使实时标点只有照片的 3/4 大——这正是用户早先"照片标点太大"的 由来。现四处统一 max(w,h)/320。 录像清晰度:编码尺寸改为传感器 x3(竖屏 720x960),码率随像素数放大;帧的翻转+旋转 用一个 Matrix 一次 drawBitmap 完成,标点经 sensorToPhoto 落在同一变换下(矩阵复合 结果与 sensorToPhoto 按坐标推导核对一致)。实测 tkhd 720x960 / avc1 / 96帧 0丢失。 分析页"每个标记出现两次":不是坐标错,而是标签避让与绘制顺序有关——拍摄按 probes→MAX→MIN、分析按 MAX→MIN→probes,避让把标签推到不同位置。改为同序后叠加 完全重合(真机裁剪对比确认)。 排查方法:验证"文件里标记位置是否正确"不靠肉眼看截图叠加,直接解析 MDT 算期望像素 再统计该处中性白色像素数——据此一次证伪"旋转没生效":rot=90 处 markerPixels= 204/219/296/719,rot=0 处全为 0。 103 项测试全绿(新增 mirror x rotation 往返、旋转角点、v1→v2 渲染块兼容)。
This commit is contained in:
@@ -489,6 +489,76 @@
|
||||
"未连接"分支显示,正常出图时用户看不到任何反馈)。
|
||||
- [x] 单测 66 → **76 项全绿**;debug + release(R8) 双构建通过;APK 已更新。
|
||||
|
||||
## 用户反馈修复 第二十三轮(2026-09-12,照片竖屏 / 标注风格重做 / 录像清晰度)
|
||||
|
||||
用户第五轮反馈(三点):竖屏拍照出来的照片不是竖屏;录像里的温度标点糊;
|
||||
温度标点不要白底,参考大牌热成像重做一套、要有工业感。
|
||||
|
||||
### 1) 照片改为按"用户看到的方向"保存(推翻上一轮的决定)
|
||||
|
||||
上一轮把照片定为**传感器朝向**(4:3 横),用户明确否掉了。现在把**显示旋转**
|
||||
(锁定 90° + 设置里的手动旋转)连同手动翻转一起烘进 JPEG:竖屏持机拍出来就是
|
||||
竖屏(720×960)。顺序与实时渲染器完全一致——**先镜像、再旋转**。
|
||||
|
||||
- 温度数据**不跟着转**:probes / NUC / extremes 仍留在原始传感器空间,旋转只存在于
|
||||
呈现层;`BLOCK_RENDER` 升级到 **version 2**,多存一个 `rotDeg`。旧文件(8 字节
|
||||
v1 块)解析为 rot=0,正好符合它们确实是传感器朝向的事实——不会被静默转错。
|
||||
- `sensorToPhoto` / `photoToSensor` 增加旋转参数(正向 (u,v)→(1-v,u),逆向对应),
|
||||
并有 16 组 mirror×rotation 的往返单测。
|
||||
- 分析页的映射改为**直接复用** `PhotoSaver.sensorToPhoto(..., 1, 1)`,让"分析显示的
|
||||
位置"和"烧进照片的位置"不可能各算一套。
|
||||
|
||||
### 2) 标注风格重做(去白底,工业感)
|
||||
|
||||
按 FLIR/Testo 那类仪表的做法重做(`AnnotSpec` + `MarkerPainter`):
|
||||
|
||||
- **图标**:细线方形准星 + 四根短臂(原来是不带臂的圆环+圆点)。方框限定测量区域、
|
||||
四臂指明确切像素、中间镂空不遮挡被测点。
|
||||
- **文字**:白字 + 深色描边(先描边后填充),**不再有白色底板**。描边是为了在黑冷的
|
||||
和白色的两端都读得清——白底会挡住被测画面,而且看着像消费级 App。
|
||||
- 极值标签改用 **MAX / MIN** 大写,并加一条**引线**把读数与自己的准星连起来。
|
||||
- 极值颜色与测点一样是白色:这是参考仪表的做法,彩色标点在铁虹的橙黄区会糊掉,
|
||||
区分靠 MAX/MIN 文字。
|
||||
|
||||
### 3) 标注尺寸统一(顺带修掉的不一致)
|
||||
|
||||
AnnotSpec 的 320 单位是**图像长边**。实时界面原来用 `viewport.width()`(竖屏时是短边)
|
||||
去除 320,导致实时标点只有照片标点的 3/4 大——正是用户早先"照片标点太大"的由来。
|
||||
现在实时/照片/录像/分析**统一用 `max(w,h)/320`**,同一画面里标点相对图像的尺寸完全一致。
|
||||
|
||||
### 4) 录像清晰度
|
||||
|
||||
原来按原生 320×240 编码,文字只有 9.5px、放大后必然糊。现在:
|
||||
|
||||
- 编码尺寸 = 传感器 × **3**(竖屏 720×960,横屏 960×720),码率随像素数自动放大
|
||||
(`w*h*10`,下限 2Mbps)。
|
||||
- 帧的翻转+旋转用**一个 Matrix** 在 reader 线程上一次 drawBitmap 完成;
|
||||
标点经 `sensorToPhoto` 落在同一变换下。矩阵与映射的一致性我按坐标推导核对过:
|
||||
矩阵复合结果 = `sensorToPhoto`(rot90 时 u'=1-v、v'=u),两者不会各转各的。
|
||||
- 真机实测:`tkhd 720 x 960`、avc1、96 帧 / 0 丢弃 / 7.3MB。
|
||||
|
||||
### 5) 分析页"每个标记出现两次"
|
||||
|
||||
照片里已经烧录了标记,分析页再叠一层,两层**标签位置不同**(准星位置是对的)。
|
||||
根因不是坐标错误,而是**标签避让与顺序有关**:拍摄时按 probes→MAX→MIN 的顺序绘制,
|
||||
分析页按 MAX→MIN→probes,碰撞避让把标签推到不同位置。已改为与分析页一致的顺序,
|
||||
叠加后完全重合(真机裁剪对比确认)。
|
||||
|
||||
**排查方法记录**:判断"文件里的标记位置对不对"不要靠肉眼看截图叠加,直接**解析 MDT**
|
||||
(`analysis` 里已有的块格式)算出每个标记的期望像素,再统计该处的中性白色像素数。
|
||||
本轮据此一次性证伪了"旋转没生效"的猜测:rot=90 处 markerPixels=204/219/296/719,
|
||||
rot=0 处全为 0。
|
||||
|
||||
**本轮真机验证(小米 22041211AC / Android 12 / MIUI)**:
|
||||
|
||||
- [x] 照片为 **720×960 竖屏**,方向与竖屏实时画面一致
|
||||
- [x] MDT 内 `flags=2 flipV=true rot=90`,四个标记在旋转后的期望位置均有标记像素
|
||||
- [x] 照片标注为新风格(准星+描边字、无白底),MAX/MIN 大写带引线,标签互不重叠
|
||||
- [x] 分析页叠加后与烧录标记**完全重合**(每个标记只有一套)
|
||||
- [x] 面板数值与照片一致(40.3 / 21.3 / 24.9,Pt1 25.0 / Pt2 23.2)
|
||||
- [x] 录像 720×960 竖屏、96 帧 0 丢弃、首帧日志确认极值标记烧入
|
||||
- [x] 103 项测试全绿
|
||||
|
||||
## 用户反馈修复 第二十二轮(2026-09-12,7×7 细节增强 + 标注统一 + 卡顿根因)
|
||||
|
||||
用户第四轮实机反馈(四点):移植 7×7 局部细节增强;分析界面标点没对齐;
|
||||
|
||||
Reference in New Issue
Block a user