画像グリッド分割

画像グリッド分割ツールは、1 枚の画像を同じ大きさのタイルに分けるツールで、SNS 用には 3×3 の 9 分割がよく使われます。Instagram、WeChat Moments、Weibo などで正しい順番に投稿すると、プロフィールやフィード上で元の大きな画像が再構成されます。キャンペーンビジュアル、商品ティザー、イベント告知、ポートフォリオ演出など、1 投稿より全体構図を見せたい場面に向いています。顔や文字が切れない余白、元画像の比率、投稿順序が重要で、1 枚でも順番を間違えると狙った見え方が崩れます。

画像グリッド分割ツールは HTML5 Canvas 2D API（WHATWG HTML Living Standard §4.12、元は W3C HTML5 勧告 2014 で規定）上に構築されています。パイプラインは 3 層で構成されます。ソースピクセルを CanvasImageSource にデコードし、drawImage の 9 引数形式でサブ矩形をオフスクリーンキャンバスにコピーし、canvas.toBlob() でオフスクリーンキャンバスを PNG としてエンコードします。すべてはブラウザタブ内で完結し、アップロードもサーバーもリモートレンダリングも不要です。 デコードステップは見た目以上に重要です。<input type='file'> またはドラッグ＆ドロップの DataTransferItem から取得した File は FileReader.readAsDataURL（または近代的なコードでは URL.createObjectURL）で Blob URL に読み込まれ、ブラウザが Image ローダーに渡します。Image 要素はプラットフォームの画像コーデック（Chromium では libpng/libjpeg-turbo/libwebp、WebKit/Gecko では同等物）がビットマップをデコードすると 'load' イベントを発火します。この方法で読み込まれた非 CORS 画像は「汚染」と見なされ、getImageData は SecurityError をスローするため、分割ツールは drawImage のみを使用してピクセル配列の読み戻しを行わず、CORS 問題を完全に回避します。非常に大きな画像（長辺が約 8K を超える）では一部のエンジンでビットマップが GPU メモリに保持されるため、canvas.toBlob が GPU→CPU のリードバックを経由し、スマホでは約 30-100 ms のコストが発生します。 クロップはスライスごとに 1 回の drawImage 呼び出しで行われます。ctx.drawImage(img, sx, sy, sw, sh, dx, dy, dw, dh)。最初の 3 ペアがソース矩形（sx、sy、sw、sh）、後半の 3 ペアがデスティネーションキャンバス上のデスティネーション矩形です。1920x1080 の写真を 3x3 に分割する場合、各スライスのソース矩形は (col*640, row*360) から始まる 640x360 です。デスティネーションキャンバスはスライスのサイズ（640x360）に正確に設定され、canvas.toBlob(blob => ..., 'image/png') でプラットフォームの PNG エンコーダーが実行されます。PNG を JPEG より選択する理由は、グリッドスライスは通常シャープなテキストや UI 要素を含むクリーンな矩形クロップであり、可逆エンコードが重要であるためです。JPEG の 8x8 DCT ブロックはエッジをぼかしてしまいます。 バッチダウンロードは各 Blob に URL.createObjectURL を適用し、<a download> の合成クリックを行い、短い遅延（通常 60-120 秒、未使用 Blob URL のプラットフォームの寿命）後に revokeObjectURL を実行します。9 スライスの場合は 9 回のダウンロードイベントが連続で発火します。一部のブラウザは同一タブからの複数ダウンロードをスロットリングするため、本ページでは通常クリック間に 50-200 ms の setTimeout を設けて間隔を空けています。パフォーマンス面では、スマホでのボトルネックは通常 PNG エンコーダー（libpng はエンコードごとにシングルスレッド）であり、drawImage ではありません。9 枚の 1080p スライスの場合、中価格帯 Android で合計 200-500 ms、デスクトップ Chromium で 100-200 ms 程度が見込まれます。

• パイプライン: FileReader または URL.createObjectURL → Image 要素 → HTMLCanvasElement → drawImage 9 引数クロップ → canvas.toBlob('image/png') → URL.createObjectURL + <a download>。
• drawImage(img, sx, sy, sw, sh, dx, dy, dw, dh) はソース矩形 (sx,sy,sw,sh) をデスティネーション矩形 (dx,dy,dw,dh) にクロップする 9 引数のオーバーロードです。これが分割を実行する単一の API 呼び出しです。
• CORS ヘッダーなしで提供されたソース画像はキャンバスを「汚染」します。getImageData は SecurityError をスローするため、分割ツールはピクセル配列を読み取らず、ブリットとエンコードのみを行います。
• canvas.toBlob は非同期でノンブロッキング（コールバックは後のマイクロタスクで発火）です。レガシーの canvas.toDataURL は同期で、大きな画像でメインスレッドをフリーズさせます。
• NxM 画像を 3x3 に分割する場合、各スライスは (N/3) x (M/3) です。割り切れないサイズでは右端/下端に 1 ピクセルの余剰が生じ、Math.floor で処理し、必要に応じて明示的な余剰スライスを生成します。
• グリッドスライスに PNG を選択する理由は、各スライスがシャープなエッジ（テキスト、UI、図表）を含む矩形クロップであり、8x8 DCT ブロックでは境界線がぼやけるためです。
• バッチダウンロードは各 Blob に URL.createObjectURL + <a download> クリックを使用。ブラウザは同一タブからの複数ダウンロードをスロットリングするため、通常クリックを 50-200 ms 間隔で空け、クリック後に Blob URL をリボックしてメモリを解放します。
• パフォーマンスのボトルネックはプラットフォームの PNG エンコーダー（libpng はエンコードごとにシングルスレッド）であり、drawImage ではありません。9 枚の 1080p スライスは中価格帯モバイルで約 200-500 ms、デスクトップ Chromium で約 100-200 ms です。