WebP

O que é WebP?

WebP é um formato de arquivo de imagem comum capaz de salvar imagens comprimidas sem perda (lossless) e com transparência, assim como PNG, de salvar imagens comprimidas com perda (lossy), assim como JPG, de salvar imagens com perda e transparentes, algo que esses dois outros formatos não são capazes de fazer, e até de salvar imagens animadas sem as limitações de profundidade de cor e paleta que o formato GIF teria.

O formato WebP é um formato novo, lançado junto do formato WebM, que seria voltado a vídeo. Ambos formatos foram desenvolvidos para uso na web, suportados primeiramente por navegadores de Internet como o Chrome, eis seus nomes: Web Picture (picture significando "imagem") e Web Movie (movie significando "filme").

WebP promete tamanhos de arquivo menores com a mesma qualidade que formatos tradicionais, o que diminuiria os custos para armazenar e transferir imagens na Internet. Veja abaixo para minha opinião sobre isso. Acreditando nessa promessa, muitos websites passaram a converter suas imagens dos formatos JPG para WebP.

Por um tempo, esses websites seriam obrigados a manter duas versões das imagens, já que nem todos os navegadores suportavam esse novo formato. Originalmente, não havia como um website informar que uma imagem estaria disponível em múltiplos formatos e permitir que o navegador escolhesse o formato que ele suporta. Isso também ocorreu com o formato SVG, que também não era suportado pela maioria dos navegadores. Passou a existir uma solução para esse tipo de problema: o que antes era um simples <img> no código HTML das páginas web passou a virar um complexo <picture><source><img></picture>. Naturalmente, esse novo código também não era suportado pela maioria dos navegadores na sua introdução. Porém, quando um navegador encontra código que não suporta, ele deve simplesmente ignorar o código. Com isso bastaria colocar a imagem JPG na tag <img> que é suportada, e o formatos de imagem não suportados na nova tag também-não-suportada <source>. Feito isso, a web passou a usar o novo formato.

Embora WebP seja suportado por navegadores, o mesmo não pode ser dito sobre outros aplicativos que trabalham com imagem; a Internet ficando cheia de usuários reclamando que imagens baixadas de websites são WebP e não abrem em nenhum aplicativo por um bom tempo. Qualquer aplicativo criado antes do WebP ser inventado não suportaria o formato sem ser atualizado, o que significa que muitos aplicativos que não são mais atualizados nunca suportarão o formato. O WebP também não é suportado por muitos aplicativos que são atualizados. O motivo disso é que, para decodificar um arquivo WebP em dados de pixels, é necessário um programa decodificador. Há diversas maneiras de se implementar um mesmo algoritmo, algumas mais rápidas, algumas que consomem menos memória, mas quando se trata de decodificadores de imagem, faria mais sentido usar o mesmo decodificador que todo mundo está usando, assim um arquivo WebP que abre em um programa abriria em todos os programas que suportam WebP, pois todos estariam usando o mesmo subprogama decodificador. Para isso, o algoritmo é compartilhado em um formato chamado de biblioteca de código (seriam os arquivos .dll no Windows). No caso do WebP, a biblioteca padrão é o libwebp (library significa "biblioteca"). De primeira vista a solução parece ser simples: basta incluir esse libwebp no aplicativo e pronto. Realmente, é assim mesmo, porém, existem camadas. Esse libwebp só pode ser usado diretamente em um programa escrito na linguagem de programação C. A maioria dos aplicativos não é programada em C, pois C é extremamente inconveniente para qualquer coisa mais complexa que uma biblioteca que só faz uma coisa. Alguns aplicativos são programados em C++, que pode usar código C facilmente, porém até isso é inconveniente para o desenvolvimento moderno. Para usar uma biblioteca como libwebp em Java, por exemplo, seria necessário alguém que sabe tanto de C quando Java criar uma biblioteca em Java que traduza os comandos para a biblioteca em C. Isso se chama de uma binding (vínculo). Então se você cria um aplicativo em Java, você depende de alguém criar esse vínculo para você. Porém, isso só se aplica se você for capaz de programar imagens diretamente. Na maioria dos casos, um aplicativo não usa os formatos de imagens diretamente, mas sim depende de uma biblioteca que provê uma interface comum para todo tipo de formato (chamado de um wrapper, "embalador"), e outras operações comuns com imagens (e.g. redimensionar). O que significa que o desenvolvedor do aplicativo não usa libpng e libjpeg para abrir imagens PNG e JPEG, ele usa uma biblioteca que usa essas outras bibliotecas—e.g. em Python uma biblioteca comum seria PIL (Python Imaging Library), sucedida pela Pillow, em Javascript temos a biblioteca Sharp, que poderia ser usado por aplicativos baseados em Electron—e, possivelmente, ele não teria o conhecimento necessário para converter os dados vindos da libwebp para serem usados na biblioteca de imagem que está usando, o que significa que ele precisa esperar que alguém que tenha conhecimento de Python e de C, e use Pillow (ou Javascript e C e use Sharp) adicionar o formato libwebp para a biblioteca Pillow ou Sharp para poder usar esse novo formato.

O WebP é Melhor para Imagens que o JPG?

Pessoalmente, eu não recomendaria usar WebP em vez de JPG para fotografia que deseja disponibilizar em boa qualidade.

É verdade que WebP gera arquivos menores com qualidades comparáveis a JPG, entretanto, isso parece ser do ponto de vista de economizar bytes. Isto é, ao gerar pequenos thumbnails a partir de imagens originais programaticamente, o WebP seria sempre melhor, pois sempre gera thumbnails com tamanhos de arquivo menores. O mesmo pode ser dito para qualquer tipo de imagem feita para pré-visualização, o que seria a grande parte das imagens encontradas em feeds de mídias sociais. Em websites de notícias encontramos algo parecido: o propósito do website não é distribuir imagens, mas sim notícias, a fotografia é apenas algo embutido no artigo.

Em todos esses casos, onde o propósito da imagem é apenas ser embutida em uma página, o WebP economiza dados, e não há muita perda.

Entretanto, se você estiver distribuindo uma imagem para ser baixada, o WebP para de fazer sentido. Por exemplo, websites que distribuem papéis de parede ou portfólios contendo fotografia de boa qualidade. Não digo de "alta" qualidade. Digo simplesmente de "boa" qualidade. Há muitos websites onde faz sentido que uma imagem "embutida" seja baixada pelo usuário, e todos queremos que essa imagem seja da melhor qualidade possível. Um exemplo seria um website que contém páginas escaneadas de uma revista antiga. Alguém pode quere salvá-las para preservá-las. Mesmo que essas imagens não sejam de alta qualidade, é possível que elas sejam as únicas imagens daquele revista que você pode encontrar na Internet. Quando publicamos algo na Internet, o que é publicado pode ficar online por anos, decades, e ser acessado por alguém olhando o passado. Seria uma pena deixar para esse visitante do futuro algo inferior só para salvar uma quantidade insignificante de kilobytes.

Um aviso: NUNCA abra um arquivo JPG criado por uma câmera e salve como WebP e então delete o arquivo JPG original. O arquivo WebP sempre será pior que o JPG nesse caso. Se salvo sem perda, terá tamanho maior, se salvo com perda, terá qualidade pior.

O WebP é Melhor para Imagens que o PNG?

Em geral, sim. A compreensão sem perda do WebP é geralmente mais eficiente que PNG, e como dados não são perdidos, não há problemas com a qualidade. O único problema seria a compatibilidade: todo tipo de aplicativo suporta PNG, mas nem todos suportariam WebP.

PNG possui funções que WebP não possui: é possível salvar PNG com 8bpp, tendo uma paleta de cores como GIF, também conhecido como PNG-8. É possível que quando salvo dessa maneira específica um imagem em PNG pode ser menor que a mesma imagem salva como WebP, porém isso encarreta perda de qualidade se a imagem possui mais de 256 cores, o que seria o caso para praticamente tudo exceto pequenos ícones.

O WebP é Melhor que GIF?

Mais uma vez, o WebP não é capaz de produzir imagens 8 bpp da forma que o GIF é capaz. Há mais suporte para GIF que para WebP, embora hoje em dia todo mundo diga "GIF" para se referir ao formato WebM. WebP é capaz de salvar animações, algo que só o GIF era capaz de fazer por muito tempo, e até animações semi-transparentes, algo que o GIF não é capaz de fazer, pois sua transparência é limitada a uma única cor.

É difícil que exista um caso de uso onde GIF seria melhor que WebP. GIF é um formato extremamente antigo, que deveria ter sido completamente substituído pelo PNG nos anos 90, mas não foi só por que o GIF suportava animações e o PNG não as suportava nativamente.

Uma questão seria se devemos converter um arquivo GIF para WebP sem perda. Nesse caso, é possível que o GIF seja superior em seu formato original. Isso por que embora GIF seja limitado a 8bpp (256 cores), alguns GIFs podem ter muito menos cores que isso. Por exemplo, animações em preto e branco (2 cores) são 1bpp. WebP sendo 24bpp (16777216 cores), seu algoritmo de compreensão teria de tornar 24bpp descomprimidos em 0.9bpp comprimidos (isto é, cada bit do arquivo conteria os dados de mais de 1 pixel da imagem em média). Considerando que a maioria das imagens seriam fotografia, não creio que WebP seja otimizado para esse tipo de caso.