플레이트를 ACEScg EXR로 바꿨더니 노출이 틀어질 때: 카메라 Log별 입력 변환 고르기 (ARRI LogC·S-Log3·RED)

촬영 원본을 ACEScg EXR로 바꿨더니 플레이트가 뿌옇게 뜨거나 반대로 어둡고 진해졌다면, ACEScg 입력 변환을 고를 때 Grade보다 Read 노드에서 원본 Log와 색역을 먼저 확인하세요. 카메라가 기록한 Log와 색역을 다른 입력 변환으로 해석하면 밝기 단계마다 결과가 달라질 수 있습니다.

편집실에서 받은 LogC ProRes나 S-Log3 MXF를 Nuke에서 읽고, Write 노드로 ACEScg EXR을 뽑았습니다. 그런데 뷰어의 플레이트가 편집본과 다르게 보입니다. 이때 많은 사람이 Grade로 노출을 맞추고 넘어갑니다. 하지만 이 차이는 노출이 아니라 곡선의 차이라서, 한 군데를 맞추면 다른 밝기에서 다시 어긋납니다.

화면이 확 망가지는 경우는 차라리 쉽습니다. 더 곤란한 것은 플레이트가 거의 맞아 보일 때입니다. 그렇다면 눈으로 보고 그럴듯한 변환을 고르면 왜 안 될까요? 이 질문은 글 뒷부분에서 닫겠습니다. 순서는 세 가지입니다. 먼저 증상으로 실수의 종류를 가르고, 다음으로 카메라별로 골라야 할 이름을 정리하고, 마지막으로 고른 뒤 확인하는 방법을 봅니다.

Log 영상이 왜 회색으로 보이는지, ACES 파이프라인에서 입력 변환(IDT)이 어디에 있는지는 이미 다뤘습니다. 개념이 낯설다면 Log 영상이 뿌옇고 회색인 이유와 ACES 구조 설명을 먼저 보세요. 이 글은 인제스트 현장에서 목록의 어느 줄을 고르느냐에만 집중합니다.

1. 화면이 확 틀어졌다면: 변환의 종류가 틀린 것입니다

아래 그림은 같은 ARRI LogC3 테스트 차트를 입력 변환만 바꿔 읽은 결과입니다. 위 줄은 회색을 2스톱 간격으로 늘어놓은 것이고, 노란 테두리가 18% 회색입니다. 아래 줄은 피부, 빨강, 초록 같은 색 패치입니다. 모두 OCIO의 ACES Studio config로 실제 계산했고, ACES 2.0 SDR(Rec.709) 뷰로 표시했습니다.

Raw로 읽으면 뿌옇고 밝아집니다. Log 파일의 18% 회색은 코드값 0.391에 기록돼 있습니다. 변환 없이 이 숫자를 선형 값으로 믿으면 회색이 0.391이 되어 약 1.1스톱 밝아집니다. 더 큰 문제는 양 끝입니다. 어두운 곳은 4스톱 가까이 떠오르고, 밝은 곳은 4스톱 가까이 눌립니다. 그래서 전체가 안개 낀 듯한 회색이 됩니다. Nuke의 Read 노드에서 Raw Data를 켜면 색공간 변환을 하지 않으므로, RGB로 디코딩된 Log 값은 같은 방식으로 선형값처럼 읽힙니다. 다만 일부 파일 형식에서는 YUV→RGB 변환 등 다른 처리도 함께 꺼질 수 있어 결과가 정확히 같다고 단정할 수 없습니다.

sRGB 곡선으로 읽으면 하이라이트가 눌립니다. LogC3 테스트 차트를 sRGB 입력 변환으로 읽는 OCIO 계산에서 18% 회색은 ACEScg 기준값보다 약 0.51스톱 낮고, 회색보다 4스톱 밝은 단계는 약 2.76스톱, 6스톱 밝은 단계는 약 4.13스톱 낮게 복원됩니다. 이는 잘못된 곡선으로 밝기를 해석한 결과이지, 값이 1.0에서 잘린다는 뜻은 아닙니다. 회색 한 점만 맞춰도 밝은 영역의 간격이 어긋날 수 있습니다. sRGB 변환이 왜 텍스처용인지, 플레이트에는 왜 맞지 않는지는 ACEScg와 sRGB의 차이에서 다뤘습니다.

이미 ACEScg인 EXR에 카메라 변환을 한 번 더 걸면 어둡고 셉니다. 0.18이라는 선형 값을 Log 코드값으로 오해해 다시 풀기 때문입니다. 계산하면 회색은 0.017로 3.4스톱 어두워지고, 4배 밝은 값은 오히려 4.05로 튀어 오릅니다. 어두운 쪽은 음수가 되어 검정이 뭉개집니다. 다른 팀에서 받은 EXR을 원본 카메라 파일처럼 다룰 때 생기는 실수입니다.

보이는 증상	의심할 실수	고칠 곳
전체가 뿌옇고 밝다, 검정이 회색이다	Log를 Raw(선형)로 읽음	Read 노드의 Input Transform을 카메라 Log로
회색과 하이라이트 값, 단계 간 간격이 어긋난다	Log를 sRGB·Rec.709 곡선으로 읽음	같은 곳
아주 어둡고 대비가 과하다, 검정이 뭉개진다	변환된 EXR에 카메라 변환을 한 번 더	EXR은 ACEScg(또는 실제 저장 공간)로 읽기
회색은 그대로인데 채도·색조만 다르다	곡선은 맞고 색역이 다름	같은 Log의 다른 색역 이름으로
살짝 밝거나 어둡고 대비도 조금 다르다	다른 카메라의 Log 곡선	다음 절에서 확인

표의 마지막 줄이 이 글에서 가장 위험한 경우입니다. 위 세 가지는 보자마자 이상하다는 것을 압니다. 그런데 그림이 그럴듯하게 나오는 실수라면, 어떻게 알아챌 수 있을까요?

2. 거의 맞아 보인다면: Log 곡선을 잘못 골랐을 수 있습니다

카메라 회사마다 Log 곡선의 모양이 다릅니다. OCIO config로 18% 회색이 기록되는 코드값을 계산해 보면 LogC3는 0.391, S-Log3는 0.411, RED의 Log3G10은 0.333, ALEXA 35의 LogC4는 0.278입니다. 그래서 다른 회사 곡선으로 풀면 회색의 위치와 스톱당 간격이 함께 어긋납니다.

LogC3 파일을 S-Log3로 읽으면 회색이 0.27스톱 어두워질 뿐입니다. 반대로 S-Log3 파일을 LogC3로 읽으면 0.28스톱 밝아집니다. 이 정도는 촬영 때 노출을 조금 다르게 잡은 것과 구별이 안 됩니다. 두 곡선의 기울기가 비슷해서 밝은 곳과 어두운 곳의 오차도 0.25~0.46스톱 사이에 머뭅니다. 그래서 누군가 Grade로 0.3스톱만 올리고 넘어가도 한동안 아무도 모릅니다.

잘못된 입력 변환으로 만든 ACEScg EXR을 실제 촬영 Log로 변환하면 원본과 다른 값이 나올 수 있습니다. 반대로 같은 잘못된 변환과 그 역변환을 짝으로 쓰면 원본 코드값이 돌아올 수도 있습니다. LogC3를 Log3G10으로 읽은 계산에서는 회색이 0.91스톱, +6스톱 단계는 1.51스톱 밝아집니다. 회색을 맞춰도 +6스톱 단계에는 약 0.60스톱 오차가 남으므로, 한 번의 노출 보정으로 전체 톤을 맞출 수 없습니다.

아래 도구에서 직접 조합을 바꿔 보세요. 값은 OCIO로 미리 계산한 것으로, 선택한 Log로 기록된 회색 스텝을 다른 변환으로 읽었을 때 ACEScg에서 생기는 오차입니다.

몇 가지 조합을 눌러 보면 규칙이 보입니다. 회색 오차가 0.5스톱 안쪽인 조합이 생각보다 많습니다. S-Log3와 V-Log처럼 서로 바꿔 읽어도 회색이 0.2스톱 안쪽으로만 어긋나는 짝도 있습니다. 그럴듯해 보이는 것과 맞는 것은 다릅니다.

3. 카메라별 ACEScg 입력 변환 이름 고르기

그럼 무엇을 기준으로 고를까요? ACES Studio config의 카메라 입력 변환은 보통 Log 곡선과 색역을 구별할 수 있는 이름으로 표시됩니다. 다만 카메라 모델명이 아니라 촬영 설정과 정확히 대응하는 색공간 이름을 골라야 합니다. 아래 이름은 OpenColorIO-Config-ACES 저장소의 Studio config(v2.2.0 ACES 1.3판과 v4.0.0 ACES 2.0판)를 대조해 정리했습니다.

촬영 기록	config에서 고를 이름	확인할 것
ARRI ALEXA Mini, LF, 65 등 LogC3	ARRI LogC3 (EI800)	EI. config에는 EI800 하나뿐
ARRI ALEXA 35 계열 LogC4	ARRI LogC4	EI와 무관
Sony S-Log3, 색역 S-Gamut3.Cine	S-Log3 S-Gamut3.Cine	카메라 설정의 색역 이름
Sony S-Log3, 색역 S-Gamut3	S-Log3 S-Gamut3	같은 곳
Sony VENICE	S-Log3 Venice S-Gamut3 또는 .Cine	VENICE 전용 이름이 따로 있음
RED IPP2 (R3D 또는 내보낸 Log)	Log3G10 REDWideGamutRGB	Image Pipeline이 IPP2인지
Panasonic V-Log	V-Log V-Gamut
Blackmagic Gen5	BMDFilm WideGamut Gen5
이미 ACEScg로 뽑은 EXR	ACEScg	카메라 이름을 고르지 않음

Nuke 14.1 이후에 제공되는 ACES 1.3 config에는 AlexaV3LogC, SLog3, Log3G10처럼 짧은 별칭이 포함될 수 있습니다. 별칭은 별도 곡선이 아니라 config의 기본 이름으로 연결되는 표기입니다. 목록에 이름이 다르게 보이면 선택한 config의 별칭 매핑을 확인하세요.

목록을 열었는데 카메라 이름이 하나도 없다면 config부터 보세요. 확인한 ACES 1.3용 CG config v2.2.0에는 카메라 Log 입력 색공간이 포함돼 있지 않습니다. 색공간 이름 목록에는 ACES2065-1, ACEScg, ACEScc, ACEScct, sRGB·감마·선형 계열과 Raw 등이 있습니다. 촬영 플레이트를 카메라 Log에서 바로 변환하려면 해당 카메라 입력 색공간이 포함된 Studio config를 선택해야 합니다. config를 바꾸는 위치와 팀이 같은 파일을 써야 하는 이유는 OCIO 설명 글에 정리했습니다.

ARRI LogC3는 EI마다 곡선이 조금씩 다릅니다. ARRI의 VFX용 LogC 문서에 따르면 18% 회색은 모든 EI에서 0.391로 같고, 최대값과 기울기가 EI에 따라 바뀝니다. 같은 문서는 EI200~1600으로 찍은 영상을 EI800 파라미터로 풀어도 흰색 카드 밝기까지는 오차가 10% 미만이라 많은 경우 EI800으로 충분하다고 설명합니다. 문서의 파라미터 표로 직접 계산해 보니 회색은 오차가 없고, 흰색보다 밝은 곳에서 차이가 커졌습니다. EI200 영상을 EI800으로 풀면 회색보다 5스톱 밝은 값이 27% 밝게 나왔습니다. 창밖 하늘이나 조명처럼 하이라이트가 중요한 샷이면 실제 EI를 확인하세요. LogC4는 EI와 상관없이 같은 식으로 풀리도록 바뀌었으므로 이 걱정이 없습니다.

Sony는 곡선보다 색역 이름을 확인합니다. S-Log3는 하나지만 색역은 S-Gamut3와 S-Gamut3.Cine 둘입니다. 곡선이 같으니 잘못 골라도 회색은 그대로이고 색만 바뀝니다. 계산하면 S-Gamut3.Cine 파일을 S-Gamut3로 읽을 때 빨강 패치의 R값이 0.318에서 0.358로 올라갑니다. 노출은 맞는데 피부와 원색이 묘하게 다르다면 이 경우입니다.

RED는 파일이 IPP2인지부터 봅니다. RED 문서에 따르면 IPP2는 색역과 곡선을 REDWideGamutRGB와 Log3G10 하나로 통일했고, 그 전 방식은 REDgamma4와 DRAGONcolor2처럼 여러 조합 중 하나를 고르는 식이었습니다. Nuke의 Read 노드 문서를 보면 R3D를 IPP2로 읽을 때 Primary Color Space는 REDWideGamutRGB, Gamma Curve는 Log3G10으로 고정 표시됩니다. 이때 짝이 되는 입력 변환이 Log3G10 REDWideGamutRGB입니다. 옛 Legacy 조합으로 내보낸 파일은 Studio config v4.0.0 목록에 맞는 이름이 없으니, IPP2로 다시 받을 수 있는지 먼저 물어보는 편이 빠릅니다.

4. 이름은 그림이 아니라 파일 정보에서 읽습니다

이제 처음 질문에 답할 차례입니다. 눈으로 고르면 안 되는 이유는 앞에서 봤습니다. 잘못된 곡선 중 상당수가 노출 차이 정도로만 보이기 때문입니다. 그래서 답은 이렇습니다.

입력 변환은 그림이 아니라 파일 정보로 고르고, 그림은 고른 뒤 확인할 때만 씁니다.

파일 정보는 세 군데에서 나옵니다. 첫째는 Read 노드의 Metadata 탭입니다. Foundry 문서대로 파일이 가진 키가 그대로 보이며, ARRI 문서에 따르면 LogC3의 EI는 QuickTime과 MXF 메타데이터와 ARRIRAW 헤더에 들어 있습니다. 둘째는 촬영 리포트와 DIT 노트입니다. 감마와 색역 설정이 적혀 있는 경우가 많습니다. 셋째는 현상소나 편집실이 보낸 풀(pull) 노트입니다. 이미 ACES로 변환된 EXR을 받았다면 그 EXR이 ACES2065-1인지 ACEScg인지가 적혀 있어야 합니다.

EXR이라고 안심하면 안 됩니다. ACES Studio config v4.0.0의 파일 규칙은 확장자가 exr인 파일의 기본 색공간을 ACES2065-1로 지정합니다. 단, 실제 앱이 이 규칙을 기본값으로 따르는지는 앱과 설정에 따라 다릅니다. 내가 뽑은 ACEScg EXR을 받는 쪽이 ACES2065-1로 읽으면 노출은 그대로여도 색역이 바뀝니다. 계산에서는 피부 패치의 채도가 0.55에서 0.62로 올라가고 진한 파랑에 음수 채널이 생겼습니다. EXR이 어떤 선형 값을 담는 형식인지는 EXR을 쓰는 이유에서 다뤘습니다. 저장한 색공간을 받는 쪽에 함께 알려 주세요.

Read 노드의 기본값도 믿지 않습니다. Foundry 문서는 Input Transform 기본값이 데이터 크기와 종류, 파일 헤더 정보로 정해진다고만 설명합니다. 카메라 Log 파일이라면 기본값이 무엇으로 잡히든 직접 카메라 이름으로 바꿔 두는 것이 안전합니다.

5. 고른 뒤 맞았는지 확인하는 방법

정보로 고른 다음에는 그림으로 확인합니다. 다음 세 가지를 순서대로 보세요.

1. 되돌리기는 보조 검사로 씁니다. 원본 Log와 색역은 촬영 정보로 먼저 확인합니다. 그 정보를 바탕으로 ACEScg EXR을 실제 촬영 Log로 역변환하고, 같은 프레임의 원본을 Raw Data로 읽어 Merge(difference)로 비교합니다. 차이가 남으면 변환의 누락·중복, 색공간 선택, 데이터 범위, 압축 등을 살펴봅니다. 하지만 잘못된 변환과 그 역변환을 짝으로 쓰면 원본 코드값이 돌아올 수도 있습니다. 따라서 차이가 거의 없다는 결과만으로 입력 변환 이름이 맞다고 판단할 수는 없습니다.
2. 차트가 찍힌 컷이 있으면 회색 패치를 샘플합니다. 노출을 기준대로 맞춰 찍었다면 회색 패치는 ACEScg에서 0.18 근처에 옵니다. 촬영 때 일부러 노출을 바꿨을 수 있으니 이것만으로 단정하지는 않습니다. 대신 이 값이 1 근처로 크게 튀거나 0.02처럼 바닥에 붙어 있다면 1절의 실수부터 의심합니다.
3. 하이라이트 단계도 숫자로 확인합니다. 회색 스텝 차트가 있으면 ACEScg에서 각 단계가 기대한 밝기 간격으로 나오는지 샘플합니다. 장면 선형 값은 1.0보다 클 수 있으므로 Viewer 표시가 아니라 ACEScg 수치와 예상한 단계 간격으로 비교합니다. 촬영 원본 자체의 클리핑 여부도 따로 확인합니다.

세 가지 검사에서 큰 노출 오류가 없어도 색역 오류는 남을 수 있습니다. 회색 노출은 맞는데 CG와 플레이트의 채도나 색조가 다르면, 촬영 기록의 색역과 Read 노드 설정이 일치하는지 먼저 확인하세요. 그다음 라이팅과 그레이딩을 살펴봅니다.

정리: Grade보다 입력 변환, 입력 변환은 파일 정보로

ACEScg로 바꾼 플레이트가 뿌옇거나 어둡거나 미묘하게 다르다면 Grade 노드보다 Read 노드의 입력 변환을 먼저 봅니다. 화면이 크게 틀어졌다면 Raw, 비디오 곡선, 이중 변환 중 하나입니다. 거의 맞아 보인다면 다른 카메라의 Log 곡선이나 다른 색역을 골랐을 수 있습니다. 이름은 config의 "곡선 + 색역" 표기에서, 고를 근거는 메타데이터와 촬영 노트에서 가져옵니다.

플레이트가 틀어지면 Grade보다 입력 변환을 먼저 보고, 입력 변환은 그림이 아니라 파일 정보로 고르세요.

참고 문서

변환 이름과 버전, 노드 동작을 확인한 공식 문서입니다.