Divisor de imagen en cuadrícula

El divisor de cuadrícula de imagen separa una foto en piezas iguales, normalmente un conjunto 3×3 de nueve imágenes para redes sociales. Cuando las piezas se publican en el orden correcto en plataformas como Instagram, WeChat Moments o Weibo, el perfil o el feed reconstruye la imagen grande original. Es útil para campañas visuales, avances de producto, anuncios de eventos, portafolios y diseños donde la composición completa pesa más que cada publicación aislada. Para que funcione bien importan la proporción de la imagen fuente, los márgenes seguros para caras y texto, y el orden de subida, porque una pieza invertida rompe el efecto.

El divisor de imagen en cuadrícula está construido sobre la API Canvas 2D de HTML5 (WHATWG HTML Living Standard §4.12, originalmente especificado en la Recomendación W3C HTML5 de 2014). El pipeline tiene tres capas: decodificar los píxeles de origen en un CanvasImageSource, copiar un sub-rectángulo de esos píxeles en un canvas fuera de pantalla mediante la forma de 9 argumentos de drawImage, y luego codificar el canvas fuera de pantalla como PNG mediante canvas.toBlob(). Todo ocurre en la pestaña del navegador — sin subida, sin servidor, sin renderizado remoto. El paso de decodificación importa más de lo que parece. Un File de <input type='file'> o un DataItem de arrastrar y soltar se lee mediante FileReader.readAsDataURL (o, en código moderno, URL.createObjectURL) en un Blob URL, que el navegador entrega al cargador de Image. El elemento Image dispara 'load' una vez que el bitmap es decodificado por el códec de imagen de la plataforma (libpng/libjpeg-turbo/libwebp en Chromium, el equivalente en WebKit/Gecko). Una imagen sin CORS cargada así se trata como 'contaminada' — getImageData lanzaría un SecurityError — por lo que el divisor solo usa drawImage y nunca lee de vuelta arrays de píxeles, lo cual esquiva el problema CORS por completo. Para imágenes muy grandes (>~8K en el lado largo) el bitmap se mantiene en memoria GPU en algunos motores, por lo que canvas.toBlob puede pasar por una lectura GPU→CPU que cuesta ~30-100 ms en un teléfono. El recorte es una sola llamada a drawImage por porción: ctx.drawImage(img, sx, sy, sw, sh, dx, dy, dw, dh) — los primeros tres pares son el rectángulo origen (sx, sy, sw, sh) y los segundos tres son el rectángulo destino en el canvas destino. Para una división 3×3 de una foto de 1920×1080, el rectángulo origen de cada porción es 640×360 empezando en (col*640, row*360). El canvas destino se dimensiona exactamente a la porción (640×360) y luego canvas.toBlob(blob => ..., 'image/png') ejecuta el codificador PNG de la plataforma. PNG se elige sobre JPEG porque las porciones de cuadrícula típicamente son recortes rectangulares limpios con texto nítido y elementos de UI donde importa la codificación sin pérdida; los bloques DCT de 8×8 de JPEG difuminarían los bordes. La descarga por lotes usa URL.createObjectURL en cada Blob, un clic sintético de <a download>, y revokeObjectURL después de un breve retardo (generalmente 60-120 s, el tiempo de vida de la plataforma para un Blob URL sin usar). Para 9 porciones esto dispara 9 eventos de descarga consecutivos; algunos navegadores limitan múltiples descargas desde la misma pestaña, por lo que la página generalmente las espacia con un setTimeout de 50-200 ms entre clics. En rendimiento, el cuello de botella en un teléfono es generalmente el codificador PNG (libpng es mono-hilo por codificación), no drawImage; para 9 porciones de 1080p esperar 200-500 ms totales en un Android de gama media y 100-200 ms en un Chromium de escritorio.

• Pipeline: FileReader o URL.createObjectURL → elemento Image → HTMLCanvasElement → drawImage de 9 argumentos para recorte → canvas.toBlob('image/png') → URL.createObjectURL + <a download>.
• drawImage(img, sx, sy, sw, sh, dx, dy, dw, dh) es la sobrecarga de 9 argumentos que recorta un rectángulo origen (sx,sy,sw,sh) en un rectángulo destino (dx,dy,dw,dh); esta es la única llamada API que realiza la división.
• Las imágenes de origen que no se sirven con cabeceras CORS contaminan el canvas — getImageData lanzaría SecurityError, por lo que el divisor nunca lee arrays de píxeles, solo blit y codifica.
• canvas.toBlob es asíncrono y no bloqueante (el callback se dispara en un microtarea posterior) versus el legacy canvas.toDataURL que es síncrono y congela el hilo principal para imágenes grandes.
• Para una división 3×3 de una imagen N×M cada porción es (N/3) × (M/3); tamaños no divisibles producen un resto de 1 píxel en el borde derecho/inferior, manejado con Math.floor con una porción de resto explícita si es necesario.
• PNG se elige sobre JPEG para las porciones de cuadrícula porque cada porción es un recorte rectangular con bordes nítidos (texto, UI, diagramas) donde los bloques DCT de 8×8 difuminarían las líneas límite.
• La descarga por lotes usa URL.createObjectURL por blob + clic de <a download>; los navegadores limitan múltiples descargas en la misma pestaña, por lo que la página generalmente espacia los clics por 50-200 ms y revoca los Blob URLs tras el clic para liberar memoria.
• El cuello de botella de rendimiento es el codificador PNG de la plataforma (libpng es mono-hilo por codificación), no drawImage; 9 porciones de 1080p tardan ~200-500 ms en móvil de gama media y ~100-200 ms en Chromium de escritorio.