O que o HDR do celular faz com a sua foto: são dois arquivos num só

Duas coisas diferentes acontecem quando você aperta o botão

O conselho que circula sobre HDR no celular é binário: ligue na paisagem, desligue no retrato. Ele erra porque trata HDR como um botão só. Na prática são dois processos distintos, e o que separa os dois é o que sobra dentro do arquivo depois que a foto sai do aparelho.

O primeiro processo é a fusão de exposições. O manual da câmera do iPhone descreve isso sem rodeio: "a câmera do iPhone tira várias fotos rápida e sucessivamente em exposições diversas e as mescla para trazer mais detalhes de altas luzes e sombras às suas fotos", e a mesma página afirma que, por padrão, o iPhone tira fotos em HDR na câmera traseira e na frontal quando isso for mais efetivo (consultado em 19/08/2026). O resultado dessa mesclagem vira pixel na imagem que você recebe. É definitivo: ninguém desfaz depois, e ele viaja com o arquivo para todo lado.

O segundo processo é o mapa de ganho. Aqui o celular não altera a foto: ele anexa uma instrução. A especificação do formato Ultra HDR, do Android, é literal sobre onde essa instrução mora: "the gain map is stored in a secondary image JPEG", ou seja, o mapa é guardado numa segunda imagem JPEG dentro do mesmo arquivo. Quem sabe ler soma as duas coisas e mostra a versão com brilho estendido. Quem não sabe ler mostra só a primeira.

Confundir os dois leva ao conselho errado. Quem manda desligar o HDR porque a foto fica apagada no envio está pedindo para você desligar o processo 1 para tratar um sintoma do processo 2: a fusão não devolve brilho nenhum do outro lado, e ainda cobra detalhe na sombra do rosto. Já quem reclama que o rosto saiu chapado está reclamando da fusão, e aí sim o botão da câmera é o lugar certo de mexer. Dois processos, dois sintomas, duas correções.

Este artigo trata do arquivo e dos bytes. Se o seu sintoma é a cor mudando de aparelho para aparelho, o problema é outro e o blog já tratou dele: cor e faixa dinâmica são dois defeitos diferentes. Aqui a pergunta é mais estreita: o que exatamente o celular gravou, quanto isso pesa, o que apaga esse pedaço e como você descobre em dois minutos se o seu arquivo ainda carrega o mapa quando chega do outro lado.

Eu abri sete fotos de celular e contei os bytes

Nenhuma página em português que trata de HDR no celular abre o arquivo. Então eu abri. Baixei sete JPEGs das amostras oficiais do Google, no repositório android/platform-samples, e li os marcadores de cada um com um script em Python de biblioteca padrão, sem instalar nada: ando pelos segmentos até o início da varredura, acho o marcador que fecha a primeira imagem, procuro um segundo início de JPEG depois dele e leio os metadados. Python 3.14.3, macOS 15.6, tudo em 19/08/2026. Para quem quiser conferir byte a byte, o arquivo principal é o night_highrise.jpg, com 2.789.951 bytes e sha256 iniciando em fc65751d1ab20f6d.

Seis dos sete carregam mapa de ganho. O sétimo, um arquivo de Galaxy S23 Ultra que entrou como controle, não carrega nada: é uma foto e só. Já dá para descartar a generalização mais comum do assunto, que é dizer que "todo celular grava HDR no arquivo".

O que existe dentro dos seis é mais específico do que a palavra HDR sugere. O mapa é um segundo JPEG de um canal só, enquanto a imagem principal tem três. Ele tem exatamente um quarto da largura e um quarto da altura da imagem principal: 4.080 x 3.072 px viram 1.020 x 768 px. Isso não é coincidência, é o que a especificação recomenda, com o exemplo de um mapa de 480 x 270 px para uma imagem de 1.920 x 1.080 px. Em cinco dos seis a razão bateu 4,00 cravado; no train_station_night.jpg deu 4,08.

O segundo elemento é como o mapa fica grudado na foto. A especificação descreve os dois metadados: o mapa é armazenado como imagem adicional no padrão Multi-Picture Format (CIPA DC-x 007-2009) e "is appended to a primary image with MPF and GContainer XMP metadata". Nos seis arquivos com mapa, o marcador MPF estava presente e o XMP com os campos hdrgm também. Nenhum dos seis traz o metadado ISO 21496-1, o encapsulamento alternativo: são arquivos de 2023, anteriores ao Android 15.

O terceiro é o preço. O mapa custa entre 1,3% e 4,0% do arquivo. É a parte mais barata da foto e a primeira a se perder. Quem perde o mapa no caminho tem a sensação de ter perdido qualidade, e perdeu 3% de bytes e 100% de uma instrução.

O quarto é o alcance dessa instrução. O campo hdrgm:GainMapMax é, nas palavras da própria tabela de metadados da especificação, o logaritmo na base 2 do impulso máximo de conteúdo, isto é, a maior razão de luminância permitida entre a versão HDR e a versão base num dado pixel. Um valor de 3,022012 significa que o mapa autoriza até 8,1 vezes. Autoriza, não entrega: o fator de peso que decide o ganho real vem do sistema de exibição e, segundo o mesmo documento, pode mudar com o tempo. E o campo hdrgm:GainMapMin marcou 0,000000 nos seis, o que quer dizer que o mapa só clareia, nunca escurece: o piso é 2 elevado a 0, ou seja, 1 vez.

Vale a correção fina de vocabulário: o mapa de ganho não é uma segunda fotografia. É um segundo JPEG, de um canal só e um quarto do tamanho, que guarda a instrução.

O mapa não clareia a foto, clareia um pedaço dela

Essa é a parte que muda o diagnóstico e que nenhum tutorial de HDR conta. Decodifiquei os seis mapas e calculei o ganho pixel a pixel. Em quatro dos seis arquivos, mais de 80% do quadro recebe ganho 1,0x: night_highrise.jpg com 80,4%, lamps.jpg com 80,5%, train_station_night.jpg com 80,8% e desert_wanda.jpg com 90,6%. Traduzindo o que o mapa manda na maior parte da imagem: não mexa.

A exceção é justamente a cena que se parece com a sua reunião. O office.jpg é uma sala interna com uma janela grande de canto e luz do dia lá fora. Nele, só 15,3% do quadro fica em ganho neutro, a mediana já sobe para 1,16x e 18,2% da área pede mais de 2x. Quanto mais a sua foto parece "escritório com janela", maior a fatia da imagem que depende de um mapa que nenhuma recodificação no caminho preserva.

A consequência prática é específica. O que some quando o mapa é jogado fora não é o brilho geral da foto. É a separação das altas luzes: a janela atrás de você, o reflexo no vidro, a lâmpada do teto, o fio de luz na borda do cabelo. O seu rosto quase sempre está na região de ganho 1,0x, e por isso ele chega do outro lado praticamente igual ao que saiu.

Isso vira um teste de triagem barato. Se a foto inteira parece mais apagada depois de enviada, incluindo o rosto, o suspeito não é o mapa: é perfil de cor ou compressão. Se o que sumiu foi o contraste entre você e a janela clara atrás, aí sim o mapa era o que estava sustentando aquela leitura.

Um detalhe fecha a seção: quando você vai ler o histograma do arquivo, o gráfico que aparece é o da imagem principal, sem o mapa. É uma boa notícia, porque significa que a leitura de exposição que você faz ali já é a versão que o destino vai exibir.

Por que o destino mostra a versão apagada

O desenho do formato é retrocompatível de propósito, e a especificação do Android escreve a consequência numa frase: "legacy readers that don't support the new format read and display the conventional low dynamic range image from the image file". Ou seja, leitores que não suportam o novo formato leem e exibem a imagem convencional de baixa faixa dinâmica que está no arquivo. Este blog já usou esse mesmo literal onde a consequência discutida é aprovar a foto na tela errada; aqui ele serve para outra coisa, que é explicar o que sobra do arquivo.

A palavra "legacy" engana quem lê rápido. Leitor legado, nessa frase, não significa software velho: significa qualquer software que não implementa o formato, inclusive código escrito ontem. É por isso que o mecanismo é silencioso: ninguém dá erro, ninguém avisa, e o que chega do outro lado é uma foto perfeitamente válida, que por acaso é a menos vistosa das duas que estavam dentro do arquivo.

Do lado de quem exibe, o suporte não é automático nem por padrão. A documentação de exibição do Android instrui o desenvolvedor a definir o modo de cor da janela como COLOR_MODE_HDR para mostrar imagens Ultra HDR com a faixa dinâmica completa, depois de checar se aquele bitmap tem mapa. São duas decisões explícitas de quem escreve o app. A página oficial do formato registra que o Ultra HDR foi introduzido com o Android 14 e que, em aparelhos sem suporte, as imagens continuam aparecendo, só que em faixa dinâmica padrão.

Do outro lado do mercado, a Apple documenta um mapa com a mesma anatomia: a documentação de desenvolvedor descreve o mapa de ganho como um mapa de luminância de 8 bits e um canal só, guardado como dado auxiliar da imagem, com um quarto da resolução do original. A mesma página registra que a técnica foi proposta para padronização na ISO. Vale a precisão: Apple e Android não usam o mesmo encapsulamento, então os dois não são intercambiáveis, mas a forma do dado é a mesma.

A padronização saiu. A ficha oficial da ISO 21496-1:2025 registra edição 1, publicação em julho de 2025, 16 páginas e comitê ISO/TC 42, com escopo declarado de definir um mapa de ganho para conversão de faixa dinâmica entre duas representações da mesma imagem (ficha consultada em 19/08/2026). O texto da norma é pago, então nada além disso pode ser afirmado sobre o conteúdo dela. O relevante é o calendário: os arquivos que eu medi são de 2023 e não trazem esse metadado, e a especificação do Android diz que o Android 15 grava os dois encapsulamentos.

E o suporte do lado de quem lê ainda não é universal. No rastreador oficial da Mozilla, o pedido de suporte a JPEG com mapa de ganho segue com status UNCONFIRMED, aberto em 11/05/2023 e sem alteração desde 07/10/2023 (consultado em 19/08/2026). Isso é o estado de um registro num rastreador, não uma declaração de política de ninguém. Mas é uma evidência pública de que "software que lê o mapa" não é sinônimo de "software".

O que apaga o mapa é qualquer recodificação, inclusive a que não muda o tamanho

A segunda medição responde à pergunta que importa: em que momento exatamente o mapa some. Peguei um arquivo único de entrada, o night_highrise.jpg com 2.789.951 bytes e um mapa de 89.982 bytes, e passei esse arquivo por oito operações corriqueiras, gravando cada saída em q85 onde a ferramenta pede qualidade. Depois reavaliei cada saída com o mesmo script. Ambiente: macOS 15.6, sips do próprio sistema, Pillow 12.1.1 em Python 3.14.3 e sharp 0.34.5 com libvips 8.17.3 em Node v24.18.0. O sharp entra na lista de propósito: é o que roda por baixo de boa parte dos pipelines de imagem da web, inclusive o deste site.

O resultado é curto de resumir. A única operação que preservou o mapa foi não mexer no arquivo. Sete de sete transformações destruíram o segundo JPEG, e a mais reveladora é a segunda linha da tabela: recomprimir mantendo exatamente os mesmos 3.072 x 4.080 px, sem redimensionar nada, já apaga tudo. Não é uma questão de encolher a foto. É uma questão de reescrever o arquivo.

Faz sentido quando você olha o que essas bibliotecas enxergam. O Pillow abre o night_highrise.jpg como uma única imagem JPEG de 3.072 x 4.080 px em RGB e nem expõe contagem de quadros para esse arquivo: JPEG, para ele, é formato de imagem única, e o segundo JPEG não entra no inventário. O sharp devolve formato jpeg, largura 3.072, altura 4.080 e 3 canais. Nenhum dos dois está com defeito. Os dois estão fazendo exatamente o que a especificação prevê para quem não implementa o formato. Quando essas ferramentas gravam a saída, elas gravam o que leram, e o que leram foi a imagem principal.

Isso desenha a fronteira com um assunto vizinho. O que a compressão cobra depois disso é outra conta: lá o arquivo é espremido, perde detalhe fino e ganha artefato. O mapa de ganho não é espremido. Ele é descartado inteiro, antes, no momento em que alguém abre o arquivo sem saber que existe uma segunda imagem colada no fim. São duas perdas com causas diferentes, e por isso com correções diferentes.

Um limite obrigatório aqui: isto mede ferramentas locais, não plataformas. Eu não subi arquivo em rede social, mensageiro, e-mail ou formulário de vaga para medir o que cada um faz, e nenhum deles publica especificação sobre mapa de ganho. O que a medição sustenta é o mecanismo: onde há recodificação, o mapa não passa. Se você quer o veredito do seu destino específico, incluindo quando o suspeito é a própria plataforma, o teste da seção seguinte devolve a resposta em dois minutos.

O teste de 2 minutos, sem programa pago

Você não precisa acreditar em nada disso: dá para conferir no seu próprio arquivo. O script abaixo tem 50 linhas, usa só a biblioteca padrão do Python e não instala nada. Ele anda pelos marcadores do JPEG, encontra onde a imagem principal termina, verifica se existe um segundo JPEG depois dela e lê os metadados que interessam. Salve como mapa-de-ganho.py.

#!/usr/bin/env python3
# mapa-de-ganho.py - diz se um JPEG carrega mapa de ganho (o "HDR" do celular).
# Uso: python3 mapa-de-ganho.py foto.jpg   (só biblioteca padrão, nada para instalar)
import sys, re


def fim_da_primaria(b):
    """Anda pelos marcadores do JPEG e devolve onde a imagem primária termina."""
    i = 2
    while i < len(b) - 1:
        if b[i] != 0xFF:
            i += 1
            continue
        m = b[i + 1]
        if m == 0xDA:                       # SOS: começa a varredura da imagem
            j = b.find(b"\xff\xd9", i)      # EOI: o fim da imagem primária
            return j + 2 if j > 0 else None
        if m in (0xD8, 0x01) or 0xD0 <= m <= 0xD7:
            i += 2
            continue
        i += 2 + int.from_bytes(b[i + 2:i + 4], "big")
    return None


def pt(n):
    return f"{n:,}".replace(",", ".")


for caminho in sys.argv[1:]:
    b = open(caminho, "rb").read()
    fim = fim_da_primaria(b) or len(b)
    seg = b.find(b"\xff\xd8", fim)          # existe um segundo JPEG depois dela?
    mpf = b"MPF\x00" in b[:fim]             # Multi-Picture Format
    iso = b"iso:std:iso:ts:21496" in b      # metadado ISO 21496-1
    gmm = re.search(rb'hdrgm:GainMapMax="?\s*([\d.]+)', b)

    print(f"\n{caminho}  ({pt(len(b))} bytes)")
    print(f"  imagem primária       : {pt(fim)} bytes")
    print(f"  segundo JPEG embutido : {'sim, a partir do byte ' + pt(seg) if seg > 0 else 'não'}")
    if seg > 0:
        print(f"  tamanho do mapa       : {pt(len(b) - seg)} bytes "
              f"({100 * (len(b) - seg) / len(b):.1f}% do arquivo)")
    print(f"  MPF (Multi-Picture)   : {'sim' if mpf else 'não'}")
    print(f"  metadado ISO 21496-1  : {'sim' if iso else 'não'}")
    if gmm:
        m = float(gmm.group(1))
        print(f"  hdrgm:GainMapMax      : {m:.6f}  -> o mapa pode multiplicar "
              f"o brilho por até {2 ** m:.1f}x")
    print(f"  VEREDITO              : "
          f"{'CARREGA MAPA DE GANHO' if seg > 0 and gmm else 'sem mapa de ganho'}")

Em português: a função fim_da_primaria percorre os segmentos do arquivo até chegar no início da varredura da imagem e devolve a posição onde essa primeira imagem se fecha. O laço principal então procura um novo início de JPEG a partir dali, checa o marcador de Multi-Picture Format, procura o metadado ISO 21496-1 e extrai o hdrgm:GainMapMax do XMP para converter em multiplicador de brilho. Cada linha existe porque é exatamente esse conjunto que define o formato: segunda imagem, MPF e metadado. Se qualquer um dos três sumiu, o mapa foi embora.

Um limite do script, para você não tirar a conclusão errada: ele procura o encapsulamento do Ultra HDR, que é o do Android, dentro de um JPEG. Num arquivo de iPhone, que guarda o mapa como dado auxiliar da imagem e costuma sair em HEIC, o veredito vem como "sem mapa de ganho" porque o campo que eu procuro não está lá, e não porque o mapa não exista. Nesse caso, vale a versão sem terminal, logo abaixo.

Para testar num arquivo que você não precisa gerar, use a mesma amostra pública do Google que eu medi. São dois comandos:

curl -sO https://raw.githubusercontent.com/android/platform-samples/main/samples/graphics/ultrahdr/src/main/assets/gainmaps/night_highrise.jpg
python3 mapa-de-ganho.py night_highrise.jpg

A saída, executada em 19/08/2026:

night_highrise.jpg  (2.789.951 bytes)
  imagem primária       : 2.699.969 bytes
  segundo JPEG embutido : sim, a partir do byte 2.699.969
  tamanho do mapa       : 89.982 bytes (3.2% do arquivo)
  MPF (Multi-Picture)   : sim
  metadado ISO 21496-1  : não
  hdrgm:GainMapMax      : 3.022012  -> o mapa pode multiplicar o brilho por até 8.1x
  VEREDITO              : CARREGA MAPA DE GANHO

Agora o mesmo arquivo depois de passar por uma recompressão comum de servidor, com sharp em q85 e sem mudar um pixel de dimensão:

06_sharp_q85.jpg  (1.487.692 bytes)
  imagem primária       : 1.487.692 bytes
  segundo JPEG embutido : não
  MPF (Multi-Picture)   : não
  metadado ISO 21496-1  : não
  VEREDITO              : sem mapa de ganho

Um arquivo perdeu 1,3 MB e a linha inteira do mapa. É esse o momento em que a sua foto "desbota", e ele acontece antes de qualquer coisa aparecer na tela de alguém.

A versão sem terminal, para quem não quer rodar código

1. Abra a foto na galeria do celular e olhe bem o brilho das partes claras: a janela, a lâmpada, o reflexo.
2. Mande o arquivo para você mesmo pelo caminho que você usa de verdade (mensageiro, e-mail, upload no destino) e baixe de volta a versão que chegou.
3. Abra os dois arquivos lado a lado, na mesma tela, um do lado do outro.
4. Se a diferença aparece só na tela do celular e some no computador, o que mudou foi a faixa dinâmica, e o mapa era o responsável. Se a diferença aparece nas duas telas, o problema é outro: cor ou compressão.

Devo desligar o HDR para a foto de perfil? A régua por caso

Essa é a pergunta que traz a maior parte das pessoas até aqui, e a resposta honesta é: quase nunca vale desligar, e o motivo é diferente do que a busca sugere. Desligar o HDR não recupera brilho nenhum no destino, porque o brilho que some é o mapa, e o mapa já morre por conta própria em qualquer recodificação. O que você desliga é a fusão de exposições, que é justamente a parte que sobrevive.

Em contraluz, mantenha ligado. Quando a janela atrás de você é vários pontos mais clara que o seu rosto, a fusão de quadros é a única coisa trabalhando a seu favor, e o detalhe que ela recupera na sombra fica gravado na imagem principal. Esse ganho atravessa qualquer upload.

Em luz frontal uniforme, é indiferente na prática. É exatamente o cenário em que a medição mostrou a maior parte do quadro recebendo ganho 1,0x: sem alto contraste na cena, o mapa quase não tem o que autorizar, e ligar ou desligar muda pouco no arquivo final.

Em pele retinta, o risco é o inverso do que a busca sugere, e vale ser exato. O problema raramente é falta de brilho. É a fusão levantando a sombra que dá forma ao rosto: quando o processamento clareia demais a região de sombra, o volume some, e o rosto fica plano. E essa perda é a que fica gravada na imagem principal, sobrevive a todas as oito operações da tabela e é a versão que a IA recebe e que o perfil publica. O conserto não é botão, é luz. A sequência certa está no artigo sobre como medir a luz num rosto retinto antes de o celular decidir por você.

Onde desligar, quando você decidir que vale. O manual da Apple documenta o caminho Ajustes, Câmera, desativar HDR Inteligente apenas para iPhone 11, iPhone SE de segunda geração e iPhone 12. A página não descreve como fazer isso em modelos posteriores, e eu não vou preencher essa lacuna por ela. No app de câmera do Google, a ajuda oficial indica Configurações, Ajuste de HDR, Ativar ou Desativar; a própria página avisa que pode conter conteúdo traduzido com tecnologia de IA, e por isso o caminho vale como indicação, não como literal.

O critério para decidir sem chutar: fotografe a mesma cena duas vezes, com e sem o recurso, e compare o volume do rosto, não o brilho da janela. Se a versão com fusão entregar um rosto visivelmente mais plano, você tem um motivo real para desligar naquela luz. Fora esse teste, o botão não é onde está o seu problema.

O protocolo de 4 passos para entregar a versão que chega igual

A conclusão operacional de tudo acima cabe em quatro passos. A lógica é simples: se o destino vai mostrar a imagem principal, você deveria estar olhando para a imagem principal antes de decidir qualquer coisa.

1. Julgue fora do aparelho que gravou. O celular que tirou a foto é o único visualizador do mundo que tem, ao mesmo tempo, o mapa e a tela para exibi-lo. Aprovar ali é aprovar uma versão que quase ninguém vai ver.
2. Produza a versão achatada de propósito. Reabra e salve o arquivo por qualquer caminho que recodifique. A tabela acima mostra que serve qualquer um: encolher, recomprimir no mesmo tamanho ou converter de formato. O que sai é exatamente o que o destino enxerga.
3. Ajuste olhando essa versão, não a original. Se a versão achatada ficou apagada, o conserto é de captura, não de saturação. Vale rever como refazer a captura em vez de consertar o brilho depois, porque luz resolve o que editor não resolve.
4. Envie a versão achatada. Você deixa de perder um brilho que ninguém do outro lado ia ver e passa a controlar o que aparece. E ganha previsibilidade: dois destinos diferentes recebem o mesmo arquivo, e mostram a mesma coisa.

Há um custo declarado nesse protocolo, e ele é honesto: você abre mão do brilho estendido nos poucos lugares que sabem exibi-lo, como a galeria do próprio celular. Para foto de perfil profissional, essa troca vale quase sempre. Para uma foto pessoal que vai viver na galeria, não vale.

A foto que você manda para a IA é a imagem principal

Esse é o pedaço da história com consequência direta para quem usa IA para gerar retrato, e é onde o assunto deixa de ser curiosidade técnica. Quando um artigo de prompt manda anexar uma foto sua como referência, o arquivo que você anexa chega do outro lado como imagem principal: foi isso que o Pillow e o sharp devolveram, é isso que a especificação manda exibir para quem não implementa o formato, e qualquer redimensionamento antes do envio já teria apagado o mapa de todo jeito.

A frase que a medição autoriza é esta: o que a IA recebe é a versão base do seu arquivo, não a versão brilhante que você aprovou na tela do celular. Foi assim nas duas bibliotecas que testei em 19/08/2026, e é o comportamento que a própria especificação descreve para quem não implementa o formato. O que não dá para afirmar é o que um serviço de IA específico faz internamente com o seu arquivo, porque isso não foi medido e não existe documentação pública.

Na prática isso explica um sintoma comum: o retrato gerado sai mais escuro ou mais chapado do que a foto que você jurava ter enviado. A referência não mentiu, e o modelo não errou. Ele recebeu outra versão do mesmo arquivo. A correção é anexar a versão achatada, que é a que você consegue ver e avaliar. O resto do que decide um bom anexo está reunido em um capítulo só sobre a foto que você anexa, e não a que você publica.

Resumo e próximos passos

O que este artigo mediu, em cinco linhas, para você levar embora sem reler:

• O arquivo que sai do celular pode ser dois arquivos: uma foto de três canais e um mapa de um canal só, com um quarto da largura e da altura, colado no fim.
• O mapa custa entre 1,3% e 4,0% dos bytes nos seis arquivos que abri, e é a primeira coisa a se perder.
• Qualquer recodificação apaga o mapa, mesmo quando não muda um pixel de dimensão: sete de sete operações testadas o destruíram.
• O que achata o rosto não é o mapa, que morre no caminho: é a fusão de exposições, que fica gravada e atravessa tudo.
• Julgue a foto na versão que o outro lado recebe, nunca na tela que a gravou.

O passo seguinte depende do seu sintoma. Se a foto muda de cor conforme o aparelho, siga por outro caminho: o diagnóstico de cor é um assunto inteiro à parte. Se ela perde nitidez e ganha manchas quadradas depois do envio, a causa é compressão. E se o incômodo é o rosto em si, plano ou mal iluminado, o problema nasceu antes do arquivo, num lugar onde o brilho da cena é decidido com luz, e não com metadado: o guia de retrato que organiza a captura neste blog.