Perguntas frequentes

O que é WebP? Por que devo usá-lo?

WebP é um método de compactação com e sem perda que pode ser usado em um variedade de imagens fotográficas, translúcidas e gráficas encontradas na web. O grau de compressão com perda é ajustável para que o usuário possa escolher o escolha entre tamanho de arquivo e qualidade da imagem. O WebP normalmente atinge um em média 30% mais compressão do que o JPEG e o JPEG 2000, sem perda de imagem qualidade (consulte o Estudo comparativo).

O formato WebP visa essencialmente criar imagens menores e mais bonitas que podem ajudar a tornar a Web mais rápida.

Quais navegadores da Web oferecem suporte nativo a WebP?

Os webmasters interessados em melhorar o desempenho do site podem facilmente criar alternativas WebP otimizadas para imagens atuais e veiculá-las em um específica para navegadores compatíveis com WebP.

  • Suporte a WebP com perda
    • Google Chrome (computador) 17 ou mais recente
    • Google Chrome para Android versão 25+
    • Microsoft Edge 18 ou versão mais recente
    • Firefox 65 ou superior
    • Opera 11.10 ou superior
    • Navegador da Web nativo, Android 4.0+ (ICS)
    • Safari 14 ou mais recente (iOS 14 ou mais recente, macOS Big Sur+)
  • WebP com perda, sem perda e suporte alfa
    • Google Chrome (computador) 23 ou superior
    • Google Chrome para Android versão 25+
    • Microsoft Edge 18 ou versão mais recente
    • Firefox 65 ou superior
    • Opera 12.10 ou superior
    • Navegador da Web nativo, Android 4.2+ (JB-MR1)
    • Lua clara 26+
    • Safari 14 ou mais recente (iOS 14 ou mais recente, macOS Big Sur+)
  • Suporte a animações WebP
    • Google Chrome (computador e Android) 32 ou superior
    • Microsoft Edge 18 ou versão mais recente
    • Firefox 65 ou superior
    • Opera 19 ou superior
    • Safari 14 ou mais recente (iOS 14 ou mais recente, macOS Big Sur+)

Consulte também:

Como posso detectar a compatibilidade do navegador com o WebP?

Você desejará veicular imagens WebP apenas para clientes que podem exibi-las corretamente e recorrer aos formatos legados para os clientes que não podem. Felizmente há várias técnicas para detectar o suporte a WebP, tanto no do lado do cliente e do servidor. Alguns provedores de CDN oferecem detecção de suporte a WebP como parte do serviço.

Negociação de conteúdo do lado do servidor pelos cabeçalhos Aceitar

É comum que clientes Web enviem uma solicitação "Accept" cabeçalho da solicitação, indicando e quais formatos de conteúdo eles aceitam em resposta. Se um navegador indica com antecedência que "aceitará" o formato image/webp o servidor da Web sabe que pode enviar com segurança imagens WebP, simplificando muito a negociação de conteúdo. Consulte os links a seguir para mais informações.

Modernizr

O Modernizr é uma biblioteca JavaScript para a detecção conveniente de HTML5 e Suporte a recursos CSS3 em navegadores da Web. Procure as propriedades Modernizr.webp, Modernizr.webp.lossless, Modernizr.webp.alpha e Modernizr.webp.animation.

Elemento HTML5 <picture>

O HTML5 oferece suporte a um elemento <picture>, que permite listar vários, destinos de imagem alternativos em ordem de prioridade, de modo que um cliente solicite a primeira imagem candidata a ser exibida corretamente. Consulte nesta discussão sobre HTML5 Rocks. O elemento <picture> é mais compatíveis com mais navegadores o tempo todo.

No seu próprio JavaScript

Outro método de detecção é tentar decodificar uma imagem WebP muito pequena que usa um determinado recurso e verifica o sucesso. Exemplo:

// check_webp_feature:
//   'feature' can be one of 'lossy', 'lossless', 'alpha' or 'animation'.
//   'callback(feature, result)' will be passed back the detection result (in an asynchronous way!)
function check_webp_feature(feature, callback) {
    var kTestImages = {
        lossy: "UklGRiIAAABXRUJQVlA4IBYAAAAwAQCdASoBAAEADsD+JaQAA3AAAAAA",
        lossless: "UklGRhoAAABXRUJQVlA4TA0AAAAvAAAAEAcQERGIiP4HAA==",
        alpha: "UklGRkoAAABXRUJQVlA4WAoAAAAQAAAAAAAAAAAAQUxQSAwAAAARBxAR/Q9ERP8DAABWUDggGAAAABQBAJ0BKgEAAQAAAP4AAA3AAP7mtQAAAA==",
        animation: "UklGRlIAAABXRUJQVlA4WAoAAAASAAAAAAAAAAAAQU5JTQYAAAD/////AABBTk1GJgAAAAAAAAAAAAAAAAAAAGQAAABWUDhMDQAAAC8AAAAQBxAREYiI/gcA"
    };
    var img = new Image();
    img.onload = function () {
        var result = (img.width > 0) && (img.height > 0);
        callback(feature, result);
    };
    img.onerror = function () {
        callback(feature, false);
    };
    img.src = "data:image/webp;base64," + kTestImages[feature];
}

O carregamento de imagens não bloqueia e é assíncrono. Isso significa que o código que depende do suporte a WebP deve ser colocado no callback função.

Por que o Google lançou o WebP como código aberto?

Acreditamos profundamente na importância do modelo de código aberto. Com o WebP em qualquer pessoa pode trabalhar com o formato e sugerir melhorias. Com suas contribuições e sugestões, acreditamos que o WebP se tornará ainda mais útil como um formato gráfico ao longo do tempo.

Como posso converter meus arquivos de imagens pessoais para WebP?

Você pode usar o utilitário de linha de comando WebP para converter seus arquivos de imagem pessoais para o formato WebP. Consulte Como usar o WebP para mais detalhes.

Se você tiver muitas imagens para converter, use o shell da plataforma para simplificar a operação. Por exemplo, para converter todos os arquivos jpeg de uma pasta, tente o seguinte:

Windows:

> for /R . %I in (*.jpg) do ( cwebp.exe %I -o %~fnI.webp )

Linux / macOS:

$ for F in *.jpg; do cwebp $F -o `basename ${F%.jpg}`.webp; done

Como posso avaliar a qualidade da imagem WebP por conta própria?

Atualmente, é possível visualizar arquivos WebP convertendo-os em um formato comum que usa compactação sem perdas, como PNG, e exibir os arquivos PNG em um qualquer navegador ou visualizador de imagens. Para ter uma ideia rápida da qualidade do WebP, consulte Galeria neste site para fotos lado a lado e comparações.

Como consigo o código-fonte?

O código do conversor está disponível na seção de downloads do projeto de código aberto WebP página. O código do decodificador leve e a especificação VP8 estão o site WebM. Consulte a Página RIFF Container do contêiner especificação.

Qual é o tamanho máximo de uma imagem WebP?

O WebP é compatível com bitstream com o VP8 e usa 14 bits para largura e altura. As dimensões máximas em pixels de uma imagem WebP são 16.383 x 16.383.

Quais espaços de cor são compatíveis com o formato WebP?

Consistente com o bitstream VP8, o WebP com perda funciona exclusivamente com um Formato de imagem Y'CbCr 4:2:0 de 8 bits (geralmente chamado de YUV420). Consulte a seção 2, "Visão geral do formato" da RFC 6386, Guia de decodificação e formato de dados VP8 para mais detalhes.

O WebP sem perda funciona exclusivamente com o formato RGBA. Consulte a Especificação de Bitstream sem perdas do WebP.

Uma imagem WebP pode aumentar do que a imagem de origem?

Sim, geralmente ao converter de um formato com perda para WebP sem perda ou vice-versa. Isso se deve principalmente à diferença do espaço de cores (YUV420 vs. ARGB). e a conversão entre eles.

Há três situações típicas:

  1. Se a imagem de origem estiver em formato ARGB sem perdas, a taxa de redução espacial ao YUV420 apresentará novas cores, mais difíceis de comprimir do que aos originais. Essa situação costuma acontecer quando a fonte está no formato PNG com algumas cores: convertendo para WebP com perda (ou, da mesma forma, para um JPEG com perda) pode resultar em um tamanho de arquivo maior.
  2. Usar a compressão WebP sem perda se a fonte estiver em formato com perda para capturar a natureza com perdas da fonte, um arquivo maior. Isso não é específico do WebP e pode ocorrer converter uma origem JPEG para formatos WebP ou PNG sem perda, por exemplo.
  3. Se a origem estiver em formato com perda e você estiver tentando compactá-la como um WebP com perda e uma configuração de qualidade mais alta. Por exemplo, tentar converter um arquivo JPEG salvo com qualidade 80 em um arquivo WebP com qualidade 95 o resultado será um arquivo maior, mesmo que os dois formatos tenham perdas. Avaliar a qualidade da fonte costuma ser impossível, por isso é aconselhável diminua a qualidade WebP de destino se o tamanho do arquivo for consistentemente maior. Outra possibilidade é evitar o uso da configuração de qualidade e, em vez segmentar um determinado tamanho de arquivo usando a opção -size na ferramenta cwebp; ou a API equivalente. Por exemplo, segmentar 80% do arquivo original pode ser mais robusto.

Observe que a conversão de uma origem JPEG para WebP com perda ou de uma fonte PNG para sem perda WebP não são propensos a tais surpresas no tamanho do arquivo.

O WebP é compatível com exibição progressiva ou entrelaçada?

O WebP não oferece atualização de decodificação progressiva ou entrelaçada nos formatos JPEG PNG. Isso provavelmente colocará muita pressão sobre a CPU e a memória da decodificando o cliente, já que cada evento de atualização envolve uma passagem completa pelo sistema de descompactação.

Em média, decodificar uma imagem JPEG progressiva é equivalente a decodificar a valor de referência três vezes.

Como alternativa, o WebP oferece decodificação incremental, em que todos os bytes do bitstream são usados para tentar produzir uma linha de amostra que pode ser exibida como assim que possível. Isso economiza memória, CPU e esforço de reformulação da tela enquanto fornece indicações visuais sobre o status do download. O aumento o recurso de decodificação está disponível API Advanced DeEncoding.

Como usar as vinculações Java do libwebp no projeto Android?

O WebP inclui suporte para vinculações JNI ao codificador e decodificador simples interfaces de rede no diretório swig/.

Como criar a biblioteca no Eclipse:

  1. Certifique-se de que você Plug-in ADT instalado junto com as ferramentas do NDK e o caminho do NDK está definido corretamente (Preferências > Android > NDK).
  2. Crie um novo projeto: File > Novo > Projeto > No Android Projeto de aplicativo.
  3. Clone ou descompacte o libwebp em uma pasta chamada jni no novo projeto.
  4. Adicione swig/libwebp_java_wrap.c à lista LOCAL_SRC_FILES.
  5. Clique com o botão direito do mouse no novo projeto e selecione Android Tools > Adicionar Suporte nativo ... para incluir a biblioteca no seu build.
  6. Abra as propriedades do projeto e acesse Build C/C++ > Comportamento. Adicionar ENABLE_SHARED=1 à seção Build (Incremental build) para criar libwebp como uma biblioteca compartilhada.

    Observação: em geral, a definição de NDK_TOOLCHAIN_VERSION=4.8 melhora Desempenho de build de 32 bits.

  7. Adicione swig/libwebp.jar à pasta do projeto libs/.

  8. Crie o projeto. Isso vai criar libs/<target-arch>/libwebp.so.

  9. Use System.loadLibrary("webp") para carregar a biblioteca no momento da execução.

A biblioteca pode ser criada manualmente com ndk-build e os recursos Android.mk. Nesse caso, algumas das etapas descritas acima podem ser reutilizadas.

Como usar o libwebp com C#?

O WebP pode ser criado como uma DLL que exporta a API libwebp. Essas funções podem e importá-la em C#.

  1. Crie o libwebp.dll. Isso definirá WEBP_EXTERN corretamente para exportar a API .

    libwebp> nmake /f Makefile.vc CFG=release-dynamic
    
  2. Adicione libwebp.dll ao projeto e importe as funções desejadas. Se você usar o método API simples chame WebPFree() para liberar todos os buffers retornados.

    [DllImport("libwebp.dll", CallingConvention = CallingConvention.Cdecl)]
    static extern int WebPEncodeBGRA(IntPtr rgba, int width, int height, int stride,
                                     float quality_factor, out IntPtr output);
    [DllImport("libwebp.dll", CallingConvention = CallingConvention.Cdecl)]
    static extern int WebPFree(IntPtr p);
    
    void Encode() {
      Bitmap source = new Bitmap("input.png");
      BitmapData data = source.LockBits(
          new Rectangle(0, 0, source.Width, source.Height),
          ImageLockMode.ReadOnly,
          PixelFormat.Format32bppArgb);
      IntPtr webp_data;
      const int size = WebPEncodeBGRA(data.Scan0,
                                      source.Width, source.Height, data.Stride,
                                      80, out webp_data);
      // ...
      WebPFree(webp_data);
    }
    

Por que devo usar WebP animado?

Vantagens do WebP animado em comparação ao GIF animado

  1. O WebP oferece suporte a cores RGB de 24 bits com um canal alfa de 8 bits, em comparação com Cor de 8 bits e Alfa de 1 bits do GIF.

  2. O WebP é compatível com compactação com e sem perda. na verdade, pode combinar frames com e sem perda. Somente GIF é compatível compressão sem perdas. As técnicas de compactação com perda do WebP são adequadas até imagens animadas criadas a partir de vídeos do mundo real, um modelo fonte de imagens animadas.

  3. O WebP exige menos bytes do que o GIF1. GIFs animados convertidos em WebPs com perda são 64% menores, e não têm perdas Os WebPs são 19% menores. Isso é especialmente importante nas redes móveis.

  4. O WebP leva menos tempo para decodificar na presença de busca. Em Piscar, rolar ou trocar de guia pode ocultar e mostrar imagens, pausando as animações e avançou para outro ponto. Uso excessivo da CPU que resulta animações que descartam quadros também podem exigir que o decodificador avance a animação. Nesses cenários, os WebP animados têm 0,57x mais decodificar o tempo2 como GIF, o que resulta em menos instabilidade durante a rolagem e uma recuperação mais rápida de picos de uso da CPU. Isso é devido a duas vantagens do WebP sobre o GIF:

    • Imagens WebP armazenam metadados que indicam se cada frame contém alfa, eliminando a necessidade de decodificar o frame para fazer essa determinação. Isso leva a uma inferência mais precisa de quais frames anteriores um determinado depende, reduzindo, assim, a decodificação desnecessária de frames.

    • Assim como um codificador de vídeo moderno, o WebP adiciona de forma heurística frames-chave em intervalos regulares (o que a maioria dos codificadores GIF não faz). Isso melhora drasticamente a busca em animações longas. Para facilitar inserindo esses frames sem aumentar significativamente o tamanho da imagem, WebP adiciona um 'método de combinação' flag para cada frame, além do método de descarte de frames usado pelo GIF. Isso permite que um frame-chave seja desenhado como se a imagem inteira tivesse sido apagada à cor do plano de fundo sem forçar o frame anterior em tamanho original.

Desvantagens do WebP animado em comparação com GIF animado

  1. Na ausência de busca, a decodificação em linha reta do WebP é mais Isso consome muita CPU do que o GIF. WebP com perda 2,2x mais tempo de decodificação GIF, enquanto o WebP sem perda usa 1,5x mais.

  2. O suporte a WebP não é tão difundido quanto o suporte a GIF, que é efetivamente universal.

  3. Adicionar suporte a WebP para navegadores aumenta o tamanho do código e de ataque menor. No Blink, são aproximadamente 1.500 linhas adicionais (incluindo a biblioteca demux WebP e a imagem WebP do Blink-side decodificador). Esse problema poderá ser reduzido no futuro se O WebP e o WebM compartilham um código de decodificação mais comum, ou se o de código-fonte são incluídos nos WebM.

Por que não oferecer suporte a WebM em <img>?

Em longo prazo, pode ser útil oferecer suporte a formatos de vídeo dentro do <img>. tag. No entanto, ao fazer isso agora, com a intenção que o WebM em <img> pode preencher o papel proposto de WebP animado, é problemático:

  1. Ao decodificar um frame que depende de frames anteriores, o WebM exige 50% mais memória do que o WebP animado para manter o número mínimo de frames anteriores3.

  2. A compatibilidade com codec de vídeo e contêiner varia muito entre os navegadores. dispositivos. Para facilitar a transcodificação de conteúdo automática (por exemplo, para proxies de economia de largura de banda), os navegadores precisariam adicionar cabeçalhos de aceitação indicando quais formatos são compatíveis com as tags de imagem. Até isso pode ser insuficiente, já que tipos MIME como "vídeo/webm" ou "vídeo/mpeg" ainda não indique a compatibilidade com o codec (por exemplo, VP8 vs. VP9). No outro o formato WebP é efetivamente congelado e, se os fornecedores ele envia um WebP animado, que é o comportamento dele em todos os UAs, deve ser consistente; e como a tag "image/webp" aceitar cabeçalho é já é usado para indicar o suporte a WebP, não há novas alterações de cabeçalho de aceitação necessárias.

  3. A pilha de vídeos do Chromium é otimizada para reprodução suave e presume que há apenas um ou dois vídeos sendo reproduzidos ao mesmo tempo tempo de resposta. Como resultado, a implementação é agressiva no sistema de consumo (linhas de execução, memória etc.) para maximizar a qualidade de reprodução. Um não é bem dimensionada para muitos vídeos simultâneos e precisam ser reformulados para serem adequados para uso em páginas da Web com muitas imagens.

  4. No momento, o WebM não incorpora todas as técnicas de compactação do WebP. Como resultado, esta imagem com compactação significativamente melhor com o WebP do que as alternativas:


1 Para todas as comparações entre GIF e WebP animado, nós usou um corpus de cerca de 7.000 imagens animadas de GIF tiradas aleatoriamente da Web. Essas imagens foram convertidas para WebP animado usando o 'gif2webp' ferramenta usando padrão (criadas com base na versão Árvore de origem do libwebp em 08/10/2013). Os números comparativos são os valores médios dessas de imagens de contêiner.

2 Os tempos de decodificação foram calculados usando a versão mais recente do libwebp + ToT. Blink em 08/10/2013 usando uma ferramenta de comparativo de mercado. "Decodificar tempo com a busca" é calculado como "Decodifique os cinco primeiros frames, limpe o frame o cache do buffer de protocolo, decodificar os próximos cinco frames e assim por diante".

3 O WebM mantém quatro frames de referência YUV na memória, com cada frame armazenando (largura + 96)*(altura + 96) pixels. Para o YUV 4:2:0, precisamos de 4 bytes por 6, pixels (ou 3/2 bytes por pixel). Então, esses frames de referência usam 4*3/2*(width+96)*(height+96) bytes de memória. O WebP, por outro lado, só precisa que o frame anterior (em RGBA) esteja disponível, que é 4*width*height bytes de memória.

4 A renderização de WebP animado requer o Google Chrome versão 32 ou posterior