友人が電話の写真とスクリーンショットを送ってくれて、リストの 1 つの画像に入れてくれるように頼んだ。 両方を自分のサイズでキャンバスに落とし、誰も受け入れられないものを手に入れました。1170 x 2532 の狭いスクリーンショットを含む 4032 x 3024 の写真、その横にある空白の帯、全幅 5202 ピクセルの写真。 写真は大丈夫でした。 2 つのファイルが次元を共有することはほとんどないため、配置が問題でした。これは、毎回同じ問題です。 どの軸を並べるかを決めることが仕事全体であり、それ以外のすべてがその先にあります。
tl;dr: 画像のマージは、描画の前にスケーリングすることを決定します。 サイド バイ サイドは、すべての写真を最も高い高さに合わせ、スタッキングを最も広い幅に合わせて積み重ね、グリッドが両方に一致するため、グリッドはトリミングとスペースのどちらかを選択する必要があります。 4032x3024 の写真で測定された 1170x2532 スクリーンショット: 横に並べると、スクリーンショットが 1397x3024 に拡大された 5429x3024 キャンバスが生成され、スタッキングすると 4032x11750 のキャンバスが 3.4 倍に拡大され、2 倍の範囲のキャンバスが生成され、2 セルのグリッドがフォトの 70.2% に保たれます。 保持する軸のモードを選択します。 ザ・ イメージの合併 すべてをブラウザー タブに描画するので、何もアップロードされません。
マージされた画像が間違っているように見えるのはなぜですか?
入力は異なる形状であり、ほとんどのツールは、どのサイズの入力でもそれらを描画します。
電話の写真は、横になって 3024 で 4032 です。 電話のスクリーンショットは 1170 で 2532 です。 スキャンはスキャナーが決めたものです。 これらのうちの 2 つをネイティブ サイズで一列に並べ、1 つがもう一方の上にそびえ立ち、高い寸法のデッド スペースで埋めます。 理由を教えてくれなかった人にとっても、レイアウトではなく、間違いとして読み取れます。
修正は正規化することであり、唯一の問題はどの軸上にあるかです。 上下は目が続くものであるため、高さは一致する必要があり、各写真はそれ自体の縦横比がどのような幅を取るかを取ります。 列では、左端と右端が線であるため、幅が一致します。 グリッドには保持する両エッジがあるため、両方に一致する必要があります。これは、何かが与えられるモードです。
それが全体のデザインです。 以下はすべて、そこから続くものです。
背の高いスクリーンショットに対して、並んでいると何をしますか?
それはあなたが望む以上に拡大します。
これは、推定ではなくレイアウト コードから取得した、上記のペアの測定結果です。
| モード | キャンバス | で描かれた写真 | で描かれたスクリーンショット |
|---|---|---|---|
| 並んで | 5429 x 3024 | 4032 x 3024 | 1397 x 3024 |
| 積み重ねられた | 4032 x 11750 | 4032 x 3024 | 4032 x 8726 |
2 つの高さの 2 つの高さの 3024 と両方を並べて一致させたため、スクリーンショットの高さは 2532 から 3024 ピクセルになりました。 これは 19% の拡大であり、テキストのスクリーンショットでは、探してみると表示され、見ていない場合は表示されません。
スタッキングは劇的なものです。 より広い画像に合わせると、スクリーンショットは幅 1170 から 4032 ピクセル、3.4 倍になり、キャンバスの高さは 11,750 ピクセルになりました。 スクリーンショットは現在、非常に長い画像の中で支配的なオブジェクトであり、その中の文字はすべて 3 回以上スケールアップされており、これは再サンプリングの量がシャープになりません。
教訓は、1 つのモードが優れているということではありません。 どの画像が拡大されるかはモードによって決定されるので、一致した軸が一致した画像を選択します。 横にある 2 枚の写真の写真は高さを共有し、スケーリングをまったく行わずに並べて表示されます。 同じ電話機の 2 つのスクリーンショットは幅を共有し、完全にスタックします。
並んで行くのではなく、いつスタックする必要がありますか?
コンテンツが下向きに読み取られるとき、または写真がすでに同じ幅になっているとき。
積み重ねはシーケンスに適しています。チェックアウト フローの 3 つのスクリーンショット、前後の AFTER が属する前後の、一部の会話のキャプチャ。 同じ向きで同じデバイスから入力が得られたときも、幅が一致しており、何もスケーリングされないため、これは正しいことです。
4032 x 11,750 の画像は表示されるのではなくスクロールされるため、並べて表示するのは適切です。目は下ではなく下ではなく下に移動する必要があります。また、投稿でインラインで表示されるものはすべて、4032 x 11,750 の画像が表示されるのではなくスクロールされるためです。
行を好む実用的な理由もあります。 1 つの画像を受け入れるほとんどの場所では、画像が固定幅で表示されるため、非常に背の高いマージが縮小してスライバーに縮小されます。 同じ高さの 3 枚の写真の列は、その幅で 3 列の列が見たことのない方法で読み続けられます。
ストリップがそうでないことをグリッドが判断する必要があるのは何ですか?
セルの形状ではない写真をどうするか。これは、ストリップが 1 つの軸しかピンをピン留めしないため、決して尋ねる必要のない質問です。
グリッドは両方をピンで留めます。 すべてのセルは同じサイズで、4:3 の写真は、9:19.5 のスクリーンショットの形をしたセルには適合しません。 正直な答えは 2 つしかなく、ツールはそれらのどちらかを選択するように求めます。
- 含む セル内に全体像を収まり、周囲にスペースを残します。 何も失われず、各画像は独自の背景にあるため、グリッドは少しぼろぼろに見えます。
- カバー 中心にあるトリミングを写真から取り出すことにより、セルを完全に埋めます。 グリッドが均一に見え、写真のエッジがなくなります。
どちらも一般的に正しいわけではありません。 スクリーンショット、ドキュメント、図、エッジが情報を運ぶあらゆるものに最適です。 カバーは、顔、風景、テクスチャーに適しています。中心に収穫した作物は、とにかく人が行うことになります。
グリッドを作成する最も一般的な理由は、1 つのオブジェクトとして読み取る必要があるため、ここでのデフォルトは COVER です。
カバーはどれくらいの写真を投げ捨てますか?
入力が異なる場合は、人々が予想以上に形を整え、一致する場合は何もありません。
セル サイズは入力の平均であるため、2 つの非常に異なる写真がどちらにも合わないセルを生成します。 写真とスクリーンショットのペアの場合、2 セル グリッドでは、レイアウト コードが描画される内容を正確に報告します。
| イメージ | ネイティブ | ソース領域が描画されます | ピクセルを保持 |
|---|---|---|---|
| 写真 | 4032 x 3024 | 2831 x 3024 | 70.2% |
| スクショした | 1170 x 2532 | 1170 x 1250 | 49.4% |
スクリーンショットの半分がなくなっています。 圧縮されていない、スケーリングされていない: 上下にトリミングされます。これは、ほぼ正方形に近いセルに押し込まれた背の高い画像は、その端を失わなければならないためです。 そのスクリーンショットが領収書である場合、合計は写真に表示されません。
同じカメラからの 12 枚の写真で同じ操作を行うと、すべての入力がすでにセルの形状を持っているため、何もトリミングされません。 カバーは、入力が一致すると安価であり、そうでない場合は高価であり、ツールはあなたがどのケースにいるのかを判断できません。 写真が異なる形になり、エッジが重要になる瞬間に切り替えます。
グリッドには何列あるべきですか?
結果が背の高いよりも広いほど広く、これは、ほとんどのカウントで、平方根が丸められたことを意味します。
行は列とカウントから続き、算術は容赦がありません。 4 列の 12 の画像は、3 つの完全行です。 3 列の 7 つの画像は、3 つの行であり、最後に 2 つの空のセルがあり、レイアウトは最後の画像を伸ばして塗りつぶすのではなく、背景として残します。
| 画像 | 列 | 結果 |
|---|---|---|
| 4です | 2です | 2×2、隙間なし |
| 6か | 3つです | 2×3、隙間なし |
| 7です | 3つです | 3 行、2 つのセルが空です |
| 9です | 3つです | 3×3、隙間なし |
| 12です | 4です | 3×4、隙間なし |
明確に考慮に入れることは、目指す価値があります。 7 枚の写真があっても、空のコーナーが気になる場合、7 つの等しいセルの配置が長方形ではないため、1 つをドロップするか、追加するか、または受け入れるかを修正します。
なぜギャップ設定があるのですか? また、それは何ですか?
画像に触れると 1 つの画像として読み取られるため、間違っている場合があります。
パノラマの前後は 1 フレームのように見えるはずですが、継ぎ目がポイントの場合は、ゼロのギャップが適切です。 そのため、ここではデフォルトです。
写真が 1 つのファイルにある別個のものである場合、ギャップは適切です。3 つの製品ショット、スクリーンショットのセット、コラージュです。 8 から 24 ピクセルの間のどこかで、数千ピクセルの画像で機能し、スライダーはより大きな作業の場合は 80 に移動します。 隙間は外側とその間に適用されるため、結果はエッジからブリーブしている写真ではなく境界線があります。
ギャップのあるマージを PNG にする前に知っておくべきことの 1 つ: ギャップは白で埋められ、透明なままではありません。 JPEG にはアルファ チャネルがなく、未描画のギャップが黒としてエクスポートされるため、キャンバスは何かを描画する前に白く塗られます。 したがって、このツールの PNG には、透明なガターではなく白いガターがあります。これは、色付きの背景に結果を配置する場合に重要です。
マージされた画像はどのくらいの大きさになりますか?
入力よりも大きく、積み重ねられたケースでは、何も圧縮されていないため、はるかに大きくなります。
キャンバスの寸法はモードから予測できます。 横に並べると、幅はスケーリングされた幅の合計で、高さは最も高い入力です。 積み重ねられた、幅は最も広い入力で、高さは合計です。 グリッドは、セルとギャップの列の列です。
4 列グリッド内の 12 枚の電話写真は、16,208 x 9,136 ピクセル、つまり 148 メガピクセルになります。 そこから次のセクションが始まります。
出力が 8,000 ピクセルで停止するのはなぜですか?
特定のサイズを過ぎてもブラウザーのキャンバスは機能しなくなり、そうは言っていません。
制限は仕様ではありません。 MDN ははっきりと言います: ほとんどのブラウザーは 10,000 × 10,000 ピクセルを超え、iOS デバイスは歴史的に 4,096 x 4,096 に制限され、最大寸法または領域を超えて [キャンバスを使用不可にする] を超えると、描画コマンドが黙って失敗します。 捕まえるのは例外ではありません。 空白の画像が表示されるか、何も表示されません。 ブラウザごとの数値は、 キャンバスサイズのテスト結果、これは、数値を想定する前に確認する価値のある参照です。
そのため、レイアウトは、失敗するのではなく、8,000 ピクセルの長辺に収まるように縮小されています。 12 枚のフォト グリッドの場合、スケール係数は 0.494 で、16,208 × 9,136 から 8,000 × 4,509 まで、つまり 36 メガピクセルになります。 各写真は、4,032 x 3,024 ではなく、およそ 1,976 x 1,483 の写真に上陸します。
これは、解像度の真の損失であり、正直な取引です。存在する 36 メガピクセルの画像は、ブラウザーが描画を拒否する 148 メガピクセルの画像よりも優れています。 12 枚の写真の完全な解像度が必要な場合は、それらをより少ない、より大きな部分に統合するか、途中でキャンバスのないデスクトップ ツールを使用します。
結果は png または jpg である必要がありますか?
写真は jpg、スクリーンショットは png で、テキストまたはフラット カラーのすべてのものを表示します。
これは通常のルールであり、マージしても変更されませんが、マージすると、出力が大きいため、より重要になります。 2 枚の写真の 5429 によるマージは、PNG サイズで気付くファイルであり、JPEG 品質 0.92 ではありません。これは、これがエクスポートするものです。
スクリーンショットの場合はその逆。 JPEG'S の Chroma サブサンプリングとブロック変換により、鮮明なテキスト エッジの周りに目に見えるフリンジが生成され、スクリーンショットのマージされたストリップは、ほとんどの場合、シャープなテキスト エッジになります。 PNG はロスレスなので、テキストは以前とまったく同じように鮮明なままです。
混合マージには正解はありません。 入力の 1 つがテキスト付きのスクリーンショットで、もう 1 つが写真である場合は、読者がどの入力を見るかを選択します。
マージは品質を失いますか?
図面はそうではありませんが、スケーリングは可能であり、どれがどれであるかを知る価値があります。
ネイティブ サイズで描画されたピクセルは、再圧縮されずにコピーされます。 同じカメラからの 2 枚の風景写真を並べてマージすると、何もスケーリングされないため、出力のすべてのピクセルが入力ピクセルから取得されました。
スケーリングは、品質がどこに行くのかです。 より高い近隣に合わせて拡大された写真は再サンプリングされ、これは、撮影されたことのないピクセルを発明します。 写真の幅に合わせて 3.4 倍に拡大されたスクリーンショットは、ある意味ソフトで、ここでの設定を修正しないで柔らかいです。 一致する軸上の最大の入力を超えてアップスケールされているものは何もないため、天井がありますが、大きな画像の横にある小さな写真は、それでもそれに到達するまで伸ばされます。
それからエクスポートがあります。 JPG を選択すると、すでに JPEG であった入力を含め、すべてを再エンコードします。これは、それらの第 2 世代の非可逆圧縮です。 で説明されているのと同じメカニズムです トラックの抽出についてのオーディオ ガイド、別の媒体で: 損失の多いものをデコードして、それを再度圧縮することは、決して自由ではありません。 0.92 の品質では、コストは低く、マージされた写真ストリップの場合は、とにかく適切な方法です。
画像はどの順番で表示されますか?
追加した順序、左から右または上から下に、変更する唯一の方法は、1 つを削除して再度追加することです。
一度に 12 個のファイルを選択する前に知っておく価値があります。ファイル ピッカーがファイル名を自分で引き渡すのは、通常はファイル名でアルファベット順で、時にはそうではないからです。 チェックアウト フローなど、重要なシーケンスの場合、必要な順序で一度に 1 つずつ追加する方が、後で修正するよりも手間がかかりません。
30 枚の画像が天井です。 これはキャンバスの制限ではなく、正気度の制限です。電話の写真 30 枚の結合は、キャップの後に 30 メガピクセルのグリッドで、誰も読むことができないレイアウトです。
マージされた画像があなたに与えないものは何ですか?
デザイン ツールが行うすべてのことは、マージ ツールの正直な境界です。
個々の写真の周りに境界線はなく、角が丸くなったり、ドロップ シャドウができず、キャプションも、画像ごとの回転も、重複もなく、白以外の背景色もありません。 各図は長方形に描かれ、それがフィーチャー セット全体です。
テキスト付きの額入りコラージュが必要な場合、それはデザイン ジョブとデザイン ツールです。 1 つのファイルに 3 つの写真を入れて、1 つの画像を受け入れるものが 3 つすべてを取得するようにしたい場合、これが 3 つになります。 2 番目を最初のバージョンの弱いバージョンとして扱うことは、通常の失望の原因です。
隣接する 2 つのツールは、一般的なフォローアップをカバーしています。 画像にテキストを追加する キャプションのために、そして 画像コンプレッサー 結合された写真グリッドがアップロード制限よりも大きくなる場合。
なぜこれがブラウザで実行されるのですか?
画像はどこにも行く必要は決してないので、その瞬間、自分に何が起こるかは他の誰かの決定です。
マージ全体はキャンバス操作です。 ファイルはページ メモリにデコードされ、タブ内のキャンバスに描画され、キャンバスがダウンロードとして返されます。 toBlob。 リクエストにはイメージがありません。サーバーに何も書き込まれません。リークまたは忘れるためのコピーが保存されません。
多くのマージの場合、それは素晴らしいことです。 銀行取引明細書のスクリーンショット、書類の写真、医療スキャン、または子供の写真が含まれるものの場合、アップロードを求める最初の結果ではなく、このようなツールを使用するのが完全な理由です。
コストは、上記のキャンバスの天井であり、非常に大きなマージはタブが保持できるメモリの量によって制限されるという事実です。 2 枚の画像、または 12 枚の画像の場合、どちらも制限はありません。
