Bildraster-Teilung

Der Bildraster-Splitter zerlegt ein Bild in gleich große Kacheln, typischerweise als 3×3-Raster für neun Einzelbilder. Werden diese Kacheln in der richtigen Reihenfolge auf Plattformen wie Instagram, WeChat Moments oder Weibo veröffentlicht, entsteht im Profil oder Feed wieder das große Ausgangsbild. Das ist nützlich für Kampagnenmotive, Produktteaser, Eventankündigungen und visuelle Serien, bei denen der Gesamteindruck erst durch die Anordnung entsteht. Wichtig sind ein geeignetes Ausgangsformat, sichere Ränder für Text und Gesichter sowie die korrekte Upload-Reihenfolge, weil schon eine vertauschte Kachel den Effekt zerstören kann. Vor Veröffentlichung oder Abgabe sollte die Ausgabedatei geöffnet und auf Lesbarkeit, Zuschnitt, Auflösung und fehlende Inhalte geprüft werden.

Der Bildraster-Splitter basiert auf der HTML5 Canvas 2D API (WHATWG HTML Living Standard §4.12, ursprünglich in der W3C HTML5-Empfehlung von 2014 spezifiziert). Die Pipeline hat drei Ebenen: Die Quellpixel in eine CanvasImageSource decodieren, ein Teilrechteck dieser Pixel über die 9-Argument-Variante von drawImage in eine Offscreen-Canvas kopieren und die Offscreen-Canvas über canvas.toBlob() als PNG kodieren. Alles geschieht im Browser-Tab – kein Upload, kein Server, kein Remote-Rendering. Der Decodierungsschritt ist wichtiger, als er aussieht. Eine File von <input type='file'> oder ein Drag-Drop-DataTransferItem wird von FileReader.readAsDataURL (oder im modernen Code von URL.createObjectURL) in eine Blob-URL gelesen, die der Browser dem Image-Loader übergibt. Das Image-Element löst 'load' aus, sobald das Bitmap vom Plattform-Bildcodec decodiert wurde (libpng/libjpeg-turbo/libwebp bei Chromium, das Äquivalent bei WebKit/Gecko). Ein nicht-CORS-Bild, das so geladen wird, gilt als „tainted“ – getImageData würde einen SecurityError werfen – daher verwendet der Splitter nur drawImage und liest nie Pixelparrays zurück, was das CORS-Problem vollständig umgeht. Für sehr große Bilder (>~8K auf der langen Seite) wird das Bitmap in manchen Engines im GPU-Speicher gehalten, sodass canvas.toBlob über einen GPU→CPU-Readback laufen kann, der auf einem Handy etwa 30-100 ms kostet. Der Zuschnitt ist ein einzelner drawImage-Aufruf pro Slice: ctx.drawImage(img, sx, sy, sw, sh, dx, dy, dw, dh) – die ersten drei Paare sind das Quellrechteck (sx, sy, sw, sh) und die zweiten drei sind das Zielrechteck auf der Ziel-Canvas. Für einen 3×3-Schnitt eines 1920×1080-Fotos ist das Quellrechteck jedes Slices 640×360, beginnend bei (Spalte*640, Zeile*360). Die Ziel-Canvas wird exakt auf die Slice-Größe gesetzt (640×360) und dann führt canvas.toBlob(blob => ..., 'image/png') den Plattform-PNG-Encoder aus. PNG wird gegenüber JPEG bevorzugt, weil Raster-Slices typischerweise saubere rechteckige Zuschnitte mit scharfem Text und UI-Elementen sind, bei denen verlustfreie Kodierung wichtig ist; JPEGs 8x8-DCT-Blöcke würden Kanten verschmieren. Der Batch-Download verwendet URL.createObjectURL für jeden Blob, einen synthetischen <a download>-Klick und revokeObjectURL nach einer kurzen Verzögerung (normalerweise 60-120 s, die Lebensdauer der Plattform für eine ungenutzte Blob-URL). Für 9 Slices löst dies 9 Download-Events hintereinander aus; manche Browser drosseln mehrere Downloads vom selben Tab, daher verteilt die Seite diese typischerweise mit 50-200 ms setTimeout zwischen den Klicks. Leistungsmäßig ist der Flaschenhals auf einem Handy normalerweise der PNG-Encoder (libpng ist pro Kodierung singlethreaded), nicht drawImage; für 9 1080p-Slices sind 200-500 ms auf einem mittleren Android und 100-200 ms auf einem Desktop-Chromium zu erwarten.

• Pipeline: FileReader oder URL.createObjectURL → Image-Element → HTMLCanvasElement → drawImage-9-Argument-Zuschnitt → canvas.toBlob('image/png') → URL.createObjectURL + <a download>.
• drawImage(img, sx, sy, sw, sh, dx, dy, dw, dh) ist die 9-Argument-Überladung, die ein Quellrechteck (sx,sy,sw,sh) in ein Zielrechteck (dx,dy,dw,dh) zuschneidet; dies ist der einzelne API-Aufruf, der den Schnitt durchführt.
• Quellbilder, die nicht mit CORS-Headern ausgeliefert werden, kontaminieren die Canvas – getImageData würde einen SecurityError werfen, daher liest der Splitter nie Pixelparrays, sondern blittet und kodiert nur.
• canvas.toBlob ist asynchron und nicht-blockierend (Callback feuert auf einem späteren Microtask) im Gegensatz zum Legacy-canvas.toDataURL, das synchron ist und den Hauptthread bei großen Bildern blockiert.
• Für einen 3×3-Schnitt eines N×M-Bildes ist jeder Slice (N/3) × (M/3); nicht teilbare Größen produzieren einen 1-Pixel-Rest am rechten/unteren Rand, der mit Math.floor behandelt wird, ggf. mit einem expliziten Rest-Slice.
• PNG wird gegenüber JPEG für Raster-Slices bevorzugt, weil jeder Slice ein rechteckiger Zuschnitt mit scharfen Kanten (Text, UI, Diagramme) ist, bei dem 8x8-DCT-Blöcke die Grenzlinien verschmieren würden.
• Batch-Download verwendet URL.createObjectURL pro Blob + <a download>-Klick; Browser drosseln mehrere Downloads vom selben Tab, daher verteilt die Seite die Klicks typischerweise um 50-200 ms und widerruft Blob-URLs nach dem Klick, um Speicher freizugeben.
• Der Leistungsflaschenhals ist der Plattform-PNG-Encoder (libpng ist pro Kodierung singlethreaded), nicht drawImage; 9 1080p-Slices laufen in ca. 200-500 ms auf mittleren Mobilgeräten und ca. 100-200 ms auf Desktop-Chromium.