Découpage en grille

Le découpeur de grille d’image divise une image en tuiles égales, le plus souvent en grille 3×3 de neuf images pour les réseaux sociaux. Publiées dans le bon ordre sur Instagram, WeChat Moments, Weibo ou des plateformes similaires, ces tuiles recomposent l’image d’origine dans la vue de profil ou de flux. L’outil sert aux visuels de campagne, teasers produit, annonces d’événements, portfolios et compositions où l’ensemble compte davantage que chaque publication isolée. Le résultat dépend du ratio de départ, des marges autour des visages et du texte, ainsi que de l’ordre de publication.

Le découpeur de grille d'image est construit sur l'API Canvas 2D du HTML5 (WHATWG HTML Living Standard §4.12, initialement spécifié dans la recommandation W3C HTML5 de 2014). Le pipeline comporte trois couches : décoder les pixels sources en un CanvasImageSource, copier un sous-rectangle de ces pixels dans un canvas hors écran via la forme à 9 arguments de drawImage, puis encoder le canvas hors écran en PNG via canvas.toBlob(). Tout se passe dans l'onglet du navigateur — aucun téléchargement, aucun serveur, aucun rendu distant. L'étape de décodage compte plus qu'il n'y paraît. Un File provenant de <input type='file'> ou d'un DataItem de glisser-déposer est lu par FileReader.readAsDataURL (ou, dans le code moderne, URL.createObjectURL) en une URL Blob, que le navigateur transmet au chargeur d'images. L'élément Image déclenche 'load' une fois le bitmap décodé par le codec d'image de la plateforme (libpng/libjpeg-turbo/libwebp sur Chromium, l'équivalent sur WebKit/Gecko). Une image non CORS chargée de cette manière est considérée comme « contaminée » — getImageData lancerait un SecurityError — le découpeur n'utilise donc que drawImage et ne lit jamais de tableaux de pixels, ce qui contourne entièrement le problème CORS. Pour les très grandes images (>~8K sur le côté le long), le bitmap est conservé en mémoire GPU dans certains moteurs, de sorte que canvas.toBlob peut passer par une lecture GPU→CPU qui coûte ~30 à 100 ms sur un téléphone. Le recadrage est un seul appel drawImage par tranche : ctx.drawImage(img, sx, sy, sw, sh, dx, dy, dw, dh) — les trois premières paires constituent le rectangle source (sx, sy, sw, sh) et les trois suivantes le rectangle destination sur le canvas cible. Pour une division 3×3 d'une photo 1920×1080, le rectangle source de chaque tranche est 640×360 démarrant à (col*640, row*360). Le canvas destination est dimensionné exactement à la tranche (640×360) puis canvas.toBlob(blob => ..., 'image/png') exécute l'encodeur PNG de la plateforme. Le PNG est préféré au JPEG car les tranches de grille sont généralement des recadrages rectangulaires nets avec du texte et des éléments d'interface nets où l'encodage sans perte compte ; les blocs DCT 8×8 du JPEG brouilleraient les lignes de contour. Le téléchargement par lot utilise URL.createObjectURL sur chaque Blob, un clic synthétique de <a download> et revokeObjectURL après un court délai (généralement 60 à 120 s, durée de vie de la plateforme pour une URL Blob inutilisée). Pour 9 tranches, cela déclenche 9 événements de téléchargement consécutifs ; certains navigateurs limitent les téléchargements multiples depuis un même onglet, la page les espacera donc généralement de 50 à 200 ms avec un setTimeout entre les clics. En termes de performances, le goulot d'étranglement sur un téléphone est généralement l'encodeur PNG (libpng est monothread par encodage), pas drawImage ; pour 9 tranches en 1080p, attendez 200 à 500 ms au total sur un Android milieu de gamme et 100 à 200 ms sur un Chromium de bureau.

• Pipeline : FileReader ou URL.createObjectURL → élément Image → HTMLCanvasElement → drawImage en 9 arguments pour le recadrage → canvas.toBlob('image/png') → URL.createObjectURL + <a download>.
• drawImage(img, sx, sy, sw, sh, dx, dy, dw, dh) est la surcharge à 9 arguments qui recadre un rectangle source (sx,sy,sw,sh) dans un rectangle destination (dx,dy,dw,dh) ; c'est le seul appel API qui effectue la découpe.
• Les images sources non servies avec des en-têtes CORS contaminent le canvas — getImageData lancerait un SecurityError, le découpeur ne lit donc jamais de tableaux de pixels, il ne fait que blitter et encoder.
• canvas.toBlob est asynchrone et non bloquant (le callback s'exécute sur une microtâche ultérieure) contrairement au legacy canvas.toDataURL qui est synchrone et bloque le fil principal pour les grandes images.
• Pour une division 3×3 d'une image N×M, chaque tranche fait (N/3) × (M/3) ; les tailles non divisibles produisent un reste d'1 pixel sur le bord droit/inférieur, géré par Math.floor avec une tranche de reste explicite si nécessaire.
• Le PNG est préféré au JPEG pour les tranches de grille car chaque tranche est un recadrage rectangulaire aux contours nets (texte, interface, diagrammes) où les blocs DCT 8×8 brouilleraient les lignes de délimitation.
• Le téléchargement par lot utilise URL.createObjectURL par blob + clic de <a download> ; les navigateurs limitent les téléchargements multiples depuis un même onglet, la page espace donc généralement les clics de 50 à 200 ms et révoque les URLs Blob après le clic pour libérer la mémoire.
• Le goulot d'étranglement des performances est l'encodeur PNG de la plateforme (libpng est monothread par encodage), pas drawImage ; 9 tranches en 1080p s'exécutent en ~200 à 500 ms sur mobile milieu de gamme et ~100 à 200 ms sur Chromium de bureau.