Deslocamento do centro do campo e costuras de integração
Quando você acumula dados ao longo de várias noites, ou integra dados capturados com vários conjuntos de equipamento, os centros de campo de cada conjunto muitas vezes não coincidem entre si — às vezes porque o ângulo de rotação do campo do equipamento é diferente, às vezes porque, por algum motivo, o apontamento se deslocou. Isso deixa costuras evidentes depois da integração. A boa notícia: na maioria dos casos essa situação não exige refazer as capturas; basta usar os parâmetros corretos no alinhamento e na integração para que a costura possa ser eliminada quase por completo. Não desperdice um único pixel conquistado com tanto esforço.
Mesmo 45 graus de diferença de rotação do campo podem ficar sem costura
Deparei com esse problema logo na primeiríssima vez em que tentei integrar fotos capturadas com dois conjuntos de equipamento diferentes: embora fosse o mesmo alvo e as distâncias focais dos telescópios fossem semelhantes, os campos das duas câmeras acabaram diferindo exatamente em 45 graus, de modo que os quatro cantos não podiam se sobrepor, e empilhá-los diretamente produzia uma fronteira de sobreposição evidente.

Após um alinhamento e uma integração adequados, não se percebe nenhum vestígio de fronteira. Vale lembrar que tudo isso se sustenta sobre uma premissa: a calibração dos flats precisa ser bem-sucedida. O deslocamento do campo em si tem pouco impacto; a menos que você amplie muitíssimo, praticamente não se vê, sobretudo ao usar uma câmera monocromática. Para dois conjuntos de dados como estes, com 45 graus de diferença de rotação do campo, a diferença de relação sinal-ruído (S/R) nos quatro cantos após a integração só se percebe ao ampliar com cuidado até 300%.

Usar a rejeição para devorar as zonas pretas “não sobrepostas”
Vejamos outro exemplo de deslocamento do centro. Ao processar M51, eu tinha dois conjuntos de imagens, A e B; no conjunto B, como o OAG apontava para uma estrela brilhante, o centro da imagem não recaía sobre a própria M51. Depois de alinhar o conjunto B ao conjunto A (que é “centrado em M51”), nas imagens alinhadas do conjunto B as partes que não cobrem a área correspondente de A aparecem completamente pretas.

A chave está em que, na integração final de A e B, você escolhe um método de rejeição adequado para rejeitar (reject) todas aquelas partes pretas, e a costura torna-se totalmente invisível — mesmo a uma ampliação de 400 a 500%. Não poucas pessoas vão pensar “é só refazer as capturas”, mas isso, na verdade, é desperdício de dados: o conjunto B tem 15 poses só no canal L, de 20 minutos cada, e refazer as capturas até a mesma posição do conjunto A significaria gastar, só no canal L, pelo menos mais de 5 horas. Desde que M51 ainda esteja dentro do enquadramento da imagem, aproveitando bem o pré-processamento a coisa se resolve — para que recomeçar do zero?
Não negligencie as costuras nos canais de cor
Ao lidar com o deslocamento do campo, há ainda uma armadilha fácil de negligenciar: a costura se manifesta de maneira diferente em cada canal.

Novamente, dois conjuntos de imagens cujos campos não se sobrepõem: o canal de luminância (L), como o número de poses de cada lado da fronteira é mais ou menos igual, não mostra diferença após a integração (imagem à esquerda); mas, entre os canais de cor, o canal azul, como a diferença no número de poses de cada lado da fronteira é grande, tem uma relação sinal-ruído nitidamente diferente, de modo que surge uma fronteira (imagem do meio). Como resultado, após a combinação LRGB, o canal azul, de pior relação sinal-ruído, faz com que a imagem final ainda mostre a fronteira (imagem à direita).
Portanto, a conclusão é clara: os canais de cor são tão importantes quanto o canal de luminância, e ambos influenciam a qualidade da imagem final. Se um dos dois lados não for bem tratado, ele basicamente puxa o produto acabado para baixo. Em vez de se apegar a afirmações do tipo “um L de 5 minutos salvou 4 horas de RGB”, é melhor tratar com honestidade e a fundo os problemas próprios de cada canal — e tudo isso, na verdade, pode ser verificado por meio de experimentos no software, em vez de se fiar em anedotas de aparência plausível.