Nao Importa A Cor Do Ceu - Não importa a cor do céu, quem faz o dia lindo é você. - Simplesmente ...
Não importa a cor do céu, quem faz o dia lindo é você. - Simplesmente ...

Correção atmosférica em imagens de satélite: o que eu aprendi na prática

Vocês já tentaram fazer análise multiespectral de uma região e perceber que as nuvens estavam atrapalhando tudo, ou que a névoa atmosférica estava alterando os valores de reflectância de um ponto tal que não fazia sentido comparar com dados de outros dias? Foi isso que me levou a estudar métodos de correção atmosférica mais consistentes. A ideia central é simples, mas a execução não é. Depois de semanas testando diferentes pipelines, cheguei numa abordagem que funciona na maioria dos cenários reais.

O conceito por trás do nao importa a cor do ceu

Na prática, o princípio que eu uso se resume a isso: a cor do céu observada numa imagem de satélite não deveria determinar os valores de reflectância que você extrai do solo. O céu interfere. Ponto. Partículas na atmosfera espalham a luz de maneira seletiva — espalhamento Rayleigh pra comprimentos de onda menores, Mie pra partículas maiores — e isso faz com que bandas azuis e verdes sejam muito mais afetadas do que as banda de infravermelho próximo. Se você não corrige isso, qualquer índice de vegetação ou classificação que você fizer vai ser influenciado pelo estado atmosférico do dia da aquisição, não pelas condições reais da superfície. O que eu fiz foi padronizar o pré-processamento pra ignorar essa variável. Em vez de usar os valores brutos de reflectância top-of-atmosphere (TOA), eu aplico correção atmosférica com modelos como LEDAPS ou 6S, dependendo da constelação. O resultado é que a mesma área fotografada em dias com céus azul intenso, alaranjado (amanhecer/entardecer) ou até levemente nebuloso produz valores de reflectância de superfície consistentes entre si.

Um detalhe importante que poucos mencionam: a correção não é apenas sobre remover o "azul" do céu. Ela envolve estimar o óptic thickness atmosférico (AOD) e usar isso pra corrigir cada banda individualmente. Sem isso, você fica com imagens que parecem corretas visualmente, mas os números são inconsistentes quando você normaliza entre múltiplas datas.

Como eu monto o pipeline na prática

Primeiro, eu baixo os dados brutos. No meu caso, costumo usar Sentinel-2 L1C porque tem banda de aerosol (Banda 1) especificamente projetada pra estimar a espessura ótica. Landsat 8/9 também funciona bem, mas exige menos bandas pra correção. O dado precisa estar no formato COG ou TIFF com metadados completos de geolocalização. A partir dali, o fluxo segue estas etapas:

1. Conversão de DN pra reflectância TOA — isso é simples e direto. Cada banda tem seus coeficientes de ganho e bias registrados no metadado do arquivo. A Sentinel Hub ou o GDAL fazem isso automaticamente se você configurar corretamente. 2. Estimativa de AOD — usando a Banda 1 do Sentinel-2 (0.443 µm), eu calculo a reflectância aparente do aerosol. O modelo 6S resolve a equação de transferência radiativa pra estimar a espessura ótica. Existem ferramentas prontas como o sensor web do EOX ou o processamento via google earth engine, mas se você quer controle total, roda local mesmo.

3. Correção atmosférica completa — com o AOD em mãos, você aplica o modelo radiativo pra cada banda espectral. O resultado é reflectância de superfície (SR). Bandas como a B8 (NIR) são muito menos afetadas, mas as bandas visíveis (B2, B3, B4) recebem correções significativas — eu já vi diferenças de até 15% na reflectância após a correção em dias com alta umidade. 4. Homogeneização entre cenas — aqui é onde a maioria erra. Mesmo depois da correção, pode haver drift entre imagens de datas diferentes porque o sol varia em ângulo, e o modelo de correção assume condições padrão. Eu uso matching estatístico: seleciono pontos de referência (áreas urbanas estáveis, corpos d'água profundos que devem ter reflectância próxima de zero no NIR) e ajusto os valores pra que fiquem consistentes.

👉 Clique no botão abaixo para saber mais sobre o assunto!

Um problema real que eu encontrei (e como resolvi)

Num projeto de monitoramento de desmatamento na Amazônia, eu tinha seis cenas Sentinel-2 de diferentes meses. A correção atmosférica estava sendo aplicada corretamente, mas ao calcular o NDVI, algumas imagens mostravam índices absurdamente altos em áreas que eu sabia estarem degradadas. O problema era que o ângulo de iluminação solar variava bastante entre as datas — umas imagens foram capturadas perto do meio-dia, outras no final da tarde. A correção 6S padrão não ajusta pro ângulo de sun-zénite de cada aquisição. A solução foi adicionar um passo de correção geométrica do ângulo solar antes da correção atmosférica. Eu extrai os parâmetros de iluminação do metadado (solar zenith angle, solar azimuth) e apliquei uma correção BRDF (bidirectional reflectance distribution function) simplificada usando o modelo de Roujean. Isso alinhou os valores entre as cenas e o NDVI passou a fazer sentido temporalmente.

Esse ajuste técnico reduz o processo inicial em cerca de 20 minutos por cena, mas elimina a necessidade de retrabalho que antes me pegava por horas tentando entender por quê os dados não batiam.

Pegadinhas e limitações que ninguém conta

A correção atmosférica não é bala de prata. Existem cenários onde ela simplesmente não funciona bem: Céu nublado parcial: se há nuvens cumuliformes na cena, a correção atmosférica não resolve. Nuvens são espalhadores múltiplos, não unidirecionais. Você precisa mascarar as nuvens primeiro. Eu uso aQA do Sentinel-2 pra gerar um mask preciso, mas em áreas de cirros finos o mask falha. Nesses casos, o melhor é descartar a cena e aguardar outra passagem.

Regiões com alta umidade persistente: em florestas tropicais, a atmosfera é carregada de vapor d'água. O modelo 6S considera um perfil padrão de umidade, mas em períodos de chuva intensa a absorção por vapor pode ser 30% maior que o esperado. Isso distorce principalmente as bandas do infravermelho médio (B11 e B12 no Sentinel-2). A correção funciona, mas os valores absolutos ficam imprecisos. Pra indexação relativa (comparação temporal), ainda serve. Pra classificação absoluta de espécies vegetais, não. Dados Landsat em áreas costeiras: a correção atmosférica em zonas costeiras tende a superestimar a reflectância da água porque o espalhamento de partículas salinas não segue o modelo padrão de aerosol continental. Se você trabalha com Monitoramento costeiro, prefira Sentinel-2 ou adicione uma correção específica de aerosol marinho.

Alternativas quando o método tradicional falha

Se você está lidando com dados de alta resolução espacial (como Planet ou drones), a correção atmosférica padrão não escala bem. Nesses casos, eu recomendo usar targets de calibração em campo — placas de reflectância conhecida posicionadas na cena no momento da aquisição. É trabalho extra, mas é a única forma de garantir precisão subpixel. pra processamento em larga escala, o Google Earth Engine tem pipelines de correção atmosférica embutidos (Surface Reflectance) que já aplicam 6S + máscara de nuvens automaticamente. Não dá o mesmo nível de controle, mas economiza horas de configuração e é suficiente pra maioria dos projetos de monitoramento regional.

O fundo da questão é que "nao importa a cor do ceu" não significa ignorar o céu completamente. Significa que, depois de fazer o trabalho corretivo adequado, a cor que você vê no céu da imagem não deve mais contaminar os dados que você extrai do solo. Quando isso funciona, a consistência temporal melhora drasticamente e você consegue comparar áreas no verão e no inverno sem se preocupar com diferenças atmosféricas. Quem quiser implementar do zero, o pacote Sen2Cor (disponível via ESA) processa Sentinel-2 L1C direto pra L2A, e o LaSRC do USGS faz o mesmo pro Landsat. São as opções mais maduras hoje. Testei várias configurações manuais ao longo dos anos e, no fim das contas, essas ferramentas consolidadas entregam resultados mais confiáveis do que tentativas caseiras de correção.