Бележки от екипа за майсторството, форматите и малките решения зад добрия резултат.
Защо WebP не се поддържа повсеместно в настолните приложения
WebP бе пуснат от Google през 2010, но възприемането му от настолния софтуер силно изостана зад поддръжката в браузърите. Браузърите възприеха WebP рано, защото управляват собствените си машини за рендиране, а Google активно оптимизира поддръжката на WebP в Chrome като конкурентно предимство. Настолните приложения възприемат нов формат изображение по-бавно, понеже всяко приложение поддържа собствен слой за разчитане и поддръжката на нов формат изисква проверка спрямо дълга опашка от гранични случаи. Adobe Photoshop, който ползва по-голямата част от професионалните фотографи и дизайнери, добави вградена поддръжка на WebP едва във версия 23.2 в края на 2022. Приложенията на Microsoft Office все още боравят с WebP непоследователно през различните платформи към 2026. Печатарският RIP софтуер и повечето стари инструменти за архивиране изобщо не го възприеха. Практическата последица е, че файл, който се показва безупречно в браузър, може да бъде напълно отказан от софтуера, от който потребителят се нуждае, а преобразуването в PNG е надеждното заобикаляне.
Как WebP постига предимството си в компресията пред PNG
PNG ползва компресия DEFLATE, общ алгоритъм без загуби от 1996. Той прилага набор от обратими филтри по редовете на сканиране преди компресията и кодира резултата с поток zlib. Това е ефективно, но е създадено, преди изследванията в машинното обучение и видеокодеците да дадат по-добри техники. Режимът със загуби на WebP ползва блоково преобразуване, произлязло от видеокомпресията VP8, прилагайки вътрешнокадрово предсказване и дискретно косинусово преобразуване върху макроблокове 16x16. Режимът без загуби на WebP ползва пространствено предсказване, цветово преобразуване и етап на кодиране LZ77, който е структурно по-ефективен от DEFLATE за типично съдържание на изображение. Публикуваните измервания на Google показват WebP без загуби с около 26 процента по-малък от PNG върху набор от стандартни тестови изображения, и WebP със загуби с алфа около три пъти по-малък от PNG при съпоставимо визуално качество. Посоката от PNG към WebP оползотворява тези печалби, посоката от WebP към PNG ги обръща, оттам и по-големият резултат.
Измерени примери за нарастване на размера на файла
Измерено на Chrome 148, настолен Linux, чрез системния път за запис на PNG, приложен върху разчетени WebP входове. Малка графика от векторен тип при 400x300 пиксела, запазена като WebP с качество 80, се разчита и записва наново като PNG за приблизително 15 до 25 ms с типично нарастване на размера от 20 до 30 процента. Фотографски WebP при 1024x768, около малък размер, се разчита и записва наново в PNG за под 100 ms с типично нарастване от 3 до 5 пъти. Голям фотографски WebP при 3840x2160, около по-голям размер, се записва в PNG за около 1,2 секунди с нарастване от 5 до 10 пъти според сложността на сцената. Практическата горна граница е приблизително снимка WebP голяма, която става PNG с многократно по-голям размер. Тези числа отразяват разликата в ефективността на компресията между двата формата и нарастват линейно с броя на пикселите.
Алфа прозрачност при прехода нататък и обратно
8-битовият алфа канал в WebP и PNG ползва един и същ диапазон от стойности, където 0 е напълно прозрачно, а 255 напълно плътно. Когато браузърът разчете WebP с алфа, той създава буфер от пиксели със стойности RGBA, чийто компонент A отразява оригиналните алфа данни. Когато този буфер се запише наново като PNG, записът на PNG поставя стойностите A директно в алфа канала на PNG. Не се случва стъпка на смесване, не се прилага цвят на фона и никакъв страничен ефект от предумножаване не променя стойностите на пикселите. Резултатът е пренос на алфа канала без загуби, при който стойността на непрозрачност на всеки пиксел в PNG съвпада с тази, която WebP е съхранил. За изображения с фино изглаждане по ръбовете всяка междинна алфа стойност, например пиксел при 40 процента непрозрачност на ръба на текст, преминава прехода непокътната. Тази вярност прави PNG правилния избор пред JPG, когато приложението по предназначение трябва да покаже изображението върху няколко фона.
Поведение на EXIF и метаданните
Процесът на повторен запис маха метаданните EXIF, IPTC и XMP от изходния PNG. WebP файловете могат да носят EXIF данни, вградени в техния блок с метаданни, и тези данни се губят, когато браузърът разчете и запише наново изображението. Цветовите профили ICC следват различен път, при който Chrome и Safari запазват етикета на профила sRGB ICC в PNG след разчитане на WebP, а Firefox маха всички метаданни, включително профила ICC. Практическата последица е изход, безопасен за sRGB, във всички браузъри, но всеки профил с широка гама, вграден в изходния WebP, не оцелява във Firefox. За професионални фотографски процеси, които разчитат на преходи с ICC етикет, ползвайте инструмент за преобразуване, който се съобразява с метаданните. За обичайна обработка на уеб изображения махането на метаданните обикновено е приемливо и има малката полза леко да намали размера на изходния файл.
Проверка на поверителността на практика
Твърдението, че никакви данни на файла не напускат браузъра, може да се провери без никакъв специален инструмент. Отворете браузъра си, отидете на страницата webp-to-png и след това отворете инструментите за разработчици на браузъра с F12 или менюто с десен бутон. Минете на раздела Network, изчистете наличните заявки и пуснете преобразуване, като пуснете WebP файл. Филтрирайте списъка със заявки по Fetch, XHR или All. Списъкът показва нула изходящи заявки, съдържащи данни на изображение по време на записа. Единствените мрежови заявки са ресурсите за първоначалното зареждане на страницата и стандартните аналитични сигнали, които записват само показвания на страницата и данни за производителност по Core Web Vitals, без никакво съдържание на изображение. Всеки голям отдалечен преобразувател от WebP към PNG създава поне една заявка POST за качване и една GET за изтегляне на преобразуване, и двете записани на сървъра. Архитектурата на устройството означава, че тези записи в дневника не съществуват, което е същественото различие за потребителите, преобразуващи файлове с чувствително съдържание.
