智绘鸿蒙 · 如 7 而至端侧 AI 能力实战手记

后排拍的PPT,超分没救回来

智绘鸿蒙·如 7 而至

前言

这个功能立项时叫"板书救星":学生在后排拍 PPT,回家看不清,App 用端侧超分把字放大变清晰。需求来自一次用户访谈,三个人里有两个说"看不清老师放的公式"。

技术方案看起来是现成的:Core Vision Kit 的 imageSuperResolution 固定 4 倍放大,输入一张,输出一张 4 倍大的,字自然就清楚了。

我把对照实验跑完,四组数据的结论是:**一行都没多读出来,其中一组还读得更差了。**于是这个功能被砍掉。这篇讲砍它的过程,以及过程中发现的三件比"能不能做"更有用的事。

实验设计

关键是要让"字高"这个变量真实可控。第一版我图省事,把一张大字图整体缩到四分之一再放回原尺寸——这样文件名义上字高 26px,实际笔画早就被插值抹平了。**测出来四组全是 0 命中,差点让我以为超分完全没用。**那是脚本造假,不是模型不行。

重做后的生成方式:直接按目标字号绘制,再用像素包围盒量出实际字高,只保留轻微模糊 + JPEG 质量 62(模拟手机拍投影幕)。

样本 标称字高 实测字高 成品
slide_h12 12px 13px 800×500,16KB
slide_h16 16px 17px 800×500,20KB
slide_h20 20px 20px 800×500,24KB
slide_h26 26px 26px 800×500,31KB

判据:把每张图送进端侧文字识别,看 7 行板书里能整行一字不差找回几行;然后同图过一遍超分(4 倍,输出 3200×2000),再识别一次。同一张图、同一个引擎、唯一变量是超分。

结果

MatePad Pro(HarmonyOS 7 / API 26):

样本 超分前 超分后 超分耗时 输出
字高 13px 3/7 3/7 3476ms 3200×2000
字高 17px 4/7 3/7 3366ms 3200×2000
字高 20px 4/7 4/7 3364ms 3200×2000
字高 26px 4/7 4/7 3352ms 3200×2000

四组里三组持平、一组倒退,没有任何一组变好。平均代价是每张多花 3.4 秒。

这就是砍功能的直接依据:如果连"机器能不能多读出内容"这个最客观的指标都是零收益,我们没法说服自己那 3.4 秒值得。

三件比结论更有用的事

一、判据本身在骗人

四组都卡在 4/7,看起来像"识别率只有 57%"。实际上丢的三行是:

基频 f0 = 1/T,谐波为 n 倍基频
例:方波 = sin(x) + sin(3x)/3 + sin(5x)/5
作业:习题 3.2、3.5、3.9

全是带英文、数字和符号的行。"整行一字不差"这个判据对空格、全半角、= 前后有没有空格极其敏感——它很可能把每个字都认对了,只是在 sin(3x)/3 中间多打了一个空格。

所以 4/7 严重低估了真实可读性。**衡量 OCR 要用字符级编辑距离,整行匹配只能当辅助。**这个教训我在别的场景也踩过一次,两次都是差点因为选错指标砍掉一个其实能用的功能。

不过对本次结论没有影响:因为比较的是"超分前 vs 超分后",判据的偏差在两组之间是同向的,抵消掉了。

二、超分的输入面积预算必须显式管

第一轮我用 1600×1000 的板书图直接调超分,返回的是:

超分失败(200):Run timed out, please try again later.

降到 800×500 才跑通,耗时 3.35~3.48 秒。

文档给的硬约束是"输入长边不超过 2048",但这条只是能被接受的下限,不是能算完的保证。1600×1000 长边 1600,远小于 2048,照样超时。所以工程上真正要写死的是输入像素总量,而不是长边。我的处理是:送超分前先把长边压到 1024 以内,并且给超分调用挂一个可取消的超时,超时就退回"直接放大显示",不要让用户对着转圈。

顺带一句:Run timed out 这种错误码是可重试的,但重试只会再等 3 秒。别写自动重试。

三、"给人看"这件事我没能证明,也没法证伪

砍功能的会上,被问得最多的一句是:"学生是用眼睛看的,又不是用 OCR 看的,你拿 OCR 当判据公平吗?"

公平地说,不公平。这次实验只测了机器可读性,没有测主观清晰度。超分把字高从 26px 抬到 104px,笔画边缘是不是更锐、看着是不是更舒服,我没有量化手段——端侧拿不到好的感知质量指标,双盲打分又超出了一个 demo 的范围。

但产品决策不能因为"没测"就往下做。当时的判断是:在唯一可测的指标上收益为零、成本 3.4 秒,那就先不做。如果哪天有用户明确说"我就是想放大看清楚",再拿主观实验来翻案。

那这个需求怎么落地

放弃超分之后,功能改成了三条更便宜的路:

  1. 拍的时候提醒。 检测到画面里有大面积高亮矩形(投影幕)且文字区域偏小,直接提示"走近两步再拍"。零成本,效果比事后超分好得多——因为真正丢的高频,谁都补不回来。
  2. OCR 出文本,而不是优化图片。 用户要的是"看清内容",不是"看清像素"。把板书识别成文字存下来,比给他一张更清楚的图更解决问题。
  3. 多拍几张。 连拍三张做简单合成,比任何单图超分都稳。这条我们没做,属于工程量的问题。

真机数据

项目 实测值
设备 MatePad Pro(HarmonyOS 7 / API 26,序列号略)
样本 800×500,实测字高 13 / 17 / 20 / 26 像素
超分倍率 4 倍,输出 3200×2000
超分耗时 3352 ~ 3476ms
超分前后可读行 3→3、4→3、4→4、4→4
1600×1000 输入 失败,错误码 200,Run timed out
单次 OCR 约 0.85 秒(由整轮 5.0s 减去超分 3.4s 再除以 2 推算,未单独计时)

四组字高的超分前后对照

结果区放大:三组持平、一组倒退

总结

这篇能直接用的结论有两条:给端侧超分设一个输入像素预算,别信"长边 2048 以内"就能跑完;以及评估图像增强效果时,先确认你的判据测的是你想测的东西。

至于超分本身,它适合"给人看"且输入不大的场景——老照片、图纸、商品图放大。板书照片不在里面,因为板书的信息量本来就在那个尺寸里丢光了,放大只是把模糊放大。

💡 一句话:四组字高、超分前后各识别一遍,一行都没多读出来,还有一组读得更差——所以这个功能我们砍了,砍它的不是主观感受,是那个 0。

参考文献

  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. Core Vision Kit 错误码:https://developer.huawei.com/consumer/cn/doc/harmonyos-references/errorcode-core-vision