Конвертер изображений в WebP

Image to WebP преобразует JPG, PNG, GIF, BMP и другие изображения в формат WebP. Файлы загружаются на сервис конвертации в WebP ToolAct, кодирование выполняется серверным libwebp (через libvips) и результат потоково возвращается в браузер. Временный загруженный файл удаляется с сервера сразу после преобразования — он не архивируется и не используется для обучения. WebP создавался для веба и часто даёт меньший размер файлов для фотографий и графики, поддерживая прозрачность, а также режимы с потерями и без потерь в зависимости от настроек. Это полезно для ускорения страниц, уменьшения загрузок, экономии трафика и современной оптимизации ассетов. Но WebP не всегда лучший выбор: очень старые клиенты, печатные процессы, требования к метаданным или редакторы могут предпочитать PNG, JPG или другой формат. После конвертации нужно вместе проверить резкость, прозрачность, цветопередачу и размер файла.

WebP — формат-контейнер от Google, построенный на трёх внутренних кодеках: VP8 для сжатия с потерями, VP8L для сжатия без потерь и VP8X как расширенный контейнер, добавляющий альфа-канал, анимацию, ICC-профиль и чанки EXIF. Lossy WebP использует внутрикадровое предсказание VP8 с 4-тайловым DCT, деблокингом в цикле и арифметическим кодированием; lossless WebP применяет преобразования цветового пространства и схему обратных ссылок LZ77 по остатку. По сравнению с JPEG при том же SSIM, lossy WebP в среднем на 25-35% меньше, а lossless WebP в среднем на 26% меньше PNG. Преобразование в этом инструменте происходит на стороне сервера. Браузер упаковывает каждое изображение в подписанную multipart-загрузку на эндпоинт /image/convert/webp ToolAct. Сервер передаёт байты в libvips, который декодирует источник (PNG, JPEG, GIF, BMP, TIFF) и передаёт буфер пикселей в libwebp — эталонный кодировщик Google. Ползунок качества напрямую соответствует параметру -q libwebp (0-100): значения ниже 100 выбирают путь lossy VP8 с субдискретизацией цветности 4:2:0 и 8-битным диапазоном на канал, а качество 100 переключается на путь lossless VP8L, который сохраняет каждый пиксель точно. Кодировщик записывает битовый поток в контейнер RIFF (Resource Interchange File Format) WebP, при необходимости добавляя расширенный чанк VP8X для альфы или ICC, а результат потоково возвращается как тело ответа. Временный загруженный файл удаляется с сервера сразу после того, как ответ записан — он не архивируется и не используется для обучения. Поддержка сейчас достаточно широка, чтобы выступать заменой JPEG: Chrome 32+, Edge 18+, Firefox 65+ и Safari 14+ содержат декодер. Оставшиеся граничные случаи предсказуемы. Lossy WebP принудительно обнуляет полностью прозрачные пиксели до RGBA 0,0,0,0, поскольку 4:2:0 цветность не может передать частичную альфу с полной точностью. Качество ниже ~70 начинает давать постеризацию на однотонных участках неба и обесцвечивание красных и жёлтых тонов в фирменных цветах, поэтому продуктовые hero-снимки обычно живут в диапазоне 80-85. Анимированный WebP может быть создан через mux-инструменты libwebp, но типичный сценарий — статические изображения, поэтому конвертация анимированных GIF требует явного указания кодировщику сохранить все кадры.

• Контейнер: VP8 lossy, VP8L lossless, VP8X расширенный (альфа, анимация, ICC, EXIF); три формата используют общую обёртку RIFF.
• Серверный конвейер: libvips декодирует источник, libwebp кодирует выход. Ползунок качества соответствует параметру -q libwebp; quality=100 выбирает безпотерьный путь VP8L, меньшие значения — lossy VP8 с цветностью 4:2:0.
• Соотношение размеров: примерно на 25-35% меньше JPEG при том же SSIM, примерно на 26% меньше PNG для lossless с прозрачностью.
• Обработка альфа-канала: lossy WebP приводит полностью прозрачные пиксели к RGBA 0,0,0,0; для сохранения настоящей альфы выберите режим без потерь или используйте PNG для иконок.
• Базовая линия браузеров: Chrome 32+, Edge 18+, Firefox 65+, Safari 14+/iOS 14+; старые заблокированные устройства без возможности обновления по-прежнему нуждаются в PNG/JPG-фолбэке.
• Жизненный цикл преобразования: каждый загруженный файл существует только на время кодирования libwebp и потоковой отправки результата обратно. Независимо от успеха или неудачи, временный файл удаляется при закрытии ответа.