Инструмент сжатия изображений

Онлайн-сжатие изображений уменьшает размер файлов, чтобы страницы загружались быстрее, загрузки проходили ограничения по весу, а пересылка тратила меньше трафика. Файлы загружаются на сервис преобразования ToolAct, обрабатываются серверными библиотеками (libvips / mozjpeg / libwebp), и сжатый результат скачивается обратно. Оригиналы удаляются с сервера сразу после преобразования — они не архивируются и не используются для обучения. В зависимости от формата сжатие может менять качество, метаданные, цветовую информацию и параметры кодирования; фотография становится значительно легче, но при обычном просмотре потери могут быть почти незаметны. Инструмент подходит для блогов, карточек товаров, соцсетей, вложений в поддержку и черновых материалов. Для печати, архива или проверки мелких деталей результат нужно внимательно оценивать после обработки. Не загружайте фото с персональными данными, внутренние документы или другие конфиденциальные материалы.

Сжатие изображений чётко разделяется по границе с потерями / без потерь. Форматы с потерями (JPEG, WebP lossy) используют ограничения человеческого восприятия: глаз гораздо менее чувствителен к высокочастотной цветности, чем к яркости, поэтому кодировщики отбрасывают мелкие цветовые детали в блоках 8x8 или 16x16, не замечая этого большинство зрителей. JPEG использует этот путь на основе DCT с 1992 года; современные альтернативы — mozjpeg (~5-10% меньше libjpeg при том же SSIM, медленнее кодирует), libwebp (видеокодек Google VP8/VP8L, 2010) и AVIF (Alliance for Open Media, AV1 intra, 2019). Форматы без потерь (PNG, GIF, WebP lossless) сжимают байты через энтропийное кодирование — скользящее окно LZ77 плюс кодирование Хаффмана или арифметическое кодирование — и никогда не изменяют ни одного пикселя. Конвейер на этой странице полностью серверный. Браузер упаковывает каждое изображение в подписанную multipart-загрузку на эндпоинт сжатия ToolAct (/image/compress). Сервер проверяет запрос, передаёт байты в libvips — высокопроизводительную библиотеку обработки изображений с низким потреблением памяти, — которая декодирует источник, при необходимости масштабирует длинную сторону и заново кодирует через mozjpeg для JPEG, libwebp для WebP или libpng/oxipng для PNG. Закодированные байты потоково отправляются обратно в браузер как ответ на загрузку, а временный загруженный файл удаляется с диска сразу после того, как ответ записан. Нет архивирования, нет обучающего конвейера и нет ручной проверки содержимого. Квантование JPEG — сердце формата: качество 90 сохраняет почти все DCT-коэффициенты, 75 начинает отбрасывать среднечастотные (видно на красном тексте поверх жёлтого), 50 — очевидная зона JPEG, где блочные артефакты появляются на плавных градиентах, а 25 даёт видимую постеризацию на лицах. Сжатие PNG основано на zlib (DEFLATE) уровнях 0-9; уровень 1 быстрый, но даёт большие файлы, уровень 9 выжимает последние байты из однотонных баннеров ценой нагрузки на CPU. Метаданные EXIF, ICC-профили, XMP и IPTC по умолчанию удаляются, так как кодировщик пересобирает заголовок файла с нуля — реальная причина, почему фото с камеры 200 КБ может стать загрузкой 60 КБ при том же разрешении, и причина, по которой метаданные происхождения и управления цветом следует сохранять отдельно, если они важны.

• libvips (John Cupitt, LGPL) — серверный движок обработки изображений: потоковый, управляемый по требованию конвейер, который держит потребление памяти низким даже на входах в 100 МП и лежит в основе Sharp, делегата vips IM7 ImageMagick и эндпоинтов конвертации этого инструмента.
• mozjpeg (Mozilla, форк libjpeg-turbo с улучшенными психовизуальными моделями) даёт файлы на 5-10% меньше стандартного libjpeg при том же SSIM, но кодирует примерно в 3-5 раз медленнее — компромисс, стоящий за большинством веб-настроек JPEG качества 80-85 с 2017 года.
• PNG — это LZ77 + Хаффман: кодировщик находит повторяющиеся последовательности байтов до 32 КБ назад (скользящее окно), выдаёт пары (расстояние, длина), затем кодирует результат по Хаффману. WebP lossless (VP8L) использует похожую идею плюс патчи Local Palette, обычно обгоняя PNG на 20-26% на тех же пикселях RGBA.
• libwebp — эталонный кодировщик/декодировщик WebP от Google; на серверной стороне он используется для записи либо lossy VP8 (качество 0-100, цветность 4:2:0 по умолчанию), либо lossless VP8L (качество управляет усилием сжатия, никогда — точностью пикселей). Декодирование WebP широко доступно (Chrome 32+ 2014, Firefox 65+ 2019, Safari 14+ 2020), поэтому сконвертированный WebP безопасен почти для каждого современного браузера.
• Субдискретизация цветности 4:2:0 по умолчанию в JPEG (два семплы цветности на 4 яркости) — вот почему красный текст на жёлтом фоне выглядит размытым при качестве 60: детали цветности отбрасываются раньше деталей яркости. Переключайтесь на 4:4:4 (без субдискретизации) для скриншотов и UI-захватов, где важны края текста.
• EXIF (формат обмена изображениями, JEITA CP-3451) и ICC-профили цвета по умолчанию удаляются при перекодировании, поэтому JPEG с iPhone на 6.3 МБ часто уменьшается до 1.8 МБ после обработки на сервере. Вот почему потребительские фотографы видят уменьшение файлов после каждого цикла через веб-инструмент. Практический подводный камень пакетной обработки: когда папка смешивает маленькие иконки (до 200x200 px, PNG с альфа-каналом), скриншоты UI с однотонными цветами (PNG, очень высокая сжимаемость) и фотографии с телефона (JPEG, в основном шумоподобный контент), единый ползунок качества не подходит для всех трёх. Иконки требуют безпотерьного PNG или WebP lossless; скриншоты — JPEG 4:4:4 при качестве 85-90; фото — lossy WebP при качестве 75-80. Сжатие всех при качестве 60 экономит байты, но вносит красную кайму на иконках, кольцевые артефакты на скриншотах и полосатость на фото. Более умный конвейер прогоняет каждую категорию через разный кодировщик, поэтому интерфейс позволяет переопределить целевой формат для каждого файла, даже когда пользователь выбирает один формат по умолчанию. В перспективе JPEG XL (ISO/IEC 18181, 2022) — формат, который Google и Cloudflare продвигают с 2020 года как преемник JPEG: ~20% меньше при том же качестве, полный режим без потерь, без субдискретизации цветности, и прогрессивное декодирование, удобное для медленных сетей. Поддержка браузерами частичная (Chrome отключил JPEG XL в Chrome 110), поэтому практический путь миграции на данный момент — WebP при качестве 80, AVIF для ключевых ресурсов, которым нужны дополнительные байты, и JPEG как fallback для старого Safari или почтовых клиентов. Страница раскрывает качество, максимальный размер и целевой формат как три значимых рычага; всё остальное — детали реализации.
• Жизненный цикл серверной конвертации: каждый загруженный файл существует только на время декодирования libvips и повторного кодирования с потоковой отправкой результата обратно. Независимо от успеха или неудачи, временный файл удаляется при закрытии ответа. JPEG в 24 МП, который заблокировал бы основной поток рендерера на 200-500 мс, обрабатывается полностью вне устройства пользователя.
• Миграция: AVIF — формат следующего поколения (Alliance for Open Media, AV1 intra, поддержка 10/12-бит, альфа-канал, анимация). Серверное кодирование AVIF через libavif/aom всё ещё в 10-30 раз медленнее WebP, поэтому большинство страниц остаётся на WebP при качестве 80 и резервирует AVIF для ключевых фото, которым выгодна дополнительная экономия 15-20% байтов.