# 长截图放大后字还是糊的怎么办 # 智绘鸿蒙·如 7 而至#

## 前言

群里转发的长截图，第一眼看是清楚的，双指放大以后字是糊的。

我的第一反应是：信息被压缩掉了。既然是被压缩掉的，那就是可恢复性问题，端侧超分（`imageSuperResolution`）正好干这个。于是准备写一段"先超分再放大"的救图逻辑。

这段代码写完之前，我先做了一件事——给"糊"找个客观判据。结果被打脸了，而且打得很干净。

这篇是排障手记，按当时的顺序记：现象、假设、造现场、跑数据、被推翻、修正结论。中间有一次判据本身出问题，也一并写进来，因为那部分对以后排查同类问题是省时间的地方。

## 假设

一条转发链路大概是这样：原图 → 降采样 → 高压缩 JPEG → 对端解码 → 显示时再放大。

按这个模型，"糊"的原因是高频细节在降采样时被丢掉了，放大只是把糊放大，所以超分应该能重建出笔画。

要验证它，得能回答一个问题：**这张图里的字，机器还认得出来吗？**

人眼说"糊"不作数，得让机器打分。

## 造现场：一张已知答案的糊图

用脚本合成一张 1080×1920 的聊天截图，12 条已知文案（每条 10~11 字，字号 34px），标准答案我自己知道。然后模拟二次传播：缩到 432×768、JPEG 质量 38，成品 18KB。

判据用同一套 Core Vision Kit 里的通用文字识别：把图喂给 OCR，看返回文本里能完整找回 12 条中的几条（子串精确匹配）。

四条路径：

| 路径 | 处理 | 送进 OCR 的尺寸 |
| --- | --- | --- |
| A | 原始截图 | 1080×1920 |
| B | 转发后的糊图，不动 | 432×768 |
| C | 糊图解码时直接拉大 4× | 1728×3072 |
| D | 糊图过端侧超分 4× | 1728×3072 |

## 结果：四条路径全跑一遍

MatePad Pro（HarmonyOS 7 / API 26）实测：

| 路径 | 尺寸 | OCR 字符数 | 命中 | 识别耗时 | 额外成本 |
| --- | --- | --- | --- | --- | --- |
| A 原始截图 | 1080×1920 | 132 | 11/12 | 1356ms | — |
| B 糊图原尺寸 | 432×768 | 132 | **12/12** | 1109ms | — |
| C 双线性拉大 4× | 1728×3072 | 132 | 11/12 | 1209ms | 无 |
| D 端侧超分 4× | 1728×3072 | 131 | 11/12 | 1044ms | **超分 3574ms** |

三个结论，全和预期相反：

1. **糊图按原尺寸喂进去，成绩最好**，12 条全中，比原始截图还多一条。
2. 放大没有帮忙。双线性放大后掉到 11/12。
3. 超分也没有帮忙。同样是 11/12，还多花 3.6 秒。

也就是说，"糊"是真的糊，但**丢的不是信息，是观感**。

## 为什么会这样：人眼和机器的分辨率不是一回事

算一下字高就明白了。原图字号 34px，缩到 432 宽是 0.4 倍，落到 13.6px。

13~14px 的汉字，对端侧 OCR 来说已经够认了——它看的是结构，不是锐度。但对人眼，在 1840×2800 的平板上放大看，13.6px 的字就是糊的，因为显示层把这几个像素又插值放大了一遍。

所以"看着糊"和"读不出来"之间隔着一整个数量级。**人眼要 24px 以上才觉得舒服，机器 14px 就够用。** 我们平时想救的，其实是那 10 个像素的观感差距，而机器的读取结果根本不在这个区间里。

## 打脸之后，还有一层：我的判据也不干净

三条 11/12 的路径，掉的到底是不是同一条？把 OCR 原文前 24 字打出来看：

```
A 原始截图    项目群 明天九点站会改到会议室b 需求文档我放共…
B 糊图原尺寸  项目群 明天九点站会改到会议室B 需求文档我放共…
C 拉大 4x     项目群 明天九点站会改到会议室b 需求文档我放共…
D 端侧超分    项目群 明天九点站会改到会议室B 需求文档我放共…
```

A 和 C 少的那一条是同一个：**"会议室B" 被认成了小写 "b"**。而原始清晰截图也认错了——这个字母的错跟压缩无关，是 OCR 对单个大写拉丁字母的偏好。

这暴露了我判据里的一个问题：**子串精确匹配是大小写敏感的**。如果做大小写归一化，A 和 C 大概率也会变成 12/12，那结论会更硬：四条路径对机器几乎完全等价。这一步我这次没重跑，留给下一次。

顺带一条：如果生产代码里真的用"识别出的文本"去做精确匹配（比如按单号查截图），大小写、`O/0`、`B/8`、`1/l` 这几对是必须先归一化的，否则你的搜索会稳定地漏掉某一类图。这类漏检最难查，因为它不是偶发的——同一张图每次都会错在同一个字符上，看起来像 bug，其实是判据写错了。

## 那超分到底什么时候该用

这次实验否定的不是超分，是"用超分去救机器读图"这条路。

该用的场景是**给人看**：老照片、翻拍的图纸、要放大的商品主图。这些场景里"观感"就是产品本身，多花 3 秒换一眼能看清，值得。

不该用的场景是**给机器读**：OCR、文搜图、人脸。这些场景先把原尺寸图喂进去测一轮，拿到分数，再决定要不要加预处理。我们这次要是没测，就会带着一个 3.6 秒的延迟上线，而收益是零。

## 真机数据

| 项目 | 实测值 |
| --- | --- |
| 合成原图 | 1080×1920，205KB，12 条文案 |
| 模拟转发图 | 432×768，18KB（缩放 0.4 + JPEG q38） |
| 端侧超分 | 432×768 → 1728×3072，3574ms |
| OCR 单张耗时 | 1044 ~ 1356ms |
| 命中（满分 12） | 原图 11 · 糊图 12 · 双线性 11 · 超分 11 |

![四条路径的完整结果](assets/01-paths.png)

![OCR 原文前 24 字：A 和 C 把"会议室B"认成了小写 b](assets/02-tail.png)

## 总结

这个排查流程可以复用到任何"图看不清"的需求上：先定义一个机器能打分的判据，再决定要不要做图像预处理。

顺序反过来的话，很容易做出一个"看起来更清楚了、但没人因此受益"的功能——多花 3.6 秒，掉一条命中。

> 💡 **一句话**：图糊不糊，先问 OCR 再问眼睛——给机器读的图，直接按原尺寸喂进去测一轮，多半不需要超分。

## 参考文献

1. 图像超分（开发指南）：https://developer.huawei.com/consumer/cn/doc/harmonyos-guides/core-vision-image-super-resolution
2. imageSuperResolution API 参考：https://developer.huawei.com/consumer/cn/doc/harmonyos-references/core-vision-image-super-resolution-api
3. 通用文字识别（开发指南）：https://developer.huawei.com/consumer/cn/doc/harmonyos-guides/core-vision-text-recognition
4. textRecognition API 参考：https://developer.huawei.com/consumer/cn/doc/harmonyos-references/core-vision-text-recognition-api