네온·LED의 진한 파랑 빛이 ACES에서 깨질 때: 색역 밖 값과 Gamut Compression

파란 LED를 찍은 플레이트가 Nuke에서 갑자기 마젠타로 밀리거나, 빛 가장자리에 계단처럼 끊긴 띠가 생길 때가 있습니다. ACES 색역 압축(ACES Gamut Compression)은 이때 시험할 수 있는 기술 보정이지만, 모든 파랑 문제와 밴딩을 고치는 만능 스위치는 아닙니다. 화면의 색만 보지 말고 올바른 입력 변환 뒤 AP1 채널에 음수가 생기는지 확인해야 합니다.

이 글에서는 세 가지를 순서대로 살펴봅니다. 먼저 파란 LED가 마젠타로 보이는 값의 경로, 다음으로 Reference Gamut Compression이 실제로 바꾸는 값, 마지막으로 Nuke에서 적용한 뒤 맞았는지 확인하는 방법입니다. ACES의 큰 구조부터 확인하려면 ACES 파이프라인 개요를 먼저 볼 수 있습니다.

파란 LED 마젠타 현상, 화면보다 채널 값을 먼저 봅니다

현장에서 촬영한 진한 파란 LED는 카메라와 렌즈가 기록한 값, 입력 변환, 합성 작업 공간을 차례로 통과합니다. 이 과정에서 소스의 색이 작업 색역 바깥으로 나가면 ACEScg(AP1) RGB 중 한두 채널이 음수가 될 수 있습니다. 파란 빛처럼 채도가 높고 밝은 영역에서 이런 값이 생기면, 합성 연산이 그 음수 값을 다루면서 색 가장자리가 깨지거나 Output Transform을 거친 화면에서 마젠타 solarization처럼 보일 수 있습니다.

여기서 중요한 건 ‘파랑이니까 파란 채널이 문제’라고 단정하지 않는 점입니다. AP1 밖 값은 R·G·B 중 한 채널만 음수일 수도 있고 두 채널이 음수일 수도 있습니다. 문제는 색 이름이 아니라 올바른 색공간 변환을 거친 선형 RGB 값이 작업 공간의 색역을 벗어났는지입니다. AP1·ACEScg와 sRGB의 차이는 ACEScg와 sRGB 비교에서 이어서 볼 수 있습니다.

ACES 색역 밖 값인지 Nuke에서 확인하는 순서

마젠타로 밀린 화면만 보고 RGC를 켜면 원인을 놓칠 수 있습니다. 먼저 입력 변환이 맞는지 확인하세요. 카메라 Log에 잘못된 IDT를 지정했다면 색이 크게 틀어질 수 있고, RGC는 잘못된 변환을 바로잡지 않습니다. 카메라 Log에서 ACEScg로 바꾸는 입력 변환 선택은 카메라 Log별 IDT를 고르는 글을 참고하세요.

1. Read의 입력 색공간을 확인합니다. 카메라 원본이면 카메라 Log와 gamut에 맞는 입력 변환을, ACES2065-1 EXR이면 ACES2065-1을, ACEScg EXR이면 ACEScg를 지정합니다. 이미 변환된 파일에 같은 변환을 다시 얹지 않습니다.
2. Viewer의 색만 보지 말고 같은 픽셀의 수치를 비교합니다. Nuke의 Windows 메뉴에서 Pixel Analyzer를 열고, RGC 앞뒤 노드에 연결한 Viewer에서 광원 가장자리의 같은 픽셀을 샘플링합니다. 분석기는 RGBA 값과 최소·최대 등을 보여 줍니다. 현재 Viewer의 표시 변환이 아니라 노드가 내보내는 값을 비교해야 합니다.
3. 밝은 파랑에만 음수 채널이 있는지 살핍니다. 입력 변환과 작업 공간이 맞는데 광원 주변 AP1 값 중 R이나 G가 음수이고, 그 부근에만 색이 깨진다면 RGC를 시험할 근거가 있습니다. 전체 화면이 한꺼번에 틀어지면 입력 변환이나 Viewer 설정부터 다시 확인합니다.

아래 그림은 ACES 1.3 Reference Gamut Compression 공식 수식으로 설명용 픽셀 하나를 계산한 결과입니다. 입력 AP1 값은 (-0.050, 0.100, 1.000)으로 가정했습니다. 이 값은 실제 카메라 프레임에서 측정한 값이 아니라, R 채널이 음수인 상황을 보여 주기 위해 만든 예시입니다.

ACES Gamut Compression: 어떤 값을 어떻게 누르나

Reference Gamut Compression(RGC)은 각 픽셀의 RGB 채널이 중립축에서 얼마나 멀리 떨어져 있는지 계산합니다. 일정한 거리 안에 있는 색은 그대로 두고, 채도가 매우 높은 값은 채널 비율을 압축해 중립축 쪽으로 옮깁니다. 그래서 ‘파란색을 정답 파랑으로 복원’하는 변환이 아니라, AP1 밖으로 튀는 값을 뒤쪽 합성·그레이딩에서 덜 문제 되게 다듬는 기술 보정입니다.

공식 임계값은 ColorChecker 24의 색을 건드리지 않는 보호 구간을 두고 정해졌습니다. 동시에 모든 극단값을 AP1 안에 가두는 것은 아닙니다. 공식 사양은 입력이 압축 한계를 넘으면 압축 후에도 AP1 밖에 남을 수 있다고 명시합니다. 따라서 값이 완전히 양수가 되지 않았다고 곧바로 구현 오류로 결론 내리지 말고, 카메라 입력 색역과 적용 위치를 함께 확인해야 합니다.

따라서 파란 LED가 마젠타로 밀릴 때는 노출이나 채도를 먼저 깎기보다, 올바른 IDT 뒤 AP1 채널의 음수 값을 확인하고 RGC를 합성 초기에 적용하는 것이 기본 경로입니다. 다만 이 처리가 원래 광원의 분광색을 알아내거나 미술 의도를 대신 정해 주지는 않습니다. 창작 그레이드는 RGC 뒤에서 조정합니다.

Nuke RGC 적용: ACES 1.3 OCIO Look을 Read 뒤에 둡니다

Foundry의 Nuke 17.1v2 문서는 기본 제공 ACES 1.3 OCIO config에서 RGC Look을 적용하는 절차를 안내합니다. 프로젝트 색관리와 Read 입력 변환을 먼저 맞춘 뒤, Read와 합성 노드 사이에 OCIO Look Transform을 둡니다.

1. Project Settings에서 Color를 엽니다. Color management를 OCIO로 바꾸고, 프로젝트와 맞는 ACES 1.3 config를 고릅니다. 팀이 제공한 커스텀 config라면 RGC Look이 정의돼 있는지 확인합니다.
2. Read의 색공간을 확인합니다. 입력 변환이 맞아야 RGC가 의도한 scene-referred 값을 받습니다. OCIO Look은 config에 정의된 process space에서 연산합니다. 공식 OCIO ACES Look은 ACES2065-1에서 RGC를 수행하고, OCIO가 필요한 색공간 변환을 앞뒤에 적용합니다.
3. Read 뒤에 OCIOLookTransform을 추가합니다. 기본 ACES 1.3 config라면 `ACES 1.3 Reference Gamut Compression` Look을 선택합니다. 커스텀 config에서는 Look 드롭다운을 열어 이름과 방향을 직접 확인합니다.
4. 같은 픽셀을 전후 비교합니다. Pixel Analyzer로 광원 가장자리 RGB를 확인하고, Viewer에는 같은 Output Transform을 유지합니다. 음수 채널이 완화되면서 마젠타 solarization이 줄어드는지 확인합니다. 변화가 없다면 변환 입력, 잘못 지정된 IDT, 이미 bake-in 된 RGC, 다른 원인을 다시 점검합니다.

앱이 RGC 수식을 직접 지원하지 않아 3D LUT로 대체해야 한다면 도메인을 확인해야 합니다. AP1 밖 값에는 음수 채널이 있을 수 있으므로 LUT 입력 Shaper가 음수 범위를 담아야 합니다. ACES 가이드는 마스터링·합성에서는 수학적 구현을 우선하고, LUT를 써야 한다면 높은 해상도와 tetrahedral interpolation을 권합니다. 경계에서 오차가 남으므로 3D LUT 구현은 역변환용으로 보지 않습니다.

마젠타 변색과 밴딩은 따로 진단합니다

‘계단’이라는 말만으로 원인을 하나로 묶을 수는 없습니다. 밝은 파랑 광원의 경계에서만 색이 뒤집히듯 깨지고 AP1 음수 채널까지 확인되면 RGC를 시험합니다. 반대로 하늘·안개·그라데이션 전반에 규칙적인 띠가 보이면 채널 양자화, 파일 출력 비트 깊이, 압축, 뷰어·모니터 경로를 따로 봐야 합니다. RGC는 색역 밖 값의 픽셀별 압축이지, 비트 심도나 dithering을 대신하지 않습니다. 일반적인 밴딩 점검은 그라데이션에 계단이 생기는 지점과 확인 순서를 참고하세요.

화면에서 보이는 증상	먼저 확인할 것	다음 행동
밝은 파랑 가장자리만 마젠타로 밀림	올바른 IDT 뒤 AP1 RGB의 음수 채널	RGC 전후 같은 픽셀을 비교
넓은 그라데이션에 여러 줄의 띠	원본·렌더·Write 출력 비트 깊이와 압축	RGC보다 밴딩 진단을 먼저 진행
장면 전체의 색·대비가 한꺼번에 변함	Read 색공간, OCIO config, Viewer Output Transform	IDT와 표시 변환을 단계별로 분리

합성에서 RGC를 중복 적용하지 않는 법

VFX용 원본 프레임은 RGC를 미리 구워 넣지 않은 AP0로 전달하는 것이 ACES 가이드의 기본 권고입니다. 합성자는 RGC를 어디에 둘지 선택할 수 있어야 합니다. 일반적으로 IDT 직후, 스케일·그레이딩·합성 전에 적용하지만, 블루스크린 despill처럼 압축 전의 값이 더 나은 작업은 원본 분기를 따로 사용할 수 있습니다. 이 경우에도 최종 합성 출력에는 파이프라인 약속에 맞춰 RGC가 한 번 적용되도록 합니다.

RGC가 이미 적용된 VFX 반환물을 DI에서 다시 처리하면 중복 압축이 됩니다. 반대로 적용을 빼먹으면 원본 플레이트와 리뷰용 WIP가 달라질 수 있습니다. AMF 등 메타데이터로 추적하거나, 당장은 샷별 상태를 문서화해 원본·중간본·최종본 중 어디에 bake-in 됐는지 전달하세요. RGC는 일반적인 룩 보정처럼 마지막에 넣었다가 납품 직전 역변환하는 처리가 아닙니다.

ACES 2를 쓰는 경우에는 한 가지를 더 나눠 봅니다. ACES 2 Output Transform에는 대상 디스플레이 색역을 고려하는 gamut compression이 들어 있습니다. 이는 scene-referred 값을 합성 초기에 다듬는 ACES 1.3 RGC와 적용 단계와 목적이 다릅니다. 화면에서만 보이는 색 이동인지, 합성 입력의 AP1 값에도 문제가 있는지 먼저 구분하고, Output Transform 뒤에 ACES 1.3 RGC를 무심코 덧붙이지 않습니다.

정리: 값이 먼저, 화면은 그다음

파란 LED가 깨져 보일 때는 올바른 입력 변환인지 확인하고, 같은 픽셀의 scene-referred RGB를 살핀 뒤, AP1 음수 채널이 문제의 에지와 맞물릴 때만 RGC를 적용해 전후를 비교합니다. 그라데이션 전체의 밴딩은 별도 출력 정밀도 문제로 진단합니다. OCIO 설정 전체가 낯설다면 OCIO config와 색관리 구조를, ACES 구성요소의 역할은 ACES 개요를 참고하세요.

한 줄로 정리하면, 파랑이 깨질 때는 색보정보다 먼저 AP1 음수 값을 확인하고, RGC는 합성 파이프라인에서 한 번만 적용합니다.

참고 문서