첫 DSLR 스택: RAW 파일 폴더에서 사진 한 장까지

트래커에 얹은 카메라는 RAW 파일로 가득 찬 메모리 카드를 만들어 내고, 거기서 사진 한 장까지의 간극이 대부분의 사람이 멈춰 서는 지점입니다. 단계가 어려워서가 아니라, 무엇을 어디에 넣고 그다음에 무슨 일이 일어나는지 아무도 분명하게 말해 주지 않기 때문입니다. 이 글은 그것을 말합니다. 실제 두 세션 - 플레이아데스를 찍은 Canon과 같은 카메라로 찍은 오리온 - 을 예로 들어, 소프트웨어가 각 단계에서 실제로 보고한 내용을 그대로 인용하면서요.

폴더

캘리브레이션에 관한 모든 것은 파일이 어디에 놓여 있느냐로 결정됩니다. 모든 튜토리얼이 가르치고 모든 스태킹 프로그램이 읽는 구조는 이렇습니다.

Pleiades/
  lights/    111 x IMG_7156.CR2 ...   the photographs of the sky
  darks/      37 x IMG_7260.CR2 ...   same exposure, same ISO, lens cap on
  flats/      17 x IMG_7290.CR2 ...   a plain, evenly lit surface
  biases/     17 x IMG_7724.CR2 ...   the shortest exposure the camera allows, cap on

최상위 폴더를 Akastroid에 끌어다 놓으세요. 네 개의 하위 폴더를 이름으로 읽고(dark/darks, flat/flats, bias/biases/offset 모두 됩니다), 무엇을 하기 전에 무엇을 찾았는지 먼저 보고합니다.

다크 37장, 플랫 17장, 바이어스 17장으로 캘리브레이션합니다.

RAW 파일에는 어떤 종류의 프레임인지 말해 주는 헤더 필드가 없으므로, 폴더가 곧 선언입니다. 다크를 lights/에 넣으면 아무것도 찍히지 않은 아주 나쁜 사진으로 등급이 매겨져 제외되는데, 올바른 결과이긴 하지만 어리둥절한 결과이기도 합니다.

라이트만 있어도 괜찮습니다. 세션은 캘리브레이션 없이 진행되고 그렇다고 말해 줍니다.

캘리브레이션 프레임이 감지되지 않았습니다. 라이트 프레임 최적화로 계속합니다.

그러면 핫 픽셀은 디모자이킹 전에 프레임 자체에서 통계적으로 복구됩니다. 이 순서가 중요한데, 핫 픽셀이 일단 이웃 픽셀로 보간되어 버리면 더 이상 고립된 점이 아니어서 찾아낼 수 없기 때문입니다. (각 캘리브레이션 프레임이 실제로 고치는 것.)

다크에는 무슨 일이 일어나는가

2400만 화소 다크 37장을 부동소수점으로 한꺼번에 메모리에 올리면 11기가바이트입니다. Akastroid는 세트가 2기가바이트 안팎에 들어가면 마스터 다크를 중앙값으로 만들고, 그렇지 않으면 이동 평균으로 만듭니다. 이 정도 크기의 세트에서는 결과 차이가 눈에 띌 만한 것이 아닙니다.

다크가 라이트와 맞는지도 확인합니다. 노출이나 ISO가 다른 다크는 다른 센서 상태를 측정한 것이고, 그것을 빼면 잔여 패턴이 남습니다. 맞지 않으면 세션이 그렇다고 알리고, 그래도 적용한 뒤, 다시 찍으라고 말해 줍니다.

다크가 라이트와 맞지 않습니다: 다크는 30초, 라이트는 120초로 노출되었습니다 …

실제 두 세션에서는 모두 맞았고 경고는 나타나지 않았습니다.

등급 매기기, 그리고 잃게 되는 프레임

모든 라이트가 측정됩니다. 별이 몇 개인지, 얼마나 선명한지, 얼마나 동그란지, 하늘이 얼마나 밝은지, 인공위성이 지나갔는지. 그다음 프레임들은 서로에 대해 점수가 매겨집니다. “초점이 좋다”는 말은 그날 밤의 나머지 프레임에 비교해서만 의미가 있기 때문입니다.

플레이아데스 세션은 111장 중 67장이 선택되었습니다. 나머지는 세션 자체의 기준선 아래로 떨어졌고 - 흐린 초점, 지나가는 구름 - 품질 판정은 “까다로움”이었습니다. 오리온은 134장 중 119장이 선택되었습니다. 두 세션 모두 같은 경고가 붙어 있었습니다.

세션 전체에 걸쳐 별이 약간 타원입니다(이심률 0.76). 추적이 아니라 광학의 문제 - 코마, 상면 만곡 또는 카메라 틸트 - 이므로 이 이유로 제외된 프레임은 없습니다.

마지막 구절이 중요합니다. 모든 프레임의 별이 타원이라면 그것은 렌즈이지 추적 오류가 아니고, 모두가 공유하는 결함을 이유로 프레임을 제외하면 스태킹할 것이 하나도 남지 않습니다. 앱은 세션 수준에서 한 번 알려 주고 넘어갑니다.

정렬

프레임은 마운트가 생각하는 지향 방향이 아니라 별 패턴을 기준으로 정렬됩니다. 카메라 렌즈는 화각을 약간 왜곡해서 - 모서리가 중앙과 조금 다르게 늘어납니다 - 통상적인 회전-이동 맞춤 뒤에 두 번째 패스가 맞춤에 신축까지 허용하고, 실제로 모서리 별을 더 가깝게 맞출 때만 그것을 유지합니다. 각 세션에서 몇 장의 프레임은 아예 대응을 찾지 못했고(플레이아데스 3장, 오리온 7장) 파일 이름과 함께 로그에 남긴 채 제외되었습니다.

통합

여기서 두 세션이 갈렸고, 로그는 그 이유를 말해 줍니다.

플레이아데스: 통합: 시그마 클리핑 - 64장 - 시그마 클리핑으로 궤적을 깔끔하게 제거할 만큼 충분히 깊음

오리온: 통합: 선형 적합 클리핑 - 세션 동안 하늘 레벨이 흘러간 112장 - 각 픽셀의 스택을 적합하면 흐름을 이상치로 오인하지 않고 이상치를 제거함

오리온의 하늘은 밤사이 밝아졌습니다. 단순한 시그마 클리핑은 모든 프레임을 같은 하늘의 표본으로 취급하므로, 완만한 흐름은 가장 이른 프레임과 가장 늦은 프레임이 이상치인 것처럼 보이고 - 그것들이 종종 가장 좋은 데이터입니다. 선형 적합 클리핑은 흐름을 먼저 맞추고 나서 남는 것을 제거합니다. 오리온은 픽셀 표본의 8.7%를 제거했고(DSLR의 핫 픽셀 집단에 흐름을 더한 것), 플레이아데스는 3.4%였습니다.

두 세션 모두 드리즐되지 않았고, 로그는 그 이유도 말해 줍니다. 별이 3.6픽셀과 3.9픽셀에 걸쳐 있었는데, 이 정도면 충분히 촘촘하게 샘플링된 것이어서 더 촘촘한 격자는 디테일을 되찾지 못한 채 파일만 키웁니다.

가장자리

화면 회전과 디더링은 몇 장의 프레임만 겹치는 너덜너덜한 가장자리를 남깁니다. 그 가장자리는 고정 비율이 아니라 실제로 있는 위치에서 잘립니다.

화면 회전으로 부분적으로만 덮인 프레임 가장자리를 잘라냈습니다 - 왼쪽 5 px, 오른쪽 40, 위 0, 아래 43.

색상과 그라디언트

두 세션 모두 배경 그라디언트가 제거되었고 화각 안의 별로 색이 보정되었습니다 - 플레이아데스는 1473개, 오리온은 1500개. 플레이아데스는 평면이 아니라 2차 그라디언트 모델이 필요했습니다. 렌즈의 비네팅이 녹색과 달리 빨강과 파랑에서 조금 다르게 나타나고, 플랫은 색보다 밝기를 더 정확하게 보정하기 때문입니다. 앱은 잔차에서 그것을 감지해 스스로 한 단계 올립니다. (보정에서 기준 별이 왜 중요한가.)

마무리

스트레치, 노이즈 제거, 별 처리, 대비는 완성된 선형 스택의 측정값 - 프레임의 얼마가 하늘인지, 가장 밝은 구조가 노이즈에 비해 얼마나 밝은지, 스택이 얼마나 깨끗한지 - 에서 맞춰지고, 로그는 결정 하나하나를 나열합니다.

배경 조정 - 프레임의 95%가 빈 하늘이므로 뿌옇게 되지 않도록 배경을 더 어둡게 설정 하이라이트 조정 - 프레임에 매우 밝은 중심부가 있으므로 구조를 유지하기 위해 하이라이트 보호를 높임

그 하나하나에 조정 탭의 슬라이더가 있고, 움직이기 전까지는 자동으로 있습니다.

얻게 되는 것

플레이아데스: 64장, 단일 프레임 대비 노이즈 4.5배 감소, 메로페와 마이아 주위의 반사 성운기가 보이고, 별은 모서리까지 동그랗습니다. 오리온: 112장, 노이즈 6.5배 감소, 트라페지움 영역은 흰색으로 날아가기 직전에서 멈추고, 러닝맨은 파랗고, 암흑 띠는 깨끗합니다.

둘 다 대회 출품작은 아닙니다. 둘 다 RAW 파일 폴더에서 4분 남짓 만에 나온 사진이고, 무엇을 왜 했는지 말해 주는 로그가 붙어 있습니다. 그것이 첫 스택입니다. 두 번째 스택은 로그를 읽고 거기에 이견을 내기 시작하는 곳입니다.

짧은 버전

• 한 폴더 아래에 lights/ darks/ flats/ biases/. 그 폴더를 끌어다 놓으세요.
• 앱은 무엇을 찾았는지, 다크가 맞는지 보고합니다. 그 줄을 읽으세요.
• 프레임은 세션에 대해 점수가 매겨집니다. 모든 프레임이 공유하는 결함은 어느 프레임도 제외할 이유가 아닙니다.
• 통합 방식은 데이터에서 골라지고, 로그는 어떤 방식을 왜 썼는지 말해 줍니다.
• 모든 자동 결정에는 슬라이더가 있습니다. 자동에서 시작하세요.