近日，第五届深度学习图像压缩挑战赛（以下将简称“CLIC 大赛”）比赛结果颁布，首次参赛的火山引擎视频云多媒体实验室夺得视频压缩赛道第一名。压缩技术对于图像、视频利用非常重要。在保障同样的品质前提下，如何将图像压缩到更小的体积便于互联网信息传输，火山引擎视频云团队一直冲破压缩技术“天花板”。
以后字节跳动高峰期每秒需解决近百万张图片，基于今日头条、抖音等亿级 DAU 的实际打磨，与国内当先的压缩技术，火山引擎视频云打造图像一站式解决方案 veImageX，笼罩上传、存储、解决、散发、展现、品质监控全链路，涵盖图像生产、图像生产、云平台三大利用场景。
图像生产
图像生产场景次要将业务产生的图像写入图像存储中，起源包含用户端的图像上传、在镜像站或三方云的存储（按需拉取或全量迁徙）、在火山引擎的独立存储桶、业务自主合成的图片等。
图像生产
图像生产环节提供了图片 URL 打包、图片实时处理链路、端数据上报等能力。
业务 URL 签发： 签发过程中会调用 veImageX 的签发服务，而后下发图片 URL 到业务客户端。通过签发的图片 URL，携带了有效期和签名信息，能够无效避免 URL 盗链、URL 篡改、域名盗用等。
客户端生产 ：业务图片加载 SDK，实现图片下载、解码、展现、拜访数据上报一系列操作。客户端上报的数据，经数据上报核心荡涤后，会存储到数据仓库，供查问、监测图片的拜访性能、错误率等指标应用。
网络散发 ：在图片下载过程中，一般来说会首先拜访 CDN。若 CDN 未缓存，则会触发回源，申请由源站接入层转发到图片静图服务。该服务次要负责拜访权限的校验、流量管制、图片资源下载以及动态图片的主体解决流程。申请处理过程中，对于须要利用图片算法、HEIF 静图 FPGA 编码的场景，图片静图服务会通过 RPC 申请 Lambda 计算平台，相应的能力已通过近程可调用函数的形式在平台上部署。对于 FPGA 不能反对的图片（分辨率过大或过小），会发送到 CPU 平台的 HEIF 静图编码服务做解决。对于动图转码解决的申请，图片静图服务会发送到动图服务做解决。因为动图的帧数有多有少，对于帧数多、分辨率高的大动图，当申请解决超过肯定工夫后，动图服务会将同步解决转为异步形式运行，并长期返回原图作为降级后果，待降级后果在 CDN 上的缓存生效后，相应的申请会再次回源，此时能够拿到异步解决后的图片。当图片静图服务实现图片申请的解决后，申请相应的数据会存入数据仓库，供数据分析、计费推量应用。
云平台
veImageX 控制台作为一站式云平台，为用户提供了租户治理、配置下发、用量查问、品质监控、算法与算子治理等性能。
控制台的申请通过网关发往 veImageX 后端服务。
平台治理 ，相干的 OpenAPI 撑持了平台侧配置管理、用量查问、品质监控等能力。波及到后两者的场景，须要查问数据仓库获取对应的数据。波及到域名的场景，须要依赖 veImageX 的域名治理服务，和接入与散发的各个组件交互。
算子仓库 ，图像算法开发人员借此能够不便地治理、公布、运维图片算法模型。云数据迁徙服务则负责了图片生产场景中数据迁徙工作的治理。创意魔方服务实现了多图合成的能力，业务能够通过创意魔方附加组件创立款式，而后动静替换文字、图片，批量生产图片，实用于海报制作、商品图片合成等场景。
离线调用 ，作为图片实时散发链路的补充，这里还提供了图片算法的离线调用，蕴含了所有图片算法的 OpenAPI。此外图片离线转码剖析平台能够应答批量图片的离线转码、画质剖析等场景。
veImageX 的技术演进历程
veImageX 这些能力的造成并非欲速不达，而是随同着字节跳动的业务倒退一路成长。
根底通用的图片散发能力
互联网时代开展业务离不开图片，在业务发展的晚期，图片散发就在思考之中。对于字节跳动来说，图片散发相干零碎的开发工作在公司正式成立之前就曾经开始了。
支流的图片传输计划都是基于 HTTP(S) 协定。因为图片的码率相比视频小很多，对于大多数场景，齐全能够在一个 HTTP(S) 申请中实现实时处理。而后在用户拜访侧接入 CDN，将本人的图片解决服务作为源站，这样能够缓存绝大部分的图片申请的响应。如此，一个根本的图片散发链路就算搭建实现了。
晚期的图片零碎次要解决业务的最根底的图片散发诉求，并在此之上做了肯定水平的形象，通过 HTTP 路由来辨别不同的散发场景。比方应用 /obj/<store_uri> 示意散发原图，应用 /large/<store_uri> 示意散发大分辨率档位的图片。
当业务场景变多后，个性化的图片展现诉求也随之而来，以 HTTP 路由辨别场景这种偏定制化的形式就日益臃肿了。此时，图片零碎利用通用做法，将图片解决参数做归类形象，比方裁剪、缩放、水印等。将图片参数的选择权交给业务，让业务在下发的图片 URL 中自行指定解决参数，达到个性化散发的目标。
在 URL 中间接拼接图片解决参数，能够提供很大的自由度。但业务应用图片更多的是基于场景，而不是参数。不同的图片散发场景，可能都应用了雷同的图片解决参数，但图片 URL 都长得一样。这时，业务不仅须要了解参数背地的含意，也无奈通过 URL 中的参数来辨别应用场景。另外，随着图片解决能力的变多、变简单，图片解决参数的设计也会成为一个问题。
为了解决这类问题，技术团队首先定义 filter，一个 filter 能够形象为一个图像处理模块，输出为 RGBA 像素矩阵和一些自定义参数，输入为 RGBA 像素矩阵。单个 filter 能够是简略的图像缩放，也能够是简单的图像算法（如超分）。接着将图片处理过程形象为一个 pipeline，顺次运行下载 -> 解码 -> 利用 filter A-> 利用 filter B-> 编码，并将最终的后果返回。有了这些概念，咱们能够定义模板：模板为一个配置文件，寄存在图片零碎服务端，模板外部封装了图片 filter（哪个 filter 什么参数）和编码参数。这样，业务在应用时不必关注外在细节，只须要在交互界面点选，即可创立属于本人的模板。为了晋升模板的可扩展性，模板还反对 filter 中的局部参数动态变化，下发时在 URL 中传入。例如反对在 URL 中动静指定缩放宽高、反对传入用户 ID 作为水印文本等。
随着模板的推出和业务线变多，一个严厉的事实呈现在眼前：业务接入时到哪里创立治理模板，到哪里治理图片资源和图片域名，如何买通客户端和服务端？这时，veImageX 作为一个残缺的产品状态应运而生。veImageX 以服务为最小粒度治理业务资源（域名、存储、模板等），通过附加组件的模式提供了诸多图片算法，具备了用量查问、品质监控、配置下发等端联动能力。
HEIF 高效压缩格局的推广
在具备根本的云图片能力后，随着业务体量的增长，veImageX 和业务逐渐关注如何升高业务的图片老本。在业务的图片相干老本中，CDN 带宽老本个别占据 80% 以上。因而在不影响下发图片品质的前提下，升高图片码率是无效升高 CDN 带宽老本的伎俩。
罕用的图片格式有 JPEG、GIF、WebP、HEIF。JPEG 和 GIF 从推出到当初历经 30 年，JPEG 主打静图，GIF 主感动图。后起之秀 WebP 于 2010 年由 Google 推出，基于 VP8（与 H.264 同代技术），同时反对动静图，同画质下，相比 JPEG 和 GIF 能够节约 70% 的码率。HEIF 格局基于 H265，由 MPEG 于 2015 年推出。
火山引擎视频云团队基于 H265 技术，以自研的 BVC1 编解码器为外围，推出了能够兼容 HEIF 格局的高效图片编解码。目前 HEIF 图片格式曾经在笼罩了超过 50% 的业务场景，应用 HEIF 压缩后的图片码率能够达到为同画质 WebP 的 55%-70%。
HEIF 格局是一把双刃剑，相比其余格局，在晋升压缩率的同时，也须要耗费更多 CPU 计算资源。为了升高 HEIF 格局的编码计算成本，veImageX 采纳了 FPGA 异构架构。利用后，整体老本约为 CPU 计划的 10%。但异构的一个难点在于：FPGA 计算集群如何部署。
这里有三种计划。
计划 A： 整体图片解决服务迁徙到 FPGA 集群；
计划 B： 将 HEIF 编码独立一个服务，并部署到 FPGA 集群；
计划 C： 整个服务划分 CPU 集群 + FPGA 集群，只将须要应用 FPGA HEIF 编码的申请发送到 FPGA 集群。
三种计划相比，计划 A 最简略，但最不经济，因为 FPGA 只会用于 HEIF 编码，不可用于其余计算。而对于不波及 HEIF 编码的申请，只耗费 CPU 资源。因为机器上 FPGA 和 CPU 配比是固定的，而 FPGA 吞吐量相比 CPU 高很多，如此会造成 CPU 资源绝对短缺。为了保障 CPU 负载在平安水位内，此时 FPGA 负载必然过低，导致资源的节约。另外，FPGA 资源有交付周期，而 CPU 资源绝对更容易获取，计划 A 也晋升整体运维老本。
计划 B 的劣势在于足够灵便，图片解决服务通过 RPC 的形式和 HEIF 编码服务通信，而不必关注 HEIF 编码的计算架构。对于 HEIF 编码服务，能够先通过 CPU 计算架构实现。待 FPGA 计划齐备后，只有扭转 RPC 的目标服务，即可实现无缝迁徙。另外独立的 HEIF 编码服务用到 CPU 的计算场景相比整个图片解决服务会少很多，这样 FPGA 的吞吐量不会受限于 CPU 资源的配比，能够施展到最大。当然，劣势在于，RPC 调用引入了额定的编解码过程，用于发送解决实现后待编码的图像，而且会引入大量的压缩噪声。另外，RPC 附带网络通信开销，链路时延变长，如此会对消 FPGA 的编码性能劣势。
计划 C 对图片解决服务及其上游有肯定要求，须要他们对流量有掌控能力，能将须要 FPGA HEIF 编码的申请按需发送到 FPGA 集群。另外计划对 FPGA 集群的 CPU 配比也有肯定的要求，此时计算瓶颈可能卡在 CPU 资源上，导致 FPGA 的吞吐量受限。计划的劣势在于可能施展 FPGA 的计算性能，升高源站图片解决提早。当然，从另外一层面来说，因为 CDN 的存在，当申请量达到肯定体量时，源站解决提早只会影响到图片的首刷体验，对端上整体图片加载时长的影响微不足道。
以后 veImageX 于计划 B 和计划 C，按场景的不同，都有采纳：对于静图场景，用到计划 B，因为 FPGA 对于图片的分辨率有限度范畴，CPU 和 FPGA 两套计算架构须要共存，而且静图申请量较大，独立服务保护能够使 CPU 不至于成为瓶颈，可能开掘 FPGA 的最大后劲；对于动图场景，因为动图帧数多，编码为两头格局再通过 RPC 发送代价较高，计划 C 更适合。
当然，图片格式的倒退很快，与 HEIF 压缩性能并驾齐驱的 AVIF 格局 veImageX 也已反对。基于新一代 H.266 的 BVC2 格局也曾经在路上
智能图像算法的利用
图片散发场景应用到的算法，按用处个别包含画质晋升、码率节俭、定向优化；定向优化次要是指盲水印、抠图、背景主动擦除、智能裁剪等。
画质晋升类的算法以超分和加强为主。超分可能提供 2-8 倍的分辨率晋升，以此晋升图片的展现成果，当然此时图片的码率也会相应变大。加强算法以优化图片内容为目标，按场景能够细分为低质加强、人像加强等。
- 低质加强算法可能对多种含糊、噪声、压缩伤害等低质类型的图像自适应解决。通过算法解决后，图片在清晰度、对比度、噪声和伪像打消等多方面都有较大的晋升。
<p align=center> 左图为原图，图片内噪声比拟显著，画质较差；右图为低质加强后后果，整体画质晋升显著 </p>
- 人像加强算法对图片中要害的人脸区域进行打消含糊、细节复原、重建清晰的人脸五官，进一步晋升人脸的品质。
<p align=center> 左图为原图，人像较为含糊；右图为人像加强后，人像整体更为清晰 </p>
码率节俭类算法的代表是集智瘦身。该算法能够在放弃原图画质的根底上，升高图片码率。依据业务的线上利用成果，整体码率节俭比例能够达到 10%-15%。
这些智能算法个别都须要依赖 GPU 计算资源来减速，由此引入了异构计算资源。在实践中，veImageX 依赖 Lambda 计算平台来治理 GPU 资源。开发人员将算法模型封装为 Lambda 平台上的函数，图片解决服务通过 RPC 来利用图片解决算法。如此，实现了图片解决服务和算法迭代间的解耦。为了晋升算法公布的效率，veImageX 建设了算子平台。算子平台作为 veImageX 和算法开发人员之间的桥梁，实现了算法模型的自动化上架、算法函数的可视化运维、算法版本的迭代治理等性能。
图片算法解决耗时个别是百毫秒的量级，再加上 RPC 中作为两头后果的图片文件的编解码和网络传输，整体解决耗时可能是一般图片申请的数倍。对于首次回源的申请，如果应用了图片算法，拜访的提早会不可控。为了晋升图片的首刷体验，veImageX 针对成果晋升类算法引入了降级的形式。首次拜访时，间接返回原图作为降级后果，并异步调用图片算法，再将算法解决后的图片长久化存储。
以上探讨的都是在图片散发的场景下，利用图片算法并实时返回。另外一种看似正当的思路是，在图片实现上传后，立刻触发图片算法，并将算法解决后的图片存下来。待到散发时，间接下发解决后的图片。这种做法有一些弊病：
首先生产侧利用图片算法是一个全量的过程，须要对所有已上传的图片做相应解决，随着工夫积攒，这部分图片数据占用的存储资源将逐渐收缩。只管外面很多图片可能不会再被拜访到，但依然要领取这部分存储开销。
另外，算法模型会有版本迭代，可能会修复一些问题、或有能力晋升，此时存量已解决过的图片就非常“难堪”：如果存量全副替换应用新算法，量级太大，未必能都解决完；如果不替换，新的算法失效慢，已有的问题图片也可能都无奈修复。
相比而言，在散发侧实时处理的劣势就体现进去了。散发时按需解决，算法模型更新后，只须要灰度替换为新的图片模板，存量和新增能够一并解决。
图像画质的把控
上文提到的算法，有些是晋升画质，有些是保障画质的前提降落码率。这外面都围绕了一个概念：画质。
veImageX 提供了 OpenAPI，能够对输出的图片做画质评估，从清晰度、噪声、美学等维度对图片做综合打分。但咱们发现用户更关注的是拜访的图片所在的微小汇合所出现的画质，而不是单张或若干张图片的画质分数。因而还须要一个大盘来展现用户拜访视角下，图片的整体画质状况。此外，当开启新的算法 AB 试验后，也能够依据画质指标来验证算法的成果，这样整体试验的后果更为相信。
在客户端间接对展现的图片做画质评估必定不是一个好方法，一方面画质评估会耗费较多计算资源，另一方面，客户端拜访到的图片大部分都是缓存在 CDN 上的，是一样的，这样反复计算很是浪费资源。因而服务端进行画质评估更正当，而画质评估的后果能够随图片内容一起缓存在 CDN。veImageX 在图片模板中新增了画质评估选项。若选项关上，则源站解决实现图片申请后，在返回图片数据之前退出一个步骤——画质评估。因为画质评估非必要步骤，评估超时或者失败都不该当影响图片数据的返回。
但天下没有收费的午餐，画质评估也波及到了近程算法调用，整体耗时约占原图片申请解决的 30%-50%，所以申请首次回源的提早必然会相应减少。解决这个问题有两个计划：
- 尽量在用户拜访频次高的场景应用。一个供参考的数据是：CDN 边缘节点命中率在 30% 的时候，如果引入画质评分，客户端申请图片均匀耗时上涨约 20%；而当 CDN 边缘命中率到 99% 的时候，整体均匀耗时上涨不到 2%。
- 源站做画质评估时退出抽样选项，默认 50%，意味着只对 50% 的申请做画质评估。因为客户端上报数据本来就是抽样进行的（个别至多百万分之一），所以源站的抽样对最终的后果影响微不足道。
在线画质评估计划次要用于试验中的画质指标剖析和用户视角的画质评分。一个问题随之而来，AB 试验个别历时较久，那么在利用新算法试验之前，如何可能评估算法对画质的影响，并相应调整算法参数呢？veImageX 通过离线画质评估平台来解决这个难题。具体做法是，拉取一批线上理论的用户的拜访图片，应用蕴含新算法的图片模板进行解决，处理过程中，对模板中每个 filter 的入口、进口图片做画质剖析，最终将所有剖析后果汇总成报表。这样依据报表中的两头画质后果，可能清晰地评估新算法的整体成果。业务也可能依据后果调换 filter 程序、批改算法参数。
散发链路的复用
图片的实时散发链路只是一个载体，稍加拓展，就能够利用到其余场景。例如，原文件为视频，如果下发静图，则对视频文件做实时截帧，从视频文件的固定工夫点抽取一帧，并复用图片模板解决；如果下动员图，则对视频文件做实时动静封面截取，从视频文件中截取一个短片段，转换为动静图片，而后复用图片模板解决。当然，受限于「实时」这个前提，原文件为小视频时，则成果最佳。
对于小视频的实时转码，也可复用图片的实时散发链路，然而须要一些定制革新。首先视频处理过程与图片天壤之别，须要独立的服务解决、独立的模板配置；其次图片处理结果码率个别不大，能够单次全量返回，然而视频得思考观看体验，须要能反对流式返回。当然，这种计划相比视频点播来说，只是胜在轻量接入、简略散发、疾速应用，对于视频点播波及到的诸多视频转码能力、播放端优化、中长视频反对都力所不能及。
总结
veImageX 图片零碎的演进贯通在字节跳动倒退的过程中，在不同期间以不同的模式解决图片散发的各类问题，最终“成长”成为图片中台。veImageX 从业务需要中走进去，回归到业务中去，紧密联系业务，提供了一套残缺的端到端图片解决方案。
福利 ：点击支付 veImageX 限时特惠资源包，获取字节跳动同款图像处理能力。