Análise dos prós e contras da tecnologia WebP (2021)

 (eng.aurelienpierre.com)
2 pontos por GN⁺ 2023-12-17 | 1 comentários | Compartilhar no WhatsApp
  • Com o suporte a WebP pelo WordPress e pelos principais navegadores, ficou mais fácil migrar bibliotecas de fotos, mas em fotografias reais danos como posterização e ringing aparecem mais do que a redução do tamanho dos arquivos
  • O Google e vários plugins do WordPress afirmam que WebP é menor que JPEG e que lossy 80 é suficiente, mas converter JPEGs existentes novamente para WebP pode acumular compressão com perdas
  • Em imagens nas quais gradientes suaves são importantes, como retratos de estúdio e scans de filme, WebP 95~96 apresentou resultados semelhantes ou mais pesados que JPEG 85+ruído
  • Comparações de SSIM médio e tamanho médio de arquivo não garantem a cobertura dos piores casos de que fotógrafos precisam; em sites onde é difícil ajustar a qualidade imagem por imagem, a estabilidade é mais importante
  • Para sites em que a qualidade da imagem é importante, é mais realista manter JPEG 85~90, adicionar dithering ou ruído fino, evitar recodificar JPEGs existentes em WebP e usar CDN, imagens responsivas e lazy loading

Expectativas com a adoção do WebP e problemas reais

  • Com o WordPress aceitando uploads com o tipo MIME image/webp e os principais navegadores passando a exibir WebP depois de setembro de 2020, ficou mais fácil migrar bibliotecas de fotos para WebP
  • O WebP parece uma opção atraente por comparações que indicam 15% menos tamanho que JPEG na mesma qualidade e pelos números do Google de 25% a 34% menos tamanho
  • Há muitos plugins no WordPress que convertem bibliotecas de mídia existentes para WebP, e boa parte deles funciona no modelo SaaS, fazendo a conversão em servidores externos
  • Alguns plugins e documentos técnicos dizem que qualidade WebP acima de lossy 80 é desnecessária para a maioria das fotos, mas exemplos com logotipos não representam suficientemente os problemas do trabalho fotográfico real

Danos ao recomprimir JPEGs existentes para WebP

  • Depois de converter em lote a mídia do WordPress com qualidade lossy 80, surgiram anéis posterizados no fundo
  • A imagem problemática era um scan de médio formato 6×7 cm, fotografado em filme Ilford Delta 400 com uma Mamiya RB 67, partindo de um scan original de 16 bits
  • Os grãos de prata do Delta 400 funcionam como uma espécie de dithering natural, o que ajuda a evitar posterização em áreas suaves, mas após a conversão para WebP o gradiente se quebrou em degraus
  • O JPEG original em qualidade 85 também não era perfeitamente limpo, mas era melhor que a versão convertida para WebP, e o impacto de empilhar mais uma compressão com perdas em WebP sobre um JPEG já comprimido com perdas foi grande
  • O Google Page Speed Insights e vários plugins recomendam ou facilitam esse fluxo de recodificação, mas a perda real de qualidade não é segura

Experimentos comparativos em fotos reais

  • Mesmo ao codificar fotos RAW diretamente pelo darktable, em uma condição de apenas uma compressão, os pontos fracos do WebP foram confirmados
  • A imagem de teste é um headshot real de estúdio, em que iluminação suave e gradiente de fundo são importantes
  • Ao salvar JPEG e WebP ambos com qualidade 90 e aplicar Floyd-Steinberg dithering de 8 bits, o resultado foi:
    • JPEG 85 e WebP 90 foram ambos avaliados como falhos
    • O WebP pareceu pior porque os anéis de posterização tinham contraste mais alto
    • WebP 90 ainda manteve o problema, mesmo sendo uma qualidade 10 pontos acima do valor recomendado lossy 80
    • JPEG 90 pareceu aceitável, mas o arquivo era maior
  • Ao salvar WebP como sem perdas, a qualidade ficou limpa, mas o tamanho do arquivo não foi satisfatório; JPEG 90 era difícil de distinguir com cerca de um terço desse tamanho, e JPEG 95 parecia semelhante com pouco mais da metade do tamanho
  • Em um teste que adicionou ruído aleatório de -48 dB PSNR em vez de Floyd-Steinberg dithering, o WebP continuou mais vulnerável à posterização
    • A qualidade WebP que ficava suavizada de forma semelhante a JPEG 85+ruído estava entre 95 e 96
    • Nessa condição, o WebP ficou 39% mais pesado que JPEG 85+ruído e também 30% mais pesado que JPEG 90+Floyd-Steinberg dithering
    • O resultado em WebP ainda manteve um ringing fraco

A lacuna entre métricas médias e qualidade fotográfica

  • A avaliação da superioridade do WebP depende fortemente do SSIM médio e do tamanho médio em bits em datasets de imagens
  • Valores médios não garantem a estabilidade de saída exigida por fotógrafos em portfólios na web
    • Um portfólio fotográfico não é um domínio em que o backend de compressão possa falhar arbitrariamente
    • Ajustar finamente a qualidade WebP para cada imagem consome muito tempo, e considera-se que esse método também é difícil no WordPress
  • SSIM é uma métrica de similaridade de imagens baseada em média, variância e covariância, por isso não reflete suficientemente métricas perceptuais reais e é controversa
  • Em danos de compressão, não importa apenas a magnitude do desvio numérico, mas também a natureza dos artefatos
    • Ruído aleatório pode ser tolerável até certo ponto
    • Manchas com padrão ou gradientes em degraus estragam muito mais a foto

Cenas em que o WebP é especialmente fraco

  • No trabalho fotográfico, as cenas mais difíceis muitas vezes envolvem gradientes suaves, não detalhes nítidos
  • Em situações em que uma luz próxima a uma fonte pontual incide sobre uma parede para criar um fundo natural, o fundo precisa ter textura suficiente sem desviar a atenção do assunto
  • Exemplos de compressão WebP frequentemente mostram cenas nítidas, com grande profundidade de campo e muitos detalhes de alta frequência, mas essas cenas têm baixa probabilidade de posterização e não expõem bem as fraquezas do algoritmo
  • Falta de nitidez não necessariamente arruína uma foto, mas uma vinheta suave se quebrar em degraus é um dano difícil de aceitar

Design do formato e problemas de cor

  • WebP usa formato RGB ou RGBalpha, portanto não permite salvar imagens em preto e branco como imagens em tons de cinza de canal único
  • A posterização observada no teste piorou com anéis magenta e verdes, interpretados como deslocamentos de cor causados por subamostragem de croma
  • Se fosse possível salvar um formato puramente preto e branco em canal único, seria possível não criar deslocamentos adicionais de croma
  • AVIF resolveu essa parte, mas considera-se que levará pelo menos 10 anos até que isso se torne amplamente viável na prática técnica

Medidas para preservar a qualidade da imagem

  • Para sites em que a imagem é importante, especialmente portfólios de artistas visuais, considera-se melhor manter JPEG qualidade 90 ou, no mínimo, 85
  • Para proteger gradientes suaves, recomenda-se sempre adicionar dithering ou ruído muito leve à imagem
  • É melhor não converter JPEGs existentes para WebP; a exceção é apenas quando danos no nível dos exemplos anteriores forem aceitáveis
  • Para aumentar a velocidade de carregamento e a responsividade percebida, é mais seguro usar CDN, tamanhos de imagem responsivos e lazy loading de imagens do que converter formatos
  • O modelo SaaS que converte em servidores externos gera custos, não revela os coeficientes reais de qualidade e pode causar erros de conexão HTTP em ambientes WordPress reforçados por plugins de segurança, entre outros casos
  • É melhor executar ImageMagick ou GraphicsMagick diretamente no servidor, e recomenda-se uma abordagem que use diretamente o programa do servidor, não uma interface PHP
  • Se desenvolvedores técnicos e projetistas de algoritmos de imagem impuserem escolhas de formato apenas com métricas médias, podem causar perda de tempo e dinheiro para artistas reais

Leituras relacionadas

1 comentários

 
GN⁺ 2023-12-17
Opiniões no Hacker News

  • Vi o mesmo problema no WebP, então voltei em grande parte para JPG/PNG; uso jpg para fotos e png para imagens de UI.
    O verdadeiro problema parece ser que muita gente não percebe a diferença, talvez porque, nos últimos 10 anos, os monitores de desktop tenham ficado numa zona esquecida, sem inovação. Metade das pessoas aqui provavelmente está vendo as imagens de exemplo em um LCD 1920x1080 de por volta de 2012, e isso também faz parte do problema.
    Curiosamente, telas pequenas como as de celulares e telas grandes como TVs 4K passaram a ter excelente densidade de pixels em relação à distância de visualização, mas painéis de 20 a 40 polegadas continuam presos ao nível de meados dos anos 2000.
    Também acho que teria sido melhor se o autor tivesse usado uma foto de exemplo com fundo claro ou mudado o fundo do artigo para preto. Imagens pretas sobre fundo branco dificultam ver o problema, porque os olhos têm dificuldade para se adaptar; em um fundo escuro, a diferença fica muito mais fácil de perceber.

    • Mesmo em dois monitores da década de 2010, os artefatos de compressão são bem visíveis. Um é um monitor IPS de 30 polegadas 2560x1600, bastante bom para a época, e o outro é uma TV TN 1080p básica de 27 polegadas.
      Por isso, é difícil ver a qualidade da tela como o problema central. Pode ser uma questão de driver ou de filtros de pós-processamento, ou simplesmente nem todo mundo tem olho para esse tipo de coisa.
      Se você se interessa por processamento de imagens, pela experiência acaba percebendo esses detalhes. O autor claramente tem mais experiência do que eu, e enxergar esse tipo de detalhe talvez faça parte do trabalho dele. É bem provável que ele consiga identificar o problema até em um monitor ruim e dizer exatamente de que maneira esse monitor é ruim.
    • Mesmo em um monitor 4K de 27 polegadas, é muito difícil notar a diferença, e nem tenho certeza se realmente a vejo.
      Os exemplos são ruins. Se quer mostrar algo, deveria ampliar uma captura de tela para mostrar os artefatos.
    • No lado da Apple, laptops e monitores de desktop evoluíram bem, com alto PPI, brilho e precisão de cores quase como padrão há cerca de 10 anos. Só que são caros e, no PC, como a maioria não liga para isso, é uma das primeiras áreas a ser cortada.
    • Concordo em relação ao JPG, mas, se usar WebP sem perdas em vez de PNG, os pixels não ficam iguais e o arquivo apenas cerca de 30% menor que o PNG correspondente? Mesmo comparando com PNGs já fortemente otimizados com zopfli/optipng e afins, ele fica cerca de 15% menor.
      Ao trocar PNG por WebP, o “lossless” de “lossless WebP” não é realmente sem perdas?
      Como referência, se você converter um PNG para WebP sem perdas, depois descompactá-lo de volta para PNG e converter esse PNG novamente para WebP, obtém exatamente o mesmo arquivo WebP sem perdas. Seja codificando diretamente a partir do PNG, seja a partir do mesmo PNG “crushed” por um otimizador de PNG, o WebP resultante é igual.
    • Aqui uso uma tela IPS 4K de 27 polegadas, e, para ver a diferença de que o autor fala, preciso apertar os olhos ou dar zoom.
      É bom que existam pessoas que realmente se importem com o melhor resultado possível, mas acho que a maioria nem vai perceber nem se importar.

  • Abri as duas primeiras fotos em abas separadas e alternando rapidamente entre elas, e não vi nenhuma diferença. Testei em dois monitores diferentes, no Chrome e no Firefox, e as últimas fotos do homem também pareciam iguais
    Correção: na última comparação, o WebP tinha sido incluído duas vezes e o link estava errado. O jpg está aqui, mas mesmo assim não vejo diferença
    https://eng.aurelienpierre.com/wp-content/uploads/sites/8/20...

  • Na minha opinião, a pior e mais fácil de distinguir desvantagem do WebP é a subamostragem de croma 4:2:0 obrigatória. Em muitas imagens com cores vivas, a perda de cor e de brilho fica evidente mesmo sem um olhar profissional
    Na comparação [1], é nítido que o balão no canto superior direito perdeu o vermelho vivo; na comparação [2], a arte de neon azul-claro no centro perdeu brilho
    [1] https://storage.googleapis.com/demos.webmproject.org/webp/cm...
    [2] https://storage.googleapis.com/demos.webmproject.org/webp/cm...

    • Não quero alimentar outra discussão, mas não consigo perceber nenhuma diferença nos dois exemplos linkados. Ajudaria se aquele site pelo menos permitisse arrastar uma barra vertical de comparação. Vi na tela de um iPhone 14
    • Obrigado pelos links; aos meus olhos dá para detectar, mas parece desprezível para uso em sites. E quanto à saturação?
      Fico curioso para saber por que este comando, ao converter de jpg > webp, gera um azul-claro desbotado, enquanto as outras cores saem razoavelmente bem
      cwebp -pass 10 -m 6 -nostrong -sharp_yuv -quiet -q 60 -sharpness 2 $1 -o

  • Este texto não abordou o maior problema que percebo no WebP. A inconveniência desse formato fora do navegador supera a pequena economia de tamanho
    Existem formatos melhores. Há formatos inspirados em codecs de vídeo, como os que podem vir de HEIF, AVIF e H.266, ou também JPEG XL; o WebP parece um meio-termo sem vantagens suficientes

    • Existe a dor de clicar com o botão direito, salvar como e... ah, é WebP de novo
    • O WebP também é, na prática, baseado em codec de vídeo. Só que o VP8 parece ter conseguido muito pouco espaço em encoders/decoders de hardware
    • A realidade pior do que a do artigo original é que você pode acabar lidando com uma imagem JPEG que foi convertida para WEBP e depois reconvertida para JPEG. Depois alguém pode ter editado esse JPEG, e talvez ele tenha sido convertido de novo para WEBP
      Muita gente discute se dá para ver banding ou não em imagens WEBP próximas das melhores condições, mas as imagens WEBP do mundo real geralmente parecem horríveis. Só recentemente comecei a perceber isso de verdade
      Claro que agora dá para “limpar” a imagem com um processo de upscaling generativo, e é bem irônico gastar tanta eletricidade porque alguém quis economizar 45 KB
      Isso também me lembra a época em que GIFs eram convertidos para JPEG. Cerca de 25 anos atrás havia muitas capturas de tela limpas em GIF, para as quais 256 cores eram suficientes, mas o JPEG as estragava
      O Google diz aos desenvolvedores para usarem WEBP, mas não tem problema nenhum em servir petabytes de anúncios em vídeo que ninguém quer ver
    • Agora vamos falar também de HEIF. No desktop, é um formato inconveniente tanto dentro quanto fora do navegador

  • Se a ideia é “pode parecer bom aos olhos de leigos, mas não aos de um fotógrafo”, então acho que deveria haver exemplos melhores para mostrar a “leigos” por que WebP é ruim e justificar o texto e o tom
    Talvez por eu estar vendo no Android, todas as fotos parecem ter a mesma qualidade
    E, se você está produzindo fotos para “olhos especialistas”, não basta não usar uma tecnologia que não atende a olhos especialistas? Ou não terceirizar esse tipo de decisão?

    • O ponto do autor é que quem cria esse tipo de tecnologia deveria ter olhos de especialista
      Vendo os comentários nesta thread em que as pessoas falam bobagem e afirmam com confiança que não há diferença, a frustração dele parece justificada. Tudo bem não ver diferença nas primeiras imagens, mas isso não significa que você deva afirmar com confiança que sabe mais que o autor, nem projetar codecs de imagem
    • Também vi no Android
      Dava para ver mesmo sem abrir em tela cheia. É só olhar para o homem fazendo careta e observar a borda da camisa perto do ombro
      Na foto de baixa qualidade, aparece um vazamento de luz ao redor do ombro, como se fosse contraluz
      Na foto de boa qualidade, o gradiente é suave. Não há esse vazamento de luz tipo contraluz ao redor do ombro; parece apenas um fundo com gradiente suave
      Para deixar claro, não sou fotógrafo; sou engenheiro DevOps. A última vez que usei JavaScript profissionalmente foi há pelo menos 11 anos
      Dá para ver com bastante facilidade
    • Veja a discussão aqui [1]. Para distinguir, é preciso ver em tamanho real
      [1] https://news.ycombinator.com/item?id=38653224
    • Qualquer pessoa que já tenha trabalhado com codecs sabe que não se compara codec usando uma única imagem
      A ideia básica inteira deste post parece não ser passar por uma validação fundamental como comparação entre formatos, mas gerar mais reclamação e cliques

  • Para dar um pouco de contexto, Aurelien Pierre é conhecido como um dos principais contribuidores do Darktable. O Darktable é uma ferramenta open source de revelação/catalogação RAW, ou seja, algo como um Adobe Lightroom open source
    Ele é conhecido por ter opiniões fortes sobre a forma correta de fazer as coisas, às vezes até de maneira áspera, e chegou a fazer um fork do Darktable em seu próprio projeto chamado Ansel. Houve uma discussão antiga no HN também https://news.ycombinator.com/item?id=38390914

    • Preciso dar uma olhada no Ansel. Alguém sabe se ele ainda é compatível com o formato do Darktable?

  • Se você se preocupa com a qualidade de imagens de arquivo, eu não recomprimiria imagens antigas em um novo formato, a menos que pudesse fazer isso a partir dos originais não comprimidos. Reencodar a partir de uma fonte com compressão com perdas piora a qualidade. Armazenamento é barato e continua ficando mais barato
    O que faz sentido é escolher configurações seguras ao comprimir fotos novas em um novo formato

    • Dizem que o JPEG XL consegue reencodar arquivos JPEG existentes em arquivos 20% menores sem perda de qualidade
      Nesse contexto, o Google vem bloqueando o JPEG XL ao remover o suporte a JPEG XL do Chrome e se recusar a restaurá-lo, alegando que ele não oferece “benefícios incrementais” suficientes em comparação com formatos existentes como WebP
    • Certo, mas esse não é o ponto principal. Mesmo começando com um gradiente perfeito salvo em PNG, o WebP apresenta banding visível em -q100, enquanto o JPEG é visualmente transparente até em -q90

  • Parece que o autor focou no lugar errado. Ele se concentrou nas diferenças entre formatos, mas na verdade deveria ter se concentrado no método de compressão. Cada programa de processamento de imagem produz resultados diferentes de compressão, mesmo usando o mesmo número, por exemplo “80”
    Para fazer uma comparação realmente significativa, seria preciso testar imagens variadas: não só uma foto de estúdio em preto e branco de uma pessoa com fundo em gradiente suave, mas também imagens coloridas com fundos complexos. Também seria preciso considerar vários programas, como imagemagick, graphicsMagick, sharp, photoshop e diversos serviços de nuvem
    Outro problema é o caso de uso. Se um fotógrafo profissional quer enviar uma foto em tamanho integral e na qualidade máxima, talvez seja melhor simplesmente não comprimir, para preservar totalmente o resultado da criação/edição. Mas esse caso de uso não é o caso médio de um site exibindo imagens em tamanho razoável e qualidade razoável
    Em muitas situações, uma imagem muito menor vale a pena mesmo com compressão mais forte e, em muitas imagens, a compressão não será tão perceptível quanto em uma foto profissional de estúdio em resolução total com um grande fundo em gradiente

  • Pessoalmente, não vejo uma diferença significativa, então meus olhos certamente parecem ser “olhos de leigo”

    • Depende muito do dispositivo. Na máquina Windows da empresa dá para ver um pouco de banding; no celular é pior; no MacBook é horrível
    • Como a maioria, você provavelmente estava olhando só para o primeiro plano. Mesmo em um dispositivo Android 12 pequeno, se você olhar sem tela cheia, a cor do fundo perto das bordas da camisa e nas bordas da foto muda de forma perceptível de uma imagem para outra
      O que o autor está reclamando são os artefatos no fundo da imagem
    • Minha visão é ruim e não tenho treinamento, mas, depois que apontaram o defeito, ao olhar de novo ele fica bem claro
    • Ótimo. Depois que você percebe o problema de banding, fica amaldiçoado a vê-lo em todo lugar
    • Curiosamente, eu conseguia ver claramente a diferença antes de ler. O dispositivo que uso é um MacBook Air de 11 polegadas de 9 anos, então não é ruim, mas também não é equipamento de ponta
      É curioso como a percepção varia tanto de pessoa para pessoa

  • Os gradientes do WebP muitas vezes parecem frames parados de vídeo. A subamostragem de croma reduz a densidade das aproximações de luminância disponíveis e, quanto mais forte ela é aplicada, piores ficam os gradientes
    Detalhes de alto contraste e alta frequência não são muito afetados, mas gradientes podem ser gravemente prejudicados

    • Dizer que “a subamostragem de croma reduz a densidade das aproximações de luminância” é quase o oposto
      Croma significa cor, e a subamostragem de cor é usada para não remover informação do canal de luminância, que é mais importante
    • Também não é raro ver banding bem forte em gradientes escuros no WebM/VP9, então essa explicação faz algum sentido
    • O WebP usa YCbCr de faixa limitada, como vídeo, enquanto o JPEG usa YCbCr de faixa completa. Por isso, em monitores que usam valores RGB completos, JPEGs em escala de cinza parecem perfeitos, enquanto o WebP pode apresentar um pouco de banding ao exibir conteúdo em escala de cinza