DPX 플레이트의 흰색이 1.0이 아닐 때: Cineon 10bit의 95·685 코드값

DPX 플레이트를 Nuke에서 열었는데 화면이 뿌옇고, 흰 부분이 linear 1.0과 맞지 않아 보일 수 있습니다. 10bit라면 1023으로 나누면 된다고 생각하기 쉽지만, Cineon log DPX의 코드값은 linear 밝기값이 아닙니다.

그렇다면 기준 검정·흰색은 어디에 있고, 변환은 어디서 어긋날까요? DPX 파일의 색공간, Cineon의 기준값, 변환이 이미 적용됐는지 세 가지를 차례로 확인하겠습니다.

1. DPX는 색공간 이름이 아닙니다

10bit는 한 채널에서 코드값 0부터 1023까지 저장할 수 있다는 뜻입니다. 이 범위가 곧 linear의 검정부터 흰색까지라는 뜻은 아닙니다. DPX는 여러 색 표현을 담을 수 있는 파일 형식이며, 확장자만 보고 Cineon log라고 단정할 수 없습니다.

먼저 납품 노트와 샷의 색공간 지정, 프로젝트의 OCIO 설정에서 입력 공간을 확인합니다. 실제 Cineon log인데 변환하지 않으면 Log 화면이 낮은 대비로 보일 수 있습니다. 반대로 이미 변환된 입력에 Cineon 변환을 다시 걸면 밝기와 대비가 한 번 더 바뀝니다. Log 화면이 왜 회색으로 보이는지 더 알고 싶다면 Log 영상이 뿌옇고 회색으로 보이는 이유도 함께 확인할 수 있습니다.

2. 95와 685는 코드 범위의 양 끝이 아닙니다

Kodak Cineon 디지털 네거티브의 전형적인 기준은 10bit 범위 안쪽에 놓입니다. 정상 노출 기준에서 검정 쪽 기준은 필름의 Dmin에 해당하는 95이고, 90% 흰색 카드는 685, 18% 회색 카드는 470으로 기록됩니다.

대상	전형적인 코드값	읽는 법
필름 Dmin, 기준 검정	95	10bit 최솟값 0과 다릅니다.
18% 회색 카드	470	정상 노출 Cineon 예시의 중간 회색 기준입니다.
90% 흰색 카드, 기준 흰색	685	10bit 최댓값 1023과 다릅니다.
표현 가능한 코드 상한	1023	저장 가능한 코드 범위의 끝입니다.

95와 685는 필름 스캔을 해석하기 위한 기준점이지, 파일 값의 바닥과 천장이 아닙니다. Cineon은 네거티브 필름의 인쇄 농도 정보를 담기 때문에, 코드값을 단순히 0에서 1로 나눈 값처럼 읽을 수 없습니다.

또 685를 모든 샷의 고정 흰색으로 취급해서도 안 됩니다. Kodak 가이드는 실제 장면의 노출에 따라 reference white가 685보다 높을 수 있어 변환 전에 장면의 흰색 기준을 지정해야 한다고 설명합니다. 여기서부터 질문이 남습니다. 같은 코드 685가 왜 어떤 변환에서는 1.0이고, 1023까지의 값은 어디로 가는 걸까요?

3. 변환이 어긋나는 지점은 세 곳입니다

첫째, 코드값을 1023으로 나눠 linear라고 부르는 경우입니다. 예를 들어 685를 1023으로 나누면 약 0.670입니다. 하지만 이는 저장된 정수 코드를 전체 범위로 정규화했을 뿐입니다. 로그 코드값을 linear 빛으로 되돌린 결과가 아닙니다.

둘째, 실제 스캔의 기준점과 기본값이 다른 경우입니다. 기준 흰색을 685로 고정했는데 해당 플레이트의 노출·스캔 기준이 달라졌다면 전체가 밝거나 어둡게 보일 수 있습니다. 95와 685는 흔한 시작값입니다. 납품 명세에 다른 black/white 기준이나 LUT가 지정돼 있으면 그 값을 우선합니다.

셋째, 자동 변환과 수동 변환을 겹쳐 적용하는 경우입니다. Nuke는 입력 색공간 설정에 따라 읽을 때 이미 Cineon을 변환할 수 있습니다. 그런 상태에서 Log2Lin 노드를 또 적용하면 변환이 중복될 수 있습니다. OCIO가 어느 지점에서 색을 바꾸는지 헷갈린다면 OCIO의 입력 색공간과 변환 구조를 먼저 정리해 보세요.

마지막으로 기준 흰색 위의 코드를 8bit 출력이나 뷰 단계에서 먼저 잘라내면 하이라이트 디테일이 사라집니다. 오래된 8bit 변환 절차는 685 위를 클립할 수 있지만, 모든 float 변환이 똑같이 동작하는 것은 아닙니다. 선형 float와 EXR이 1.0보다 큰 값을 다루는 이유는 VFX에서 EXR을 쓰는 이유와 이어집니다.

그러면 기준 변환에서 실제 코드 470은 얼마가 되고, 기준 흰색 위 값은 어떻게 남을까요? 이제 코드값을 직접 식에 넣어 보겠습니다.

4. Cineon 코드값을 linear로 직접 계산합니다

아래는 Sony Pictures Imageworks의 Nuke-default OCIO Cineon 변환식입니다. CV는 0–1로 정규화한 숫자가 아니라 DPX 채널의 10bit 정수 코드값입니다. b는 코드 95를 출력 0으로 맞추는 black offset입니다.

b = 10^((95 - 685) / 300)
  = 0.01079775...

L(CV) = [10^((CV - 685) / 300) - b] / (1 - b)

18% 회색 카드의 전형적인 코드 470을 대입하면 10^((470-685)/300) = 0.192014입니다. 이를 black offset으로 보정하면 L(470) = (0.192014 - 0.010798) / (1 - 0.010798) ≈ 0.183이 됩니다. 즉 이 변환에서는 470이 약 0.18에 해당합니다.

입력 코드 CV	변환 결과 L	의미
95	0	기준 검정
470	약 0.183	18% 회색 카드의 전형적인 값
685	1.0	이 변환에서 기준 흰색
760	약 1.787	기준 흰색보다 밝은 코드

이 식에서는 685가 1.0이고, 685보다 높은 값은 1.0을 넘을 수 있습니다. 1023은 10bit 코드가 저장할 수 있는 상한이지, 이 Cineon 변환의 흰색 기준이 아닙니다. 다만 앱의 설정이나 뒤이은 클립·뷰 변환이 하이라이트를 자를 수 있으므로 숫자가 남는지 확인해야 합니다.

이 계산은 특정 OCIO Cineon 곡선의 예시입니다. Foundry의 Nuke Log2Lin 노드는 black=95, white=685, gamma=0.6 같은 조절값을 노출합니다. 프로젝트가 지정한 노드나 LUT가 있다면 그 설정을 확인하고, 위 식을 그 위에 다시 적용하지 않습니다.

5. 플레이트를 변환할 때 이 순서로 확인합니다

1. 소스 명세에서 픽셀 인코딩이 Cineon log인지 확인합니다. DPX 확장자만으로 추정하지 않습니다.
2. 납품처가 준 reference black/white, LUT, 노출 기준을 확인합니다. 지정값이 없을 때만 95/685를 전형적인 출발점으로 봅니다.
3. Nuke Read 또는 OCIO에서 변환이 자동 적용됐는지 확인합니다. 수동 노드를 추가한다면 중복 변환이 없는지 살핍니다.
4. 기준 패치와 하이라이트를 raw 코드값 및 변환 후 float 값으로 확인합니다. 코드 685가 1.0에 맞는지, 그 위 값이 남는지 확인합니다.
5. 표시 화면에서만 흰색으로 뭉개지는지, 실제 데이터가 이미 클립됐는지 나눠 봅니다.

DPX 플레이트의 흰색을 1.0으로 맞추는 기준은 코드의 최댓값이 아닙니다. 먼저 입력 색공간과 reference point를 확인하고, 변환은 한 번만 적용합니다.

외부 참고자료

기준값, 변환식, Nuke 동작을 원문에서 확인할 수 있습니다.