

截图工具的卖点里,"异形截图"听起来只是"好玩"——自由画一个圆形或多边形,比矩形灵活。
但它背后藏着一个硬约束,而且这个约束顺带解释了另一个常见疑问:为什么截图存成 JPG 之后,文字会发虚。
先想清楚这张图长什么样。
矩形截图很简单:就是一格一格的像素,行列整齐,边界天然由宽高决定。
任意形状就不一样了:形状之外的区域不属于这张图。 它不是"黑"、也不是"白",而是"不存在"。
要表达"不存在",就需要一个额外的通道——每个像素除了颜色,还要有一个"这一格是否可见"的数值。
于是结论很直接:
任意形状的截图,必须用支持透明度信息的格式来存。
而不支持透明通道的格式,根本存不了这种图——它只能把形状外的区域填成某个颜色,于是"异形"就退化成了"一张带色块的矩形"。
这就是第一层约束:不是"哪种格式画质好",而是"哪种格式能表示"。 表示不出来的东西,画质无从谈起——这也是 截图工具 在保存环节唯一绕不过去的一层。
把形状这件事放下,再来看内容本身。
屏幕截图这类图像,有一个很鲜明的统计特征:
翻译成压缩算法关心的话:"可预测性"非常高——相邻像素大概率一样,或者变化很规律。
而无损压缩正好吃这类内容:它找重复、找规律、把重复的部分用更短的表示法记下来。
所以对截图来说,无损压缩不但没有损失,体积本身也不会失控——因为可压的东西太多了。
现在看另一边。
有损压缩的思路完全不同:它不追求"一模一样",而是把图像切成固定大小的块,每块用少数几个"频率分量"去近似。
这个模型对照片很合适——照片本来就是连续变化的,丢掉一些细节看不出来。
但对截图就不合适了,原因在于"锐利的边界":
在一个小块内,如果左边是纯色背景、右边是纯黑文字,块内的变化是"突变的"。
用少数几个连续分量去近似一个突变,必然在边界两侧产生波纹——它想平滑地过渡过去,于是边缘周围出现了本不存在的花纹。
这就是文字发虚的来源。 它通常表现为笔画边缘的"蚊子噪点"或淡淡的重影。
注意这一点:这不是"画质参数设低了"。
把质量拉到最高,只是让这些波纹变淡,不会让它们消失——因为问题出在"用连续的方式去描述突变"这件事本身,不在参数上。
还有一层相关的影响:有损压缩常常会对色彩信息做"降采样"(因为人眼对亮度更敏感)。于是彩色文字的边缘最容易先掉色——出现彩边或颜色发脏。
把顺序倒过来想,判断标准就清楚了。
照片的特征恰好相反:连续渐变多、细节噪声多、颜色数量大。
"可预测性"很低 → 无损压缩找不到多少重复 → 压不动,体积暴涨。
所以:
判断依据可以压成一句话:
这份内容里,有没有大块"可以预测"的区域?
有(界面、文字、线稿)→ 无损;没有(照片)→ 有损。
最后一行要特别说一句:
格式转换是单向的。 一张已经存成有损格式的截图,再转回无损格式,波纹不会消失——它已经被写成像素了,无损只是"忠实地保存这些波纹"。
这一点经常被误解为"转一下格式就能救回来"。 救不回来:有损压缩丢掉的不是"格式信息",而是图像内容本身。
这一条容易误判:觉得文件大,就去换格式,换完发现没小多少。
因为无损不等于小,它只是"没有额外损失"。
文件大小首先取决于像素总量:
这些情况下,无损压缩已经尽力了——它的压缩比是有限的,因为它承诺"一个像素都不改"。
所以遇到"太大",先看两件事:像素量有多大,以及内容是不是真的需要无损。 顺序反了,就会在格式之间反复试,而体积没变化。
关于 截图工具 的输出格式,记住四条:
这里可以带走的经验是关于"选编码方式"的:先看数据本身的特性,再看表示能力,最后才比效率。
具体到三个问题:这份数据里有没有大块可预测的区域(决定该用无损还是有损)?需不需要表示"不存在"这类额外信息(决定格式是否够用)?可接受的损失是多少、以后还要不要再改(决定要不要留无损原件)?
按这个顺序判断,就不会陷入"试遍所有格式,体积和画质都没变化"的循环——因为决定权不在格式的新旧上,而在数据的样子和你对它的要求上。
https://www.ijinshan.com/functions/screenshot.html?channel=4108
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。