Разделение изображения на сетку

Разделитель изображения на сетку нарезает одну картинку на равные плитки, чаще всего на формат 3×3 из девяти изображений для социальных сетей. Если опубликовать части в правильном порядке в Instagram, WeChat Moments, Weibo или похожих сервисах, профиль или лента снова складывает исходную большую композицию. Инструмент полезен для рекламных визуалов, тизеров продуктов, анонсов событий, портфолио и серий, где общий вид важнее отдельного поста. Для хорошего результата нужны подходящее соотношение сторон, запас вокруг текста и лиц, а также точный порядок загрузки. Перед публикацией лучше сохранить все части с понятными именами. Перед публикацией или отправкой нужно открыть результат и проверить читаемость, crop, resolution, порядок и отсутствующие элементы.

Разделитель изображений на сетку построен на HTML5 Canvas 2D API (WHATWG HTML Living Standard §4.12, первоначально определён в рекомендации W3C HTML5 2014 года). Конвейер имеет три уровня: декодирование исходных пикселей в CanvasImageSource, копирование под-прямоугольника этих пикселей в offscreen-холст через 9-аргументную форму drawImage и кодирование offscreen-холста в PNG через canvas.toblob(). Всё происходит во вкладке браузера — никакой загрузки на сервер, никакого удалённого рендеринга. Этап декодирования важнее, чем кажется. Файл из <input type='file'> или перетаскиваемый DataTransferItem читается через FileReader.readAsDataURL (или, в современном коде, URL.createObjectURL) в Blob URL, который браузер передаёт загрузчику Image. Элемент Image срабатывает 'load' после декодирования растрового изображения платформенным кодеком (libpng/libjpeg-turbo/libwebp в Chromium, эквивалент в WebKit/Gecko). Изображение без CORS, загруженное таким образом, считается «загрязнённым» — getImageData выбросил бы SecurityError — поэтому разделитель использует только drawImage и никогда не считывает массивы пикселей, что полностью обходит проблему CORS. Для очень больших изображений (>~8K по длинной стороне) растровое изображение может храниться в памяти GPU в некоторых движках, поэтому canvas.toBlob может проходить через чтение GPU→CPU, что стоит ~30-100 мс на телефоне. Обрезка — это один вызов drawImage на каждый фрагмент: ctx.drawImage(img, sx, sy, sw, sh, dx, dy, dw, dh) — первые три пары задают исходный прямоугольник (sx, sy, sw, sh), а вторые три — целевой прямоугольник на целевом холсте. Для разбиения 3x3 фото 1920x1080 исходный прямоугольник каждого фрагмента — 640x360 начиная с (col*640, row*360). Целевой холст имеет размер точно по фрагменту (640x360), затем canvas.toBlob(blob => ..., 'image/png') запускает платформенный PNG-кодировщик. PNG выбран вместо JPEG, потому что фрагменты сетки — это обычно чистые прямоугольные обрезки с чётким текстом и UI-элементами, где важно безпотерьное кодирование; блоки DCT 8x8 в JPEG размазали бы границы. Пакетное скачивание использует URL.createObjectURL для каждого Blob, синтетический клик <a download> и revokeObjectURL после небольшой задержки (обычно 60-120 с, время жизни неиспользуемого Blob URL на платформе). Для 9 фрагментов это запускает 9 событий скачивания подряд; некоторые браузеры ограничивают множественные скачивания с одной вкладки, поэтому страница обычно разделяет их задержкой 50-200 мс между кликами через setTimeout. С точки зрения производительности, узкое место на телефоне обычно — PNG-кодировщик (libpng однопоточный на кодирование), а не drawImage; для 9 фрагментов 1080p ожидается 200-500 мс на среднем Android и 100-200 мс на десктопном Chromium.

• Конвейер: FileReader или URL.createObjectURL → элемент Image → HTMLCanvasElement → 9-аргументная обрезка drawImage → canvas.toBlob('image/png') → URL.createObjectURL + <a download>.
• drawImage(img, sx, sy, sw, sh, dx, dy, dw, dh) — перегрузка с 9 аргументами, которая обрезает исходный прямоугольник (sx,sy,sw,sh) в целевой прямоугольник (dx,dy,dw,dh); это единственный вызов API, выполняющий разбиение.
• Исходные изображения, отданные без CORS-заголовков, загрязняют холст — getImageData выбросил бы SecurityError, поэтому разделитель никогда не считывает массивы пикселей, а только копирует и кодирует.
• canvas.toBlob — асинхронный и неблокирующий (колбэк срабатывает на следующей микрозадаче) в отличие от устаревшего canvas.toDataURL, который синхронный и замораживает основной поток для больших изображений.
• Для разбиения N×M на 3×3 каждый фрагмент имеет размер (N/3) × (M/3); неделимые размеры дают остаток в 1 пиксель на правой/нижней границе, обрабатываемый через Math.floor с явным фрагментом-остатком при необходимости.
• PNG выбран вместо JPEG для фрагментов сетки, потому что каждый фрагмент — это прямоугольная обрезка с чёткими краями (текст, UI, схемы), где блоки DCT 8x8 размазали бы граничные линии.
• Пакетное скачивание использует URL.createObjectURL для каждого blob + клик <a download>; браузеры ограничивают множественные скачивания с одной вкладки, поэтому страница обычно разделяет клики на 50-200 мс и отзывает Blob URL после клика для освобождения памяти.
• Узкое производительности — платформенный PNG-кодировщик (libpng однопоточный на кодирование), а не drawImage; 9 фрагментов 1080p выполняются за ~200-500 мс на среднем мобильном и ~100-200 мс на десктопном Chromium.