图像和照片·社交图像调整器
偶数像素尺寸和色度子采样:为什么奇数尺寸会导致问题
· 背景
图像尺寸 图像编码 视频工作流程
JPEG 和大多数视频编码器使用 4:2:0 色度二次采样以半分辨率存储颜色,这就是为什么奇数像素尺寸会在某些管道中导致错误或边缘伪影的原因。这篇文章解释了这一机制以及为什么将尺寸微移一个像素有时是正确的选择。
奇数维故障属于特定下游编码器; ToolAcre 在此不重现
特定视频编码器可能会拒绝奇数宽度或高度,但 Social Image Resizer 本身接受任何适合其像素预算的正整数目标。它当前的预设恰好使用偶数的整数维度。此应用程序中的任何测试均未显示单像素故障或边缘伪影。
将编码器错误视为有关下游合约的证据,而不是图像的通用属性。捕获准确的消息、编解码器设置和尺寸。然后,如果下一个工具明确需要偶数对,则调整 ToolAcre 自定义输出。这种纠正将原因和补救措施保持在同一管道中。
亮度和色度概念是背景,不是此工具公开的控件
图像和视频编解码器可以与颜色信息分开表示亮度信息。人类视觉所容忍的空间色彩细节通常少于亮度细节,这激发了色度子采样设计。这一背景解释了为什么某些格式将相邻像素的颜色样本分组。
ToolAcre 不公开亮度平面、色度平面或采样控制。它将画布和 MIME 请求传递给浏览器编码器。生成的实现细节取决于该编码器,并且不能从质量滑块中得出。概念编解码器教育必须与产品声明分开。
ToolAcre 不承诺 4:2:0 对 JPEG、WebP 或视频进行编码
在 4:2:0 表示中,色度通常与二乘二的亮度区域相关,这使得甚至维度对于许多实现来说都很方便。精确的存储、填充和边界规则属于编解码器和编码器。对于此处提供的证据来说,诸如“所有 JPEG 和大多数视频都使用此”之类的口号过于宽泛。
render.js 及其测试都不会检查 JPEG 或 WebP 输出中的子采样标记。该应用程序还导出静态图像,而不是视频。如果必须知道子采样,请使用格式感知工具分析实际编码文件或查阅记录的下游编码器,而不是从维度推断它。
奇数尺寸失败的地方必须在实际下游管道中进行验证
奇数尺寸可能不受支持、填充或正常处理,具体取决于管道。该存储库不包含证明最后一行或最后一列模糊的测试,因此本文省略了所声称的症状。在更改尺寸之前,应使用确切的文件和使用者重现失败的切换。
ToolAcre 的输出表报告宽度和高度,使切换检查变得简单。如果接收视频工具要求两个值都能被 2 整除,请将该要求添加到生产清单中。当每个社会形象的目的地没有这样的限制时,不要默默地推动它。
纵横比与偶数像素 — 为什么数学上精确的比率有时必须屈服于偶数尺寸
当自定义尺寸被舍入时,长宽比和整除性可能会发生竞争。 sizeFromRatio 在固定最长边后将较短边舍入。这个结果可能很奇怪。如果下游合约需要偶数对,请选择偶数最长边并计算附近的偶数对应项,同时测量所得的比率差异。
不要通过仅更改元数据来扩展现有输出。以所选尺寸创建新画布并检查框架。在一项工作中,一个像素的调整在视觉上可能可以忽略不计,但接受应该来自实际的下游需求和预览,而不是普遍的断言。
工作示例:计算偶数 9:16 对,而无需发明编码器工件
对于 9:16, 1080×1920 已经是精确偶数对,并且是当前通用全屏工具预设。一对定制的半尺寸 540×960 也可以准确地保留比例并保持均匀。这两个例子都来自算术,而不是来自发明的编码器质量规则。
如果请求的最长边产生奇数圆角对应项,则通过宽度除以高度来比较相邻的偶数值,并选择满足记录的消费者要求的对。导出它,验证结果表并运行接收工具。交接的成功是重要的证据。
这不包括什么 - 4:4:4 和 4:2:2 工作流程和专业视频色彩管道
专业 4:4:4、4:2:2 和视频颜色管道位于此静态图像裁剪器之外。编解码器配置文件、像素格式和硬件编码器限制也是如此。浏览器编码器接受 JPEG、PNG 或 WebP 请求;它不会公开承诺这些生产格式所需的开关。
使用视频工具控制视频采样和颜色。使用 Social Image Resizer 准备具有已知尺寸和构图的静止框架。维持该边界可以防止有用的偶维检查成为对编码色度结构的错误保证。
要点:免费时更喜欢偶数 — Social Image Resizer 会在浏览器中按照比例进行裁剪并调整大小;在将文件交给视频工具之前检查最终尺寸
当记录的下游工作流程有益并且调整不花费任何成本时,更喜欢甚至尺寸,但不要将偏好提升为图像法则。接收编码器拥有其约束。 ToolAcre 的工作是提供可检查的整数输出维度和可预测的框架。
在切换之前检查文件,保持预期的比例并运行真实的消费者。如果失败,请使用错误和文档选择另一对。这种证据优先的方法比在不检查编码文件的情况下将每个奇怪大小的工件归因于 4:2:0 更可靠。