Inspetor de arquivos WebP

Como usar

1. Solte um arquivo .webp na caixa. Vale tudo o que a extensão cobre: uma foto, um adesivo com transparência, uma animação ou um arquivo que você suspeita estar quebrado.
2. Veja primeiro a forma do arquivo. Simples com perdas, simples sem perdas e estendido são três leiautes distintos, e um decodificador que só conhece os simples recusa o terceiro.
3. Compare a tela declarada com o que este navegador decodificou. Deveriam bater; se o navegador recusou o arquivo, a lista de achados diz o motivo.
4. Abra a tabela de blocos para ver o leiaute: fourcc, deslocamento, tamanho declarado e se vem um byte de preenchimento. Esses deslocamentos são o ponto de partida ao depurar um codificador.
5. Numa animação, confira a tabela de quadros — os deslocamentos já foram devolvidos ao dobro do campo — e as durações, em que o Chrome exibe um quadro de 0 ms por 100 ms.

Perguntas frequentes

Por que um .webp começa com um bloco VP8 e outro com VP8L ou VP8X? Não é o mesmo formato?

Eles dividem o contêiner e a extensão, não o fluxo de bits. A forma simples com perdas embrulha um quadro-chave VP8, o mesmo quadro intra com que um vídeo VP8 começaria, e a forma simples sem perdas embrulha um fluxo VP8L, que é um codec inteiramente diferente, com codificação entrópica e transformadas de cor próprias. A forma estendida coloca um bloco VP8X na frente para que o arquivo também possa carregar alfa num bloco ALPH separado, um perfil ICC, Exif, XMP ou uma animação, e só então os dados de imagem. É por isso que um decodificador antigo abre um WebP e recusa o seguinte: as formas simples chegaram em 2010 e a estendida em 2011, e cada biblioteca as adicionou em momentos diferentes. O fourcc do primeiro bloco é a única coisa que decide qual forma você tem.

Os deslocamentos dos quadros de uma animação parecem a metade do que deveriam. Por quê?

Porque é literalmente o que está guardado. Um cabeçalho ANMF guarda o X e o Y do quadro como valores de 24 bits que são o deslocamento real dividido por dois, o que também explica por que um quadro só pode ser colocado em coordenadas pares. Um leitor que imprime o campo como está mostra um quadro em x=8 como x=4, e um compositor que usa o campo cru desenha cada quadro à metade da distância da borda da tela — um defeito que parece um desvio sutil e não uma quebra evidente. O mesmo cabeçalho guarda largura e altura menos um, então um quadro de 32 pixels de largura é escrito como 31. Esta ferramenta dobra os deslocamentos e soma um aos tamanhos antes de mostrá-los, e por isso os números aqui batem com o que um decodificador realmente pinta.

O que acontece com um quadro que declara duração de 0 ms?

Ele não é exibido por tempo zero. O Chrome e os demais navegadores baseados em Blink substituem por 100 ms a duração de um quadro WebP que vale 0, a mesma substituição que fazem num quadro GIF de atraso muito pequeno, partindo do princípio de que o zero foi um engano e não um pedido de animação infinitamente rápida. Firefox e Safari nem sempre concordaram, e ferramentas de linha de comando como o ffmpeg mantêm o zero e produzem outra taxa de quadros. A consequência prática é que a soma das durações declaradas não é o tempo que o arquivo roda: aqui aparecem os dois totais para você ver a distância entre eles antes de confiar no ritmo.

A tela e a imagem dentro dela têm tamanhos diferentes. O navegador estica ou coloca bordas?

Nenhum dos dois, no caso de uma imagem parada. A libwebp exige que a tela do VP8X seja igual às dimensões do único quadro VP8 ou VP8L que ela contém e recusa o arquivo quando divergem; e como Chrome, Firefox e Safari decodificam WebP com a libwebp, uma imagem parada desalinhada simplesmente não aparece em lugar nenhum. Numa animação a regra é outra e a tela pode legitimamente ser maior: cada quadro ANMF é composto no seu próprio deslocamento e o que passar da borda é cortado. Por isso esta ferramenta trata a divergência entre tela e fluxo de bits numa imagem parada como um achado e informa à parte os quadros que ultrapassam a tela.

Por que o campo de tamanho RIFF importa se o arquivo abre mesmo assim?

Ele só abre mesmo assim se o campo estiver certo. Os quatro bytes do deslocamento 4 precisam conter o tamanho do arquivo menos oito — esses oito são o fourcc RIFF e o próprio campo de tamanho — e a libwebp valida isso antes de decodificar qualquer coisa. Um download que parou cedo mantém o campo de tamanho original enquanto perde bytes do fim, então o campo fica grande demais e o arquivo é recusado sem outra mensagem além do ícone de imagem quebrada. O caso oposto é um codificador que esqueceu de voltar e corrigir o campo depois de anexar metadados, o que produz um arquivo que algumas ferramentas leem e os navegadores não. Aqui os dois números são impressos para você ver qual dos casos tem, e os bytes que sobrarem depois do último bloco são sinalizados à parte.

Como a transparência é guardada e por que a mesma imagem às vezes tem um bloco ALPH e às vezes não?

São três arranjos. Um arquivo sem perdas registra o alfa dentro do próprio fluxo VP8L e apenas liga um bit de dica no cabeçalho. Um com perdas não consegue, porque o VP8 não tem canal alfa nenhum, então o codificador emite um arquivo estendido: um VP8X com o sinalizador de alfa ligado, um bloco ALPH com o plano de alfa — comprimido sem perdas e filtrado opcionalmente na horizontal, na vertical ou por gradiente — e depois o bloco VP8 com a cor. Uma animação repete isso por quadro, então alguns quadros podem trazer ALPH e outros não. Mais um detalhe: um codificador com perdas normalmente descarta a cor dos pixels totalmente transparentes para poupar bytes, algo invisível até que alguma coisa componha ou borre a imagem, e a opção exact da libwebp é o que preserva essa cor.

Ferramentas relacionadas