Lançamento da nova especificação do PNG

• O formato de arquivo PNG foi revisado pela primeira vez em 20 anos, recuperando seu antigo destaque
• Esta especificação incorpora várias tecnologias modernas, incluindo suporte oficial a HDR, APNG (animação) e dados Exif
• O desenvolvimento contou com a participação conjunta de grandes empresas de TI e do setor de broadcast, como Adobe, Apple e Google
• A especificação mais recente já é suportada por vários programas, como Chrome, Safari e Photoshop
• Há planos para futuras atualizações, incluindo melhores técnicas de compressão e codificação/decodificação paralela

---

Introdução: o renascimento e a importância do PNG

• Recentemente, o formato de arquivo PNG foi atualizado com uma nova especificação após cerca de 20 anos de estagnação
• Instituições importantes como a Biblioteca do Congresso dos EUA, Library and Archives Canada e o Arquivo Nacional da Austrália adotam o PNG como formato oficialmente recomendado
• Com a nova especificação, o PNG recupera sua competitividade no mercado e volta a demonstrar capacidade de inovação

Novos recursos e características

Suporte adequado a HDR e compatibilidade futura

• O novo PNG oferece suporte a HDR (High Dynamic Range)
• Em imagens comparando os espaços de cor Rec. 2020 e Rec. 709, a área mais ampla (o triângulo externo) mostra as cores representadas pela imagem HDR
• Essas informações de HDR exigem apenas 4 bytes adicionais (além da sobrecarga dos chunks já existentes do PNG)
• Chris Lilley e outros autores iniciais, além de especialistas técnicos centrais, participaram explicando claramente as novas tecnologias

Reconhecimento oficial do APNG (PNG animado)

• O PNG animado (APNG), proposto inicialmente pela Mozilla e suportado pelo Firefox, também foi incorporado à especificação oficial
• Antes era suportado apenas por alguns softwares, mas hoje já foi amplamente adotado por diversos programas

Suporte oficial a dados Exif

• Com Exif, é possível armazenar metadados como direitos autorais, informações da câmera e dados de GPS
• Isso garante grande utilidade em criação e arquivamento de imagens, além de gestão de direitos autorais

Melhorias gerais e correções de erros

• A atualização também inclui correções de errata e esclarecimentos da especificação anterior

Contexto e processo de desenvolvimento

• A última especificação do PNG havia sido publicada há cerca de 20 anos (três anos e meio antes do lançamento do iPhone)
• O desenvolvimento foi retomado quando o W3C Timed Text Working Group (padronização técnica de legendas) levantou a necessidade de suporte a HDR no PNG
• Após a proposta, Adobe, Apple, BBC, Google, MovieLabs, W3C e outras grandes organizações de tecnologia participaram em conjunto
• Formou-se um consórcio forte, transformando o PNG em um formato de imagem de nova geração
• Atualmente, duas atualizações subsequentes já estão em preparação

Situação atual de ampla adoção

• A especificação mais recente do PNG é suportada por diversos programas, como Chrome, Safari, Firefox, iOS/macOS, Photoshop, DaVinci Resolve e Avid Media Composer
• O suporte também está se expandindo entre empresas de broadcast e em hardware e ferramentas relacionadas
• Elementos gráficos de transmissão, como rolagens de notícias e banners de placar esportivo, são exemplos de uso do novo PNG com HDR

Planos futuros

• A próxima edição pretende melhorar ainda mais a compatibilidade entre HDR & SDR
• Além disso, estão em andamento métodos de compressão mais avançados e codificação/decodificação paralela
• A quarta edição deverá ser uma atualização relativamente curta, e depois disso está prevista uma quinta edição baseada em pesquisas sobre tecnologia de compressão

[carnoxen]

No começo, rejeitaram o APNG dizendo que não era um padrão oficial de imagem da organização, e só agora finalmente reconheceram.

[GN⁺]

Comentários no Hacker News

• O autor se identifica e diz que perguntas são bem-vindas a qualquer momento

  • Enfatiza que este PNG não é um formato totalmente novo, mas uma versão atualizada do formato existente

  • Afirma que oferece compatibilidade retroativa muito alta

  • Explica que programas antigos também conseguem ler os novos arquivos PNG da melhor forma possível e, por exemplo, ainda reconhecer que se trata de uma foto de uma maçã vermelha

  • Resume os pontos principais porque pode haver confusão sobre o funcionamento interno do PNG

    • Um arquivo PNG é composto por vários chunks de dados
    • Cada chunk tem um nome, então um programa pode simplesmente pular chunks que não conhece ou de que não precisa
    • Especifica que existe apenas um único fluxo de imagem

  • Diz que gostaria que houvesse arquivos de exemplo usando os recursos da nova especificação do PNG, especialmente uma página de demonstração onde fosse possível baixar diretamente animações ou imagens HDR para testar compatibilidade entre programas

  • Afirma que apoia metaformatos e tooling genérico

    • Dá como exemplo estruturas como Office Open XML e ePub, que podem ser parseadas apenas com bibliotecas de zip e XML
    • Explica por experiência própria que o PNG tem uma estrutura quase igual à do Interchange File Format (doravante IFF), mas que antes havia pequenas diferenças na especificação que tornavam impossível fazer um parser IFF totalmente genérico que parseasse ao mesmo tempo PNG e arquivos da família IFF
    • Diz que o IFF é fácil de implementar e tem vantagens em compressão de dados, mas até hoje foi usado apenas em usos limitados, como dados de jogos antigos e áudio AIFF/RIFF, e aponta a falta de compatibilidade entre PNG e IFF como uma das razões para não ter surgido tooling genérico
    • Diz esperar que, se o PNGv3 fizer com que arquivos PNG se tornem oficialmente arquivos IFF, a popularidade do PNG ajude a expandir um ecossistema IFF genérico (por exemplo, algo como libiff) e permita seu uso também na definição de novos formatos
    • Menciona que já implementou parsers de PNG/IFF e que não é fácil simplesmente modificar o PNG para torná-lo compatível com IFF, além de ser necessário preservar a compatibilidade retroativa, especialmente com parsers em hardware
    • Propõe documentar separadamente como um novo metaformato padrão (IFF 2.0) a estrutura derivada de IFF usada pelo PNG
    • Espera que o IFF 2.0 oficialize perfis como um perfil compatível com PNGv2 e perfis que também cubram IFFv1, como AIFF/RIFF, para impulsionar tooling IFF genérico
    • Vai além e diz que, em um novo perfil greenfield voltado a ambientes modernos, seria possível adotar, por exemplo, verificação de integridade com hashes modernos em vez de CRC, ampliar o conjunto de caracteres dos nomes de chunks e introduzir uma estrutura para armazenar de forma eficiente informações de atributos de cada chunk
    • Considera desejável que essas estruturas permitam transcodificação tanto de IFFv1 quanto de PNGv2, e que se faça algo parecido com a estratégia de declaração de perfis usada no HTML5 para combinar e compatibilizar HTML4 e XHTML
    • Conclui enfatizando que se concentrou mais nos objetivos de design — minimizar a heterogeneidade entre formatos antigos e novos e expandir o ecossistema de ferramentas — do que nos detalhes

• No meu aplicativo de desenho baseado na web, uso o truque de armazenar a representação JSON do documento no campo de comentário do PNG

  • Assim, o arquivo salvo pode ser usado diretamente como imagem e também pode ser carregado de volta no editor

  • Isso tem a vantagem de evitar o acúmulo de arquivos JSON pouco reconhecíveis na pasta de downloads

  • É divertido, mas fica meio complicado explicar ao usuário por que o arquivo é salvo como .png ou por que os dados desaparecem se ele abrir e salvar no Paint, por exemplo

  • O Krita também salva configurações de pincel dessa forma, mas isso pode causar problemas inesperados quando a quantidade de dados é grande

    • Issues relacionadas: Krita-Brushes issue #4, conversa sobre Memileo Impasto Brushes

  • O Macromedia Fireworks já usava PNG como formato padrão de salvamento há 20 anos

    • Claro que naquela época não colocava JSON dentro

  • Muitos frontends de geração de imagem por IA também usam algo parecido

    • Salvam prompts ou configurações em comentários da imagem, de modo que, ao abrir só a imagem, seja possível recuperar as configurações ou até carregar o workflow inteiro, como no ComfyUI
    • Na verdade, acho que esse tipo de abordagem é bem comum em ferramentas que lidam com imagem

  • O Macromedia Fireworks salvava arquivos Fireworks dentro de PNG,

    • arquivos do Adobe Illustrator (AI) na prática são PDF,
    • e arquivos PSD do Photoshop também podem ser armazenados dentro de TIFF
    • Por isso, no Photoshop várias camadas podem aparecer, enquanto em outros softwares só aparece uma camada

• Esta especificação parece mais uma formalização de algo que já foi amplamente implementado

  • Mesmo sendo um PNG de próxima geração, se exigisse um novo decodificador talvez pudesse ter sido chamado de PNG2

  • O JPEG-XL já atende à maioria das condições que as pessoas querem em um codec sem perdas

    • O problema é velocidade e recursos de codificação/decodificação

  • Hoje, o melhor codec de imagem sem perdas é o HALIC

    • Discussão detalhada: discussão do HALIC no HN

  • Olhando a thread de discussão do HALIC, dizem que na prática o LEA 0.5 é superior

    • No benchmark de compressão sem perdas de imagens, o HALIC não está entre os primeiros

  • Sinceramente, por um tempo eu ignorei o JPEG XL porque achei que ele servia só para “imagens gigantes”

  • Eu uso png numa ferramenta de anotação de imagens para visão computacional (XLabel)

    • Posso salvar os rótulos de classe diretamente nos metadados da imagem sem precisar manter arquivos de texto separados
    • No futuro, gostaria de criar um formato estendido voltado a esse tipo de uso

  • A compressão sem perdas do WebP é de altíssimo nível, mas mesmo assim não é amplamente usada

    • Isso sugere que o principal desafio não é apenas atingir a melhor compressão sem perdas, e sim a adoção no ecossistema

  • Problemas de velocidade de codificação/decodificação podem melhorar com o tempo

    • Isso de fato aconteceu antes no ecossistema jpg

• O melhor de tudo é que o suporte oficial a dados Exif foi incluído

  • Já era possível gravar dados personalizados no cabeçalho antes, mas ter suporte a Exif é muito bem-vindo

  • A propósito, fico curioso se o Exif tem campos para giroscópio (rotação) ou acelerômetro (gravidade)

    • Muitas vezes senti falta dessas informações em fotos tiradas com o app da câmera do Google para correções automáticas ou montagem de panoramas depois

  • Existe um campo de aceleração (Exif.Photo.Acceleration) e um campo para altitude/elevação da câmera (Exif.Photo.CameraElevationAngle),

    • mas não há suporte para os três eixos completos
    • Há sensores ambientais (condições ao redor), mas só são contemplados itens específicos definidos pelos autores da especificação
    • Exif.Photo.MakerNote é uma área livre em que o fabricante pode salvar o que quiser, e o limite de tamanho é grande o bastante para registrar até dados de 9 eixos

  • O Exif pode causar confusão na renderização da imagem dependendo de como a rotação é tratada

    • Decodificadores antigos e novos podem mostrar a imagem de forma diferente dependendo de considerarem ou não a rotação Exif
    • Como não há recomendações detalhadas para decodificadores sobre rotação Exif, bugs como rotação dupla — por exemplo, o ambiente desktop e a biblioteca tratando isso separadamente — ocorrem com frequência
    • Só existe uma recomendação ambígua do tipo “se o decodificador não souber separadamente se os dados Exif são confiáveis, deve tratá-los apenas como registro histórico”
    • Para compatibilidade retroativa total, acho que seria necessária uma diretriz clara como “nunca rotacione”

  • Não existe um campo padrão para registrar dados de acelerômetro ou de sistema de navegação inercial da câmera

    • Lista de campos Exif: descrição oficial das tags do exiv2

  • Na prática, muitos sites removem a maior parte dos dados Exif no upload

    • Porque alguns campos podem ser usados indevidamente para privacidade ou rastreamento de localização

  • Pessoalmente, eu preferiria que as pessoas usassem XMP em vez de Exif

    • O Exif tem uma estrutura estranha e essencialmente equivale a embutir uma imagem TIFF dentro de um PNG

• Esta especificação de PNG oficializa práticas que já eram amplamente usadas

  • O melhor codec precisa funcionar em qualquer lugar, em qualquer app, no shell do sistema operacional, em APIs, no Linux etc.

  • Formatos como HEIC ou AV1, sem suporte no nível do sistema operacional, são difíceis até para pré-visualizar

  • Um formato que não circula direito não deveria virar padrão da plataforma

  • Trabalho com vários formatos de imagem, inclusive formatos raros usados só em nichos específicos

    • Dar suporte de verdade a muitos formatos é um desafio enorme
    • Bibliotecas até dizem superficialmente que suportam jpg/tif/heic, mas isso não significa que vão lidar sem problemas com, por exemplo, um jpeg de 30 GB ou com todos os metadados

  • Essa nova especificação talvez seja ainda mais confusa do que HEIC ou AV1

    • Não dá para saber de jeito nenhum qual codec está dentro do PNG antes de abrir o arquivo

• É a primeira vez que vejo HDR ser usado claramente não no sentido de expansão de brilho/faixa de contraste, mas no sentido de “espaço de cor mais amplo”

• Fico me perguntando se não é tarde demais

  • E o JPEG XL já oferece todos os recursos (compressão com e sem perdas, animação, HDR, Exif etc.) e técnicas avançadas de compressão (Finite State Entropy, ZStandard etc.)

  • Acho que não precisa de atualização separada para PNG; era só usar JPEG XL

  • Na prática, esse “é só adotar” não funciona

    • Status de suporte do JPEG XL em navegadores: já se passaram 5 anos e só há suporte em um navegador
    • Se os fabricantes de navegadores não implementarem, desenvolvedores e usuários não conseguem usar o novo formato

  • Sobre a menção a “técnicas avançadas de compressão (ZStandard etc.)”

    • O ZStandard pode até não ser bom para comprimir números com variação regular, como gradientes
    • O Bzip2 é melhor nesse aspecto e pode ser mais adequado quando duas variáveis — repetição interna e externa, como no exemplo — correspondem aos canais de cor
    • Dados reais não são tão simples por causa do ruído, mas esse tipo de comparação entre algoritmos ainda assim difere da prática
      • Referência: discussão relacionada no Mastodon

  • “Não precisa atualizar o PNG, basta adotar JPEG XL”

    • Então isso tem que ser dito ao Google
    • Na prática, o Google abandonou o suporte a JPEG XL no Chrome (issue relacionada), e isso acabou bloqueando a expansão do ecossistema

  • Não entendo por que criar mais um padrão (ou derivação)

    • Já existe confusão demais, e continuam surgindo novos padrões sem nenhum diferencial realmente único

• Agora vai dar para substituir GIF por APNG (alpha blending + fundo transparente + compressão sem perdas), então a estética web dos anos 2000 pode voltar com tudo

  • Fico curioso se existe um padrão de Animated SVG também

    • Já vi antes animações SVG baseadas em JavaScript, como avatar de chatbot, mas não sei se existe um framework padrão

  • Animated SVG existe, sim

    • Principais elementos de animação SVG: set, animate, animateTransform, animateMotion
    • Mais detalhes: material sobre animação SVG

  • Pelo que sei, hoje em dia vídeos sem áudio (por exemplo, mp4) costumam comprimir melhor e por isso são mais usados no lugar de GIF

    • Fico curioso se Animated PNG consegue competir com formatos de vídeo como AV1

  • Na maioria dos serviços que aceitam upload de GIF, quase não há suporte a APNG ou animated WEBP

    • O suporte de backend é praticamente zero, o que é muito frustrante

  • Ao converter vídeos curtos em gráficos animados, o WEBP originalmente já era melhor que o APNG

    • Quando o GIF é usado como formato intermediário, o APNG até consegue competir
    • Hoje em dia, o AVIF é a melhor escolha

  • Alguns anos atrás tive experiência usando a biblioteca Lottie (Bodymovin)

    • Você cria animações no Adobe After Effects, exporta para svg e json, e depois aplica facilmente na web com lottie JS
    • Senti falta de ferramentas e de uma DX realmente boa para animações vetoriais na web
    • Também tenho curiosidade sobre ferramentas e DX no lado de animated PNG

• Entre as alegações no PR de que “muitos programas já suportam a nova especificação de PNG”

  • A menção de que o Photoshop suporta APNG está errada

    • Fiquei decepcionado porque o reconhecimento de APNG aparece como o segundo item em What's new, mas na prática o Photoshop não suporta isso

  • O Photoshop suporta a parte de HDR, mas não a de APNG

• Alguém comentou que as pessoas deveriam conseguir gerenciar por software a incerteza de hora/data de forma consistente

  • Algo como “a foto foi digitalizada em 2025, o conteúdo é por volta da Páscoa, entre 1920 e 1940” exige tratamento de informação temporal ambígua

  • O EXIF tem o campo DateTimeDigitized

    • Para datas ambíguas, existe a especificação EDTF
      • Referência: explicação de campos EXIF, documentação oficial da especificação EDTF

  • No Google Fotos e no Apple Photos é possível definir a data manualmente, mas isso não é gravado de fato no EXIF

    • Ao migrar de plataforma, imagens sem EXIF acabam perdendo também essas informações de data