一位朋友給我發了一張電話照片和一張截圖，並在一張圖片中要求他們列出。 我以自己的尺寸將兩者都放入畫布中，並得到了沒人會接受的東西：一張 4032 x 3024 的照片，旁邊是一張窄 1170 x 2532 的截圖，螢幕截圖下方有一條空白的帶子，整個 5202 像素寬。 圖片很好。 安排是問題，每次都是一樣的問題，因為這兩個檔案幾乎從不共享一個維度。 決定哪個軸必須排列是整個工作，其他一切都隨之而來。
TL;DR: 合併圖像是一個縮放的決定，然後才是繪圖決定。 並排將每張圖片與最高的高度相匹配，將匹配到最寬的寬度，並且網格匹配兩者，這就是為什麼網格也必須在裁剪和留出空間之間做出選擇。 在 1170x2532 螢幕截圖旁邊的 4032x3024 照片中測量：並排製作 5429x3024 畫布，螢幕截圖放大到 1397x3024，堆疊產生 4032x11750 畫布，螢幕截圖放大 3.4%，在 6% 的 6 倍。 選擇要保留的軸的模式。 那個 圖片合併 在瀏覽器標籤中繪製所有內容，因此沒有上傳。
為什麼合併的圖像看起來不對？
因為輸入是不同的形狀，大多數工具會以它們到達的任何大小來繪製它們。
一張電話照片是 4032 x 3024。 電話截圖是 1170 x 2532。 掃描就是掃描器決定的任何內容。 將其中任何兩個以原生大小排成一排，其中一個高聳於另一個，死空間填滿更高維度的剩餘物。 這讀起來是錯誤而不是佈局，即使是對無法告訴你為什麼的人來說也是如此。
修復是規範化，唯一的問題是關於哪個軸。 一排，頂部和底部是眼睛的後面，所以高度必須匹配，每張圖片都採取它自己的縱橫比，然後給它。 在一列中，左右邊緣是線，因此寬度匹配。 網格有兩個邊可以保持，所以它必須同時匹配，這就是必須給予的模式。
這就是整個設計。 下面的一切都是從中產生的。
並排對高大的螢幕截圖有什麼影響？
它擴大了它，有時比你想要的要多。
這是上面這對的測量結果，取自佈局代碼而不是估計：
| 模式 | 帆布 | 照片繪製在 | 截圖 |
|---|---|---|---|
| 並排 | 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 截圖的單元格。 只有兩個誠實的答案，工具要求你在它們之間做出選擇：
- 遏制 適合牢房內的整個畫面，並在其周圍留出空間。 沒有任何東西遺失，網格看起來有點破爛，因為每個圖像都位於自己的背景中。
- 蓋 透過從圖片中取出一個有中心的作物來完全填充細胞。 網格看起來均勻，圖片的邊緣消失了。
一般來說都不是正確的。 包含適用於螢幕截圖、文件、圖表和任何邊緣攜帶資訊的任何內容。 遮蓋物適合面部、風景和紋理，而集中作物是人們無論如何都會做的事情。
這裡的預設是覆蓋，因為建構網格的最常見原因是它應該作為一個物件讀取。
封面丟了多少照片？
當輸入是不同的形狀時，比人們預期的要多，而當它們匹配時根本沒有。
單元大小是輸入的平均值，因此兩個截然不同的圖片產生一個既不適合的單元格。 對於照片和螢幕截圖對，在兩單元網格中，佈局程式碼準確地報告了被繪製的內容：
| 形像 | 本土的 | 繪製的源區 | 保持像素 |
|---|---|---|---|
| 照片 | 4032 x 3024 | 2831 x 3024 | 70.2% |
| 螢幕截圖 | 1170 x 2532 | 1170 x 1250 | 49.4% |
一半的截圖不見了。 沒有壓縮，沒有縮放：頂部和底部被剪掉，因為一個高大的窄圖像被迫進入一個幾乎方形的單元格，必須失去它的末端。 如果該螢幕截圖是收據，則總數不在圖片中。
同一台相機對十二張照片的相同操作沒有任何裁剪，因為每個輸入都已經有了單元格的形狀。 當輸入同意時，覆蓋很便宜，而當輸入同意時很昂貴，並且工具無法判斷您處於哪種情況。 切換到包含您圖片不同形狀的那一刻，邊緣很重要。
網格應該有幾列？
足以使結果比高大更寬，對於大多數計數來說，這意味著平方根向下圓。
行從列和計數開始，算術是無情的。 四列中的十二個圖像是三整行。 三列中的七個圖像是三行，末端有兩個空白單元格，佈局將其作為背景留下，而不是拉伸最後一張圖片來填充它們。
| 圖片 | 列 | 結果 |
|---|---|---|
| 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 通道，並且未上漆的 Gap Export 為黑色。 因此，該工具的 PNG 具有白色的排水溝而不是透明的，如果您打算將結果放在彩色背景上，這很重要。
合併後的圖像有多大？
比輸入大，在堆疊的情況下大得多，因為沒有任何東西被壓縮。
畫布尺寸是可以從模式預測的。 並排，寬度是比例寬度的總和，高度是最高的輸入。 堆疊，寬度是最寬的輸入，高度是總和。 網格是單元格加間隙的列乘以。
四列網格中的十二張手機照片為 16,208 x 9,136 像素，即 148 兆像素。 這就是下一節開始的地方。
為什麼輸出在 8,000 像素處停止？
因為超過一定大小，瀏覽器畫布停止工作，它並沒有這麼說。
限制不是規範。 MDN 說得很清楚：大多數瀏覽器超過 10,000 比 10,000 像素，iOS 設備歷來限制為 4,096 x 4,096，並且超過最大尺寸或區域“渲染無法使用畫布”，繪圖命令無聲無線失敗。 捕捉也不例外。 你會得到一張空白的圖像，或者什麼都沒有。 每個瀏覽器的數字收集在 帆布尺寸測試結果，這是在假設數字之前值得檢查的參考。
因此，佈局被縮小以適應 8,000 像素的長邊，而不是允許失敗。 對於那個十二張照片網格，比例因子為 0.494，16,208 x 9,136 下降到 8,000 x 4,509，即 36 兆像素。 每張照片的降落在 1,483 份約 1,976 份，而不是 4,032 張 x 3,024 的。
那是真正的分辨率損失，這是誠實的交易：存在的 36 兆像素圖像勝過瀏覽器拒絕繪製的 148 兆像素圖像。 如果您需要十二張照片的完整解析度，將它們合併成更少、更大的部分，或使用沒有畫布的桌面工具。
結果應該是 PNG 還是 JPG？
用於照片的 jpg，用於截圖的 png 以及任何帶有文字或平面色彩的 png。
這是普通的規則，合併不會改變它，但合併確實使它變得更重要，因為輸出很大。 5429 到 3024 合併兩張照片是您會注意到的文件，您會注意到 PNG 的大小，而不是 JPEG 質量 0.92，這是它出口的。
反之亦然，適用於螢幕截圖。 JPEG 的色度子採樣和區塊變換會在鋒利的文字邊緣周圍產生可見的邊緣，而合併的螢幕截圖條主要是鋒利的文字邊緣。 PNG 是無損的，所以文字保持與以前完全一樣清晰。
混合合併沒有正確的答案。 如果您的輸入之一是帶有文字的螢幕截圖，而另一個是照片，則選擇讀者將查看哪一個。
合併會失去品質嗎？
圖紙沒有，但縮放可能會，值得知道哪個是哪個。
以原生大小繪製的像素被複製，而不是重新壓縮。 在同一台相機的兩張橫向照片的並排合併中，完全沒有縮放，因此輸出中的每個像素都來自輸入像素。
縮放是品質的去處。 任何與較高的鄰居相匹配的圖片都會重新採樣，它發明了從未拍攝過的像素。 螢幕截圖放大 3.4 次以匹配照片的寬度，以一種沒有設定的方式來修復。 沒有任何東西會超過軸上的最大輸入，所以有一個天花板，但是旁邊的一張大圖仍然被拉伸到它。
然後是出口。 選擇 JPG 可以重新編碼所有內容，包括已經是 JPEG 的輸入，這是對這些的第二代有損壓縮。 是同一機制 關於提取曲目的音頻指南，在不同的媒介中：解碼有損的東西並再次壓縮它永遠不會自由。 品質 0.92 的成本很小，對於合併的照片片來說，無論如何都是正確的選擇。
影像以什麼順序排列？
您添加它們的順序，從左到右或從上到下，更改它的唯一方法是刪除一個並再次添加它。
在您一次選擇十二個檔案之前，這是值得了解的，因為檔案選擇器按自己的順序交出它們，這通常是按字母順序按字母順序排列的，有時不會。 對於重要的序列，例如結帳流程，一次添加它們的順序比事後修復它更少。
三十張圖片是天花板。 這不是畫布限制，而是理智限制：三十張手機合併的合併是蓋帽之後的 30 兆像素網格和無人能讀的佈局。
合併的圖像沒有給你什麼？
設計工具所做的一切，這是合併工具的誠實邊界。
單張圖片周圍沒有邊框，沒有圓角，沒有陰影，沒有標題，沒有每個圖像的旋轉，沒有重疊，沒有除了白色之外的背景顏色。 每張圖片都被畫到它的矩形中，這就是整個特徵集。
如果您想要一個帶有文字的框架拼貼，那就是設計工作和設計工具。 如果您想將三張圖片放在一個檔案中，以便接受一張圖片的東西得到所有三個，那就是這個。 將第二個視為第一個的弱版本是令人失望的常見來源。
兩個相鄰的工具涵蓋了常見的後續行動： 將文字添加到圖像中 標題，和 圖像壓縮機 當合併的照片網格出來時，超出上傳限制。
為什麼它在瀏覽器中運行？
因為圖像永遠不需要去任何地方，而當它們去任何時候，他們都會發生什麼，這是別人的決定。
整個合併是畫布操作。 您的檔案被解碼為頁面記憶體，繪製在標籤中的畫布上，畫布將作為下載傳回給下載 toBlob。 沒有請求攜帶圖像，沒有寫入伺服器，也沒有儲存的副本供任何人洩漏或忘記。
對於很多合併來說，這是一個不錯的選擇。 對於涉及銀行對帳單、文件照片、醫療掃描或孩子照片的截圖，這就是使用這樣的工具而不是要求您上傳的第一個結果的全部原因。
成本是上面描述的畫布天花板，而且非常大的合併受限於選項卡可以容納多少記憶體。 對於兩個圖像或十二個圖像，您也不是遇到的限制。
