瞧瞧我们对漫画图片都做了什么!?

动手点关注

0a36256d2036450367152ffee4181486.gif

干货不迷路

概述

漫画是一种以图片为主体的内容形式,我们在实现漫画业务需求时,不可避免地会和图片打交道。本文总结了番茄小说业务场景中两个和图片相关的技术需求,在此抛出遇到的问题与团队的解决思路,望能抛砖引玉。

一、漫画内容加密

1. 需求背景

漫画的内容是由一张张的图片构成,这些图片就是我们的资产,为了防止盗版商/灰黑产能轻易地获取这些资产,我们需要提供一个图片加密方案,以此来保证这些内容只能在我们允许的分发渠道上展示。

2. 内容加密的思考

加密过程,无非就是明文、加 / 解密算法、密文。在这种情况下,增加对内容的保护程度,本质上就是对密钥算法的迭代。但本次需求不同点在于,由于我们需要保护的不是某一个特定的文件,而是一大批文件,因此除了密钥算法本身的迭代外,我们还可以考虑从密钥的颗粒度着手。

3. 密钥的颗粒度

针对漫画章节的特性,我们考虑了三种颗粒度的密钥方案:

「所有内容统一一个密钥」

该方案的问题是,只要盗版商 / 灰黑产获取到一个密钥,即可解全网的图片内容。盗版商/灰黑产获取到该密钥的成本非常低,该方案做了等于没做。

「每个用户一个密钥」

每个用户一个密钥,意味着每个用户获取的内容是不同的,使得内容不能放在 CDN 上,需要由服务端 API 直接输出。但问题在于图片文件比较大,不适合直接放在服务端 API 的响应包里。且对于图片这种多媒体数据,更应该更多地利用 CDN 近用户端的好处。

「每个章节一个密钥」

由于是内容维度的密钥,还是可以将内容推至 CDN 来进行访问,也避免了“所有内容统一一个密钥”的问题。坏人可以获取到一个密钥,但比较难获取到所有内容的密钥。

从安全性的角度上看,我们认为,密钥颗粒度越小,越难被发现分发内容的规律,越难被破解。

3. 如何维护密钥

上文从安全角度分析,我们确定了要以每个漫画章节一个密钥的设计方向。然而,从维护成本看,如果我们直接为每个漫画章节都保存一个密钥,则需要引入额外的章节数量级(千万级~亿级)的密钥存储,维护成本相对比较高。

如何既能实现章节维度的密钥,又能降低维护成本呢?

我们想到了一种基于 “元密钥” 的实现方式,即:

  • 服务端只保存一个密钥,称之为“元密钥”,该密钥保存在密钥管理服务中;

  • 设计一个变换函数,该变换函数保证多次运算结果一致,输入参数为元密钥和章节 id,组合生成“章节密钥”;

“元密钥”方案解决了海量章节数量级的密钥维护成本问题,我们只需要维护一个“元密钥”和一个“变换函数”,即可源源不断的生成新的章节密钥。

4. 整体流程设计

如上,我们确定了我们加密方案的基础—— “元密钥”。于是基于 “元密钥”方案 ,我们所设计的整体流程如下所示,核心主要是生产与分发两步。

9f10f5a4fc57b11126b88000f496f5bf.png

「生产」

生产步骤主要由内容生产服务完成,其主要功能是将内容提供商或者是作者提供的多媒体源文件,转换成在客户端APP可读的文件形式,然后上传到云端或其他存储介质中。在生产过程中,需要生成不加密版本和加密版本,同时保存至对象存储服务中。加密版本的漫画图片使用 “变换函数” 组合元密钥和章节id生成章节密钥,来对该章节的漫画内容进行加密。不加密版本是为了防止极端情况下获取元密钥失败,此时可直接下发不加密版本,减少用户体验上的损失。

「分发」

分发步骤主要由内容分发服务完成,其主要功能是查询客户端请求的章节内容,打包下发给客户端 APP 进行展示。漫画的章节内容,同时包括了漫画图片的 URL 链接、图片加密状态以及章节密钥。 其中漫画图片的URL链接以及章节加密状态是从存储服务中获取的,而章节密钥则是在分发时利用 “变换函数” 来进行生成,所以生成时也需要获取元密钥,获取元密钥失败时,就会降级到图片不加密的逻辑,下发非加密图片。

最后,漫画章节内容在下发前,还需要对下发的响应包进行加密。客户端获取到章节内容时,需要首先对响应包进行解密,得到当前的图片加密状态、漫画图片 URL 链接以及章节密钥等信息;然后根据漫画图片链接,获取漫画图片文件;最后根据图片加密状态,判断是否需要对获取到的漫画图片文件进行解密,如需解密,则根据下发的章节密钥进行解密。

5. 解密失败感知

上述方案也存在一些局限,一个比较严重的问题在于如果密钥生成函数计算出错,会导致加/解密的密钥不匹配,进一步导致图片内容解密失败,这会使得图片无法正常显示,对于用户来说这是非常有损的体验。由于图片内容加密过程发生在内容生产服务,图片内容解密过程发生在客户端,内容分发服务本身无法感知到解密失败事件,不能前置降级处理,因此实现上必须在客户端上做好解密失败的监控,在解密失败时及时告警,推动后台排查处理。

二、漫画封面超分

1. 需求背景

相比于网文,漫画的书封更加精美,信息量也更多,因此在产品形态上,漫画也采用了大屏的展现形式。

948020532dfd16c318b40c5f41d224d3.png

然而,在漫画功能上线后,我们发现有部分漫画的原始书封比较模糊,影响体验,如下所示:

d50f249ba4c940b423486ecc254eaae9.png

为了提升这部分图片的画质,我们想到了寻求超分/画质增强组件搭建自动化处理流程,对该类图片做增强处理,得到高清图,提升整体观感。

2. 目标

  • 筛查低质图片

    • 大部分漫画的书封画质是比较好的,仅有少部分存在图片模糊的问题,但由于书本量级多,人工筛查的工作量大,因此期望能具备自动筛查的能力,不依赖人工筛选。

    • 使用 vqscore 对封面图片进行打分,通过设定阈值来定位出需要进一步做增强的低质图片。

  • 图片增强处理

    • 增强后的图片需要有明显的画质提升。

    • 图片加载有明显的用户感知,更小的图片意味着更小的带宽成本,加载得也更快,所以经过超分处理后的图片在文件大小上不能有太大的增长,需要具备下采样抗性。

3. 调研

  • 筛查低质图片的方法 - vqscore

    • 火山引擎视频云团队提供的一种画质评估指标,其背景是通过深度学习的方法对图像/视频得到符合人类主观的评价分数,分数越高代表画质越好。

  • 图片超分接入方法 - imageX

    • imageX是火山引擎视频云团队提供的一站式图片解决方案,可通过模板配置的方式实现对输入的图片进行图像处理。

  • 图片超分处理方案 - 多媒体实验室

    • imageX 本身提供了一种通用的超分能力可直接进行画质增强处理,但是经过尝试后发现处理后的图片仍然比较模糊,不符合预期,因此找到了多媒体实验室的同学进行定制化的超分能力处理方案的开发。

4. 设计思路

  • 图片超分处理方案开发 - by 多媒体实验室

    • 给出一批封面图片供算法同学进行算法离线验证。算法同学从以下维度进行离线评测:

    • 使用 vqscore 对封面图片进行打分,通过设定阈值来定位出需要进一步做增强的低质图片。

    • 使用超分模型对低质图片进行增强处理,验证增强效果是否符合预期。

    • 考虑到某些场景下会对图片做下采样处理,还需验证增强算法对下采样的抗性。

    • 业务方确认增强效果符合预期后,通过 ImageX 来调用增强模块。

  • 图片超分处理方案效果验证 - by 内容分发侧

    • 在漫画封面的分发场景下,通过实验的方式,验证图片超分处理的业务收益。

    • imageX 新增漫画场景定制化超分处理模板。

    • 对照组仍然保持线上处理,下发原图。实验组下发漫画书封图片时,配置请求超分模型用的图片模板。

    • 客户端请求图片时,由超分模型进行画质判断 & 超分处理,返回处理后的图片。

  • 图片超分处理方案正式接入 - by 内容生产侧

    • 接入超分处理后,会给图片加载带来额外的时延,因此考虑在内容生产服务上传书封图片时,直接进行“筛选低质图片->图片超分处理”的过程,减少客户端加载漫画图片的时延。

5. 技术实现

漫画封面超分处理方案

「方案预设」

  • 输入图片 --> 4 倍超分。验证超分对原图画质的提升。

  • 输入图片 --> 4 倍超分-->缩放至 240p(长边 240)。验证超分对压缩图片的画质提升。

  • 根据投稿图片 vqscore 大小,将其分为四组:低画质,中低画质,中高画质,高画质。分别统计各组画质提升效果,确定触发阈值。

「数据分析」

  • 给出的 1040 个漫画封面,原始分辨率以 630x840 居多。

  • 整体质量较好,少部分存在低质问题。

  • 低质原因怀疑是压缩后经上采样而引起的模糊、块效应和锯齿。

  • 输入图片 vqscore 低于 62 分而且图片长边小于 1080 时,开启 4 倍超分(v4)。

「验证方案」

对输入图片(ori)做离线增强处理,得到超分图片(SR2)。为了验证下采样抗性,进一步下采样至 240p,记为(SR2_240)。同时作为对照组,将输入图片 ori 下采样至 240p,记为 ori_240。

计算以上 4 个节点的 vqscore,从大图和小图两个维度予以验证:

  • 比较 ori 与 SR 2的分数大小来验证超分增强有效性。

  • 比较 oir_240 与 SR2_240 的分数大小来验证超分对下采样的抗性,从消费端的角度来审视超分增强的有效性。

「整体结论」

  • 低画质和中低画质占比约 17%,这一部分图片建议开启增强。

  • 低画质经增强处理后,大图 vqscore 提升约 21 分,小图 vqscore 提升约 9 分,主观画质明显提升。

  • 中低画质经增强处理后,大图 vqscore 提升约 15 分,小图 vqscore 提升约 6 分,主观画质明显提升。

  • 中高画质和高画质经增强处理后,大图和小图 vqscore 均有提升,主观画质提升不明显。

  • 输入图片 vqscore 低于 62 分而且图片长边小于 1080 时,开启 4 倍超分(v4)。

「前后对比」

74886d973c3cdbf16556af11069f6aa6.png

流程示意 (流程图只表述关键节点)

「测试阶段」

测试阶段,触发超分处理的时机放在客户端请求图片时。

4adbb4f752214e589f42ea50354c81a3.png

「正式接入」

正式接入时,触发超分处理的时机放在内容生产服务上传图片时。

d1723280db7da90668f0da01beb570aa.png

三、总结

本文总结了两个业务场景中遇到并已经解决的实际问题——图片加密和图片超分。图片加密基于我们的真实业务场景进行思考,提出了以章节维度进行加密的方案,同时设计了元密钥+函数概念避免了章节维度带来的海量密钥存储的问题;图片超分充分结合业务需求和火山引擎视频云在图片画质评估、图片处理和接入、超分定制化方案的一揽子能力,针对低、中低画质的图片进行增强处理,效果提升显著。由于篇幅所限,本文仅对解决思路进行了阐述,具体实现上有所省略,但仍希望能给整个行业一点启发,一同进步!

猜你喜欢

转载自blog.csdn.net/ByteDanceTech/article/details/129053412