Desfase del centro del campo y costuras de integración

Cuando acumulas datos a lo largo de varias noches, o integras datos tomados con varios juegos de equipo, los centros de campo de cada conjunto a menudo no cuadran entre sí: a veces porque el ángulo de rotación del campo del equipo es distinto, a veces porque, por algún motivo, el apuntado se desplazó. Esto deja costuras evidentes tras la integración. La buena noticia: en la mayoría de los casos esta situación no requiere volver a fotografiar; basta con usar los parámetros correctos en el registro y la integración para que la costura pueda eliminarse casi por completo. No desperdicies ni un solo píxel conseguido con esfuerzo.

Incluso una rotación de campo de 45 grados puede quedar sin costuras

Me topé con este problema la primerísima vez que intenté integrar fotos tomadas con dos juegos de equipo distintos: aunque era el mismo objetivo y las distancias focales de los telescopios eran parecidas, los campos de las dos cámaras resultaron diferir justo en 45 grados, de modo que las cuatro esquinas no podían solaparse y apilarlas directamente producía un borde de superposición evidente.

Tras un registro y una integración adecuados, no se aprecia ninguna huella de borde. Conviene advertir que todo esto se sostiene sobre una premisa: la calibración de flats debe salir bien. El desfase de campo en sí influye poco; a menos que amplíes muchísimo, básicamente apenas se ve, sobre todo con una cámara monocroma. Con dos conjuntos de datos como estos, con 45 grados de diferencia de rotación de campo, la diferencia de relación señal-ruido (S/N) en las cuatro esquinas tras la integración solo se aprecia si amplías con cuidado hasta el 300 %.

Usar el rechazo de píxeles para comerse las zonas negras «no coincidentes»

Veamos otro ejemplo de desfase del centro. Al procesar M51 tenía dos conjuntos de imágenes, A y B; en el conjunto B, como el OAG apuntaba a una estrella brillante, el centro de la imagen no caía sobre M51 en sí. Tras registrar el conjunto B respecto al conjunto A (que está «centrado en M51»), las partes de las imágenes del conjunto B que no cubren el área correspondiente de A aparecen completamente negras.

La clave está en que, en la integración final de A y B, elijas un método de rechazo de píxeles adecuado y rechaces por completo todas esas zonas negras; así la costura se vuelve del todo invisible, incluso al 400-500 % de ampliación. No poca gente pensará «pues vuelvo a fotografiar y ya», pero eso en realidad es desperdiciar datos: el conjunto B tiene 15 tomas solo en el canal L, de 20 minutos cada una, y para volver a fotografiar hasta la misma posición que el conjunto A habría que dedicar, solo al canal L, al menos otras 5 horas y pico. Mientras M51 siga dentro del encuadre, aprovechando bien el preprocesamiento se resuelve; ¿para qué empezar de cero?

No pases por alto las costuras en los canales de color

Al lidiar con el desfase de campo hay otra trampa fácil de pasar por alto: la costura se manifiesta de forma distinta en los diferentes canales.

De nuevo, dos conjuntos de imágenes cuyos campos no se solapan: el canal de luminancia (L), como el número de tomas a ambos lados del borde es más o menos igual, no muestra diferencia tras la integración (imagen de la izquierda); pero el canal azul, dentro de los canales de color, como la diferencia en el número de tomas a ambos lados del borde es grande, tiene una relación señal-ruido claramente distinta, de modo que aparece un borde (imagen del centro). Como resultado, tras la combinación LRGB, el canal azul, con peor relación señal-ruido, hace que la imagen final siga mostrando el borde (imagen de la derecha).

Así que la conclusión es clara: los canales de color son tan importantes como el canal de luminancia, y ambos influyen en la calidad de la imagen final. Si uno de los dos lados no queda bien resuelto, básicamente lastra el producto acabado. En lugar de aferrarte a afirmaciones como «una L de 5 minutos salvó 4 horas de RGB», más vale que resuelvas con honestidad y a fondo los problemas propios de cada canal; y todo esto, en realidad, puede verificarse con experimentos en el software, en vez de fiarse de anécdotas que suenan verosímiles.