Refletindo com cuidado sobre comparações de codecs

Quando saiu a notícia de que o Chrome interromperia os experimentos com JPEG XL (https://pt.news.hada.io/topic?id=7709), o issue tracker foi inundado por perguntas do tipo “por que apagar isso?”. Em resposta, o lado do AVIF chegou a publicar materiais de benchmark feitos por eles para se defender (https://storage.googleapis.com/avif-comparison/index.html). Este texto é uma análise desse material e uma tréplica do lado do JPEG XL.

Vale a leitura não apenas por apoiar ou se opor ao JPEG XL, mas porque destaca pontos importantes sobre a comparação entre formatos de imagem. Resumindo alguns pontos principais:

• A velocidade de decodificação apresentada pelo lado do AVIF se baseava em versões antigas do Chrome e do libjxl, e por isso está exagerada. Com base nas versões recentes, JPEG XL (configuração padrão) ~= AVIF de 12 bits < JPEG XL (configuração de decodificação rápida) ~= AVIF de 8 bits < JPEG XL recomprimido a partir de JPEG, e cada desigualdade representa apenas algo em torno de 10% de diferença.

• Mais importante do que a velocidade total de decodificação é em que momento a imagem utilizável aparece, e o JPEG XL leva grande vantagem aqui por suportar decodificação progressiva (progressive). (É o mesmo contexto de discutir algo como Largest Contentful Paint na web.)

• O texto compara separadamente o desempenho de codificação e a qualidade da imagem codificada, mas o libjxl permite ajustar desempenho de codificação e qualidade de codificação de forma totalmente independente, enquanto a maioria dos outros encoders, incluindo AVIF, não permite isso; portanto, essa comparação não pode ser feita da mesma forma.

• A faixa de qualidade alvo apresentada para a codificação é ampla demais e não considera distribuição de probabilidade. A pior qualidade, chamada de "On the fly", é tão baixa que ninguém conseguiria usá-la para finalidade alguma. Além disso, o AVIF tende a ir melhor em imagens de baixa qualidade em média, mas assim que o tamanho do arquivo cresce um pouco, em muitos casos o JPEG XL passa a ficar muito à frente; isso acabou sendo diluído ao se tirar médias de uma forma inadequada.

• O conjunto de dados usado nos testes é inadequado. Na compressão sem perdas, foi usado o conjunto Kodak, composto por digitalizações de imagens de revista, e na compressão com perdas entrou o conjunto Noto Emoji, normalmente usado para gráficos vetoriais ou compressão sem perdas; em ambos os casos, não são exemplos de uso típicos para compressão sem perdas e com perdas.

• Se o desempenho de compressão de imagens é uma discussão sobre o presente, então os recursos suportados por um formato de imagem são uma discussão sobre o futuro. Se um formato de imagem, uma vez adotado pelo navegador, não pode mais ser removido, então ele deve ser avaliado com ainda mais ênfase em suas funcionalidades.

[lifthrasiir]

Como escrevi às pressas antes de sair para o trabalho, há alguns erros pequenos (...): estritamente falando, "on the fly" não é a menor qualidade, e sim a maior velocidade (embora, na maioria dos codificadores, exceto o JPEG XL, tenha uma correlação inversa com a qualidade). Além disso, no conjunto de dados Kodak, eu escrevi "revista", não sei o que eu estava pensando, mas na verdade ele foi digitalizado a partir de filme.

[xguru]

Vantagens do JPEG XL