Command Palette

Search for a command to run...

两张照片并排是一个缩放问题

两张照片并排是一个缩放问题

T
Toolz Team
|Oct 21, 2026|18 最小读数
Google 上的首选 Toolz.dev

图像转换器集合的一部分

Merge Images

Combine several images into one: side by side, stacked, or in a grid. Sizes are matched on the axis that has to line up, and nothing is uploaded.

用Merge Images

一位朋友给我发了一张电话照片和一张截图,并在一张图片中要求他们提供列表。 我把它们都放进了自己大小的画布中,得到了没人接受的东西:一张 4032 x 3024 的照片,旁边有一张窄 1170 x 2532 的截图,截图下方的空白带,整个东西有 5202 像素宽。 图片很好。 安排是问题所在,而且每次都是同样的问题,因为这两个文件几乎从不共享一个维度。 决定哪个轴必须排列是整个工作,其他一切都由此而来。

TL;博士: 合并图像是一种缩放决定,它是绘图之前的决定。 并排将每张图片与最高的高度相匹配,将匹配到最宽的宽度,并与两者匹配,这就是为什么网格也必须在裁剪和留出空间之间进行选择的原因。 在 1170x2532 屏幕截图旁边的 4032x3024 照片上测量:并排制作 5429x3024 画布,截图放大到 1397x3024,堆叠产生 4032x11750 画布,截图放大 3.4 倍,覆盖模式中的两个单元格网格保持 70.2%。 选择要保留的轴的模式。 那个 图片合并 在浏览器选项卡中绘制所有内容,因此没有上传任何内容。

为什么合并的图像看起来不对?

因为输入是不同的形状,大多数工具以它们到达的任何大小绘制它们。

一张手机照片是 4032 x 3024 的风景。 2532 的手机截图是 1170。 扫描是扫描仪决定的任何内容。 将其中任何两个以原生大小连续放置,其中一个位于另一个高处,死角填充了较高尺寸的任何剩余空间。 这读作是一个错误而不是布局,即使对于那些无法告诉你原因的人来说也是如此。

修复是正常化的,唯一的问题是在哪个轴上。 一排,顶部和底部是眼睛所遵循的,因此高度必须匹配,每张图片采用其自己的宽高比的任何宽度。 在一列中,左右边缘是直线,因此宽度匹配。 网格有两个边都要固定,所以它必须同时匹配,这就是必须给予的模式。

这就是整个设计。 下面的一切都是由它产生的。

并排对高个截图有什么作用?

它放大它,有时比你想要的更多。

这是上面对的测量结果,取自布局代码而不是估计:

模式 帆布 照片画在 截图在
同 5429 x 3024 4032 x 3024 1397 x 3024
堆叠 4032 x 11750 4032 x 3024 4032 x 8726

并排匹配到 3024,两个高度中的较高,因此截图从 2532 到 3024 像素高。 那是 19% 的放大,如果您查找它,在文本截图上是可见的,如果您不查看,则是不可见的。

堆叠是戏剧性的一种。 与更宽的图像匹配的屏幕截图从 1170 到 4032 像素宽,3.4 倍,画布的高度为 11,750 像素。 截图现在是一个很长的图像中的主要对象,其中的每个字母都缩放了三倍以上,没有任何重新采样的清晰度。

教训不是一种模式更好。 是模式决定哪张图片放大,所以选择一张你的图像已经一致的轴匹配的轴。 横向的两张手机照片共享一个高度,并排进行,完全没有缩放。 同一部手机的两个截图共享宽度和堆叠完美。

什么时候应该堆叠而不是并排?

当内容向下读取时,或者当图片已经具有相同的宽度时。

堆叠适合一个序列:结帐流程的三个屏幕截图,一个在后面属于的前后,一个部分捕获的对话。 每当输入来自同一设备的相同方向时,它也是正确的,因为这样宽度就已经匹配并且没有任何缩放。

并排是正确的比较,眼睛应该移动而不是向下移动,对于任何将在帖子中看到的内容,因为 4032 x 11,750 图像是滚动的而不是看到的。

也有一个实际的理由更喜欢这排。 大多数接受一张图像的地方都以固定的宽度显示它,因此一个非常高的合并会缩小到一个条子。 一排三张同高度的照片在该宽度上以三列永远不会读的方式保持可读性。

网格必须决定条带没有什么?

怎么处理一张不是细胞形状的图片,这是一个条带永远不必问的问题,因为它只固定一个轴。

网格引脚两者。 每个单元格大小相同,4:3 的照片不适合 9:19.5 截图的单元格。 只有两个诚实的答案,该工具要求您在它们之间进行选择:

  • 包藏 适合整个单元格并在其周围留出空间。 没有任何东西丢失,网格看起来有点破烂,因为每张图像都位于自己的背景补丁中。
  • 盖 通过从图片中取出一个中心裁剪来完全填充细胞。 网格看起来很平,图片的边缘不见了。

一般来说,两者都不是正确的。 包含的是屏幕截图、文档、图表和边缘携带信息的任何内容。 封面适合脸部、风景和纹理,其中以中心为中心的作物是一个人会做的事情。

这里的默认值是cover,因为构建网格最常见的原因是它应该作为一个对象读取。

封面丢掉了多少图片?

当输入是不同的形状时,比人们预期的要多,而在它们匹配时什么也没有。

单元格大小是输入的平均值,因此两个截然不同的图片产生了一个不适合的单元格。 对于照片和屏幕截图对,在两个单元格中,布局代码准确报告绘制的内容:

影 本土 绘制的源区域 像素保留
照片 4032 x 3024 2831 x 3024 70.2%
截图 1170 x 2532 1170 x 1250 49.4%

截图的一半消失了。 不压缩,不缩放:被剪掉,顶部和底部,因为被迫进入几乎方形的高的窄图像必须失去其末端。 如果该屏幕截图是收据,则总数不再出现在图片中。

对来自同一相机的 12 张照片进行相同的操作,因为每个输入都已经具有单元格的形状。 当输入一致时,覆盖物很便宜,而当它们不一致时,该工具无法判断您处于哪种情况。 切换到包含您的图片形状不同的那一刻,边缘很重要。

一个网格应该有多少列?

足以让结果比高高更宽,这对大多数计数意味着平方根向下舍入。

行从列和计数开始,算术是无情的。 四列中的十二幅图像是三行。 三列中的七张图像是三行,末端有两个空单元格,布局将其作为背景保留,而不是拉伸最后一张图片来填充它们。

图像 柱 结果
4锛屽湪娴欐睙鏉 2 2 x 2,无间隙
6 3 2 x 3,无间隙
7 3 3行,两个单元格空
9 3 3 x 3,无间隙
12绔 涔诲芥澶澧 4锛屽湪娴欐睙鏉 3 x 4,无间隙

一个干净利落的因素值得追求。 如果你有七张照片,而空白的角落困扰着你,诚实的修复是丢掉一张,添加一张,或者接受它,因为七个相等的单元格的排列不是矩形。

为什么会有差距设置,应该是什么?

因为触摸图像读作一张图片,有时这是错误的。

零间隙适合全景图,前后的间隙应该看起来像一帧,对于接缝是重点的任何东西。 由于这个原因,这里是默认值。

当图片是一个文件中恰好存在的东西时,差距是正确的:三个产品照片、一组截图、一张拼贴画。 在 8 到 24 像素之间的某个地方可以完成几千像素的图像,滑块的工作量会达到 80 以进行更大的工作。 间隙在外部以及之间应用,因此结果具有边界而不是图片从边缘流出。

在选择 PNG 进行间隙合并之前要知道的一件事:间隙充满了白色,而不是保持透明。 画布在绘制任何东西之前都被绘成白色,因为 JPEG 没有 Alpha 通道,未绘制的间隙导出为黑色。 因此,此工具的 PNG 具有白色的排水沟而不是透明的,这很重要,如果您打算将结果放置在彩色背景上,这很重要。

合并的图像有多大?

比输入大,在堆叠的情况下要大得多,因为没有任何东西被压缩掉。

画布尺寸可从模式中预测。 并排,宽度是缩放宽度的总和,高度是最高输入。 堆叠,宽度是最宽的输入,高度是总和。 网格是列的列,加上间隙。

四列网格中的 12 张手机照片为 16,208 x 9,136 像素,即 148 兆像素。 这就是下一节的开始。

为什么输出会停止在 8,000 像素?

因为超过一定大小的浏览器画布停止工作,它没有这么说。

限制不是规范。 MDN 说得很清楚:大多数浏览器超过 10,000 x 10,000 像素,iOS 设备历来限制为 4,096 x 4,096,并且超过了最大尺寸或区域“渲染画布无法使用”,并且绘图命令静默失败。 捕获没有例外。 你得到一张空白的图像,或者什么都没有。 每浏览器数据收集在 画布大小的测试结果,这是在假设一个数字之前值得检查的参考。

因此,布局被缩小以适合 8,000 像素的长边,而不是允许失败。 对于这十二张照片网格,比例因子为 0.494,将 16,208 乘 9,136 降至 8,000 x 4,509,即 36 兆像素。 每张照片的落地约为 1,976 x 1,483,而不是 4,032 x 3,024。

这是一个真正的分辨率损失,这是诚实的交易:存在的 36 兆像素图像击败了浏览器拒绝绘制的 148 兆像素图像。 如果您需要十二张照片的全分辨率,请将它们合并成更少、较大的部分,或者使用没有画布的桌面工具。

结果应该是PNG还是JPG?

jpg 用于照片,用于截图的 PNG 以及任何带有文字或平面颜色的东西。

这是普通的规则,合并不会改变它,但合并确实使它变得更重要,因为输出很大。 5429 x 3024 合并两张照片是您会在 PNG 尺寸下注意到的文件,并且不会以 0.92 的 JPEG 质量,这就是此出口的内容。

相反的屏幕截图。 JPEG 的色度子采样和块变换在清晰的文本边缘周围产生可见的边缘,合并的屏幕截图条形多为清晰的文本边缘。 PNG是无损的,所以文本保持与原来一样清晰。

混合合并没有正确的答案。 如果您的输入之一是带有文本的屏幕截图,而另一张是照片,请选择读者将查看的内容。

合并会降低质量吗?

绘图没有,但缩放可能,值得知道哪个是哪个。

以其原生大小绘制的像素被复制,而不是重新压缩。 在同一相机的两个横向合并的两个横向合并中,没有任何缩放,因此输出中的每个像素都来自输入像素。

缩放是质量的地方。 任何放大以匹配更高邻居的图片都会重新采样,它发明了从未拍过的像素。 放大 3.4 倍以匹配照片宽度的屏幕截图在某种程度上是柔和的,这里没有任何设置可以修复。 没有任何东西被升级到被匹配的轴上的最大输入,所以有一个天花板,但大画面旁边的一幅小画面仍然被拉伸到它。

然后是出口。 选择JPG可以重新编码所有内容,包括已经是JPEG的输入,这是对它们的第二代有损压缩。 它与描述的机制相同 有关提取曲目的音频指南,在不同的媒介中:对有损的东西进行解码并再次压缩它永远不会是免费的。 在质量 0.92 的情况下,成本很小,对于合并的照片条,无论如何它都是正确的选择。

图像的顺序是什么?

您添加它们的顺序,从左到右或从上到下,更改它的唯一方法是删除一个并再次添加它。

在一次选择十二个文件之前,这是值得了解的,因为文件选择器以自己的顺序将它们交给它们,这通常是按文件名的字母顺序,有时不是。 对于一个重要的序列,比如结账流程,按你想要的顺序一次添加一个序列比之后修复它更少。

三十张图片是天花板。 这不是画布限制,它是一个理智限制:合并三十张手机照片是一个 30 兆像素的网格,之后是一个没有人可以阅读的布局。

合并的图像不给你什么?

设计工具所做的一切,这是合并工具的诚实边界。

单个图片周围没有边框,没有圆角,没有阴影,没有字幕,没有每个图像的旋转,没有重叠,没有除了白色之外的背景颜色。 每张图片都被绘制到其矩形中,这就是整个特征集。

如果您想要带有文本的框架拼贴画,那就是设计工作和设计工具。 如果你想把三张图片放在一个文件中,这样可以接受一张图像的东西得到所有三个,那就是这个。 将第二个视为第一个的弱版本是通常的失望来源。

两个相邻的工具涵盖了常见的后续行动: 向图像添加文本 为标题,和 图像压缩器 当合并的照片网格出现大于上传限制允许时。

为什么会在浏览器中运行?

因为图像永远不需要去任何地方,而当它们到达时,这是别人的决定,他们会发生什么。

整个合并是一个画布操作。 您的文件被解码到页面内存中,绘制到选项卡中的画布上,画布作为下载通过 toBlob。 没有请求携带图像,没有写入服务器,也没有存储的副本供任何人泄漏或忘记。

对于很多合并,这是一个很好的选择。 对于银行对账单的截图、文件的照片、医疗扫描或儿童的照片的截图,使用这样的工具而不是要求您上传的第一个结果的全部原因。

成本是上面描述的画布天花板,非常大的合并受到标签可以容纳多少内存的限制。 对于两张图片或十二幅图像,您将遇到的限制都不是。

Comments

0 comments

0/2000 characters

No comments yet. Be the first to share your thoughts!