Converter AVIF para JXL

Faça isso quando algo exige JPEG XL especificamente. Uma ferramenta que não lê mais nada, um pipeline construído em torno dele, uma política de arquivamento que cita a norma ISO, ou um experimento genuíno que você pretende medir. São motivos reais, e esta conversão atende bem a eles.

Se o motivo é que JPEG XL soa mais novo ou melhor, mantenha o AVIF. Os dois formatos são próximos o bastante em compressão para que nenhum surpreenda, a conversão custa uma geração com perdas, e o AVIF é o que todo navegador atual lê enquanto o JPEG XL ainda tem suporte parcial. Não existe cenário em que converter uma imagem web funcional para JXL melhore a página onde ela está.

O AVIF foi publicado em 2019 pela Alliance for Open Media, construído sobre o codec de vídeo AV1. O JPEG XL veio em seguida, em 2022, do próprio comitê JPEG, como ISO/IEC 18181-1, tecnicamente ambicioso e em vários aspectos o desenho mais elegante.

A adoção não seguiu o mérito técnico. O suporte a AVIF em navegadores hoje é praticamente universal; para JPEG XL continua parcial, motivo pelo qual o formato fica na categoria de nicho em vez de corrente, e a demanda por ele é uma fração da demanda por AVIF. Essa lacuna é o dado mais importante para decidir se esta conversão faz sentido para o seu arquivo, e não tem nada a ver com qual codec é melhor.

O AVIF é decodificado até pixels brutos, e esses pixels são codificados de novo pelo codificador JPEG XL. Nada é carregado na forma comprimida, então o que o codificador AVIF descartou permanece descartado, e o codificador JXL toma suas próprias decisões em cima disso.

Na qualidade padrão de 82, o segundo passo raramente é visível numa fotografia, e não é gratuito. Textura fina, granulação de filme e o leve blocado que o AVIF com perdas deixa em torno de bordas duras são exatamente o que um segundo codificador trata pior, porque gasta bits descrevendo os erros do primeiro codificador como se fizessem parte do assunto.

No papel, ele vai mais longe que o AVIF em várias direções que importam para fotógrafos e arquivistas. Trata até trinta e dois bits por canal onde o AVIF para em doze, é construído para trabalho de gama ampla, e foi desenhado com o armazenamento de longo prazo de grandes coleções fotográficas como objetivo explícito.

Pouco disso chega através desta conversão específica. O que chega ao codificador já passou pelo pipeline de imagem do navegador em oito bits por canal, então a margem de profundidade é teórica aqui e seria teórica em qualquer fonte entregue pela web, que nunca teve mais de oito bits para dar.

O argumento prático mais forte a favor do JPEG XL é que ele consegue pegar um JPEG existente e reempacotá-lo cerca de vinte por cento menor com os dados da imagem intocados e totalmente recuperáveis. Isso é raro entre formatos de imagem e é por isso que grandes arquivos fotográficos levam o formato a sério.

Funciona porque os dados JPEG estão sendo rearranjados em vez de recodificados, e um AVIF contém dados AV1 em vez disso — uma representação completamente diferente da imagem, sem nada em comum com um JPEG além de ambos serem comprimidos. Não há nada para reempacotar, então este par não recebe nenhum desse benefício.

GIMP e ImageMagick leem JPEG XL, e ambos também leem AVIF, o que resume bem a situação no desktop: as ferramentas que suportam um geralmente suportam o outro, então a conversão raramente resolve um problema de "não consigo abrir isso".

Além disso o terreno fica raso rapidamente. Pré-visualizações de sistema operacional, editores mais antigos, formulários de upload, clientes de mensagem e serviços de impressão frequentemente não lidam com nenhum dos dois formatos, e onde lidam com um é mais frequentemente AVIF.

Um elemento picture com uma fonte JXL e um alternativo AVIF ou JPEG é o jeito correto de servir o formato, e funciona. O que não faz é economizar nada, porque o alternativo tem que existir e ser gerado de qualquer forma.

Essa é a aritmética incômoda desta direção para quem está pensando em desempenho web. Você começou com um formato que alcança todo mundo num tamanho perto do melhor disponível, e termina com dois arquivos, uma negociação e um cache que precisa guardar os dois.

O padrão de 82 é um bom equilíbrio para uma fotografia e o número certo para deixar como está sem motivo específico. Subir para perto de 95 torna o segundo passo de codificação conservador, o que vale quando o arquivo vai ser editado ou recodificado de novo depois.

Descer abaixo de 70 raramente vale a pena neste par. A origem já está comprimida, então os artefatos do primeiro codificador e do segundo caem nas mesmas bordas e se compõem mais rápido do que aconteceria a partir de um original.

Os dois formatos podem carregar EXIF, XMP e um perfil ICC, e nenhum dos dois blocos sobrevive a este caminho. Toda conversão de imagem aqui decodifica até pixels brutos e escreve um arquivo novo a partir deles, então a data de captura, a câmera e qualquer coordenada são descartadas em vez de migradas.

Para um arquivo sendo entregue a alguém, isso é uma melhoria de privacidade e um passo a menos para lembrar, já que as coordenadas de onde uma fotografia foi tirada são o que as pessoas mais esquecem de remover.

Solte uma pasta e os arquivos convertem um após o outro no seu próprio processador, voltando como um único ZIP sem nada enviado e sem cota diária. A codificação JPEG XL é rápida o bastante para que um lote grande seja uma questão de paciência, não de uma tarde bloqueada.

Mantenha os arquivos AVIF. São a geração anterior, são os que ainda vão exibir num navegador daqui a cinco anos, e rodar esta conversão de novo mais tarde não custa nada se as cópias JXL acabarem sendo as que você não precisava. Apagar a origem para economizar espaço num par de formatos tão próximos em tamanho é o único erro aqui que não tem volta.