납품한 VFX 샷 색이 그레이딩실에서 달라졌다면: 플레이트 왕복 색공간 지키기

vfx 잡학지식 2026년 10월 17일 최종 수정 10월 13일 읽는 시간 약 14분

VFX 샷을 납품했는데 그레이딩실에서 다시 열어 보니 받은 플레이트와 색이 달라졌다면, 어느 단계부터 확인해야 할까요? 받은 플레이트와 같은 인코딩으로 돌려보내려면 어디서 색공간을 변환하고 어디서 되돌리는지 먼저 확인해야 합니다. 화면에서 비슷하게 보였다는 사실만으로는 반환 파일의 인코딩이 맞다고 판단할 수 없습니다.

이번 글에서는 플레이트 색공간 변환을 납품 왕복 기준으로 정리합니다. 확인할 것은 세 가지입니다. ① 받은 플레이트의 인코딩과 반환 규격, ② Nuke Read에서 작업공간으로 들어오는 변환, ③ Write에서 납품 인코딩으로 돌아가는 변환입니다. 마지막에는 실제 샷에 적용하기 전 검증하는 방법까지 살펴보겠습니다.

1. 플레이트 색공간 왕복 전에 반환 규격부터 확인합니다

플레이트 색공간 왕복의 출발점은 렌더 설정이 아니라 납품 규격입니다. ‘원본과 같은 색으로 반환’이라는 지시만으로는 충분하지 않습니다. 같은 인코딩으로 반환한다는 것이 무엇을 뜻하는지 먼저 합의해야 합니다.

입력 인코딩: 받은 플레이트의 실제 색공간, 색역, 감마 또는 전달 곡선
작업 기준: 쇼에서 지정한 OCIO config와 내부 작업공간
반환 규격: 출력 색공간과 곡선, 컨테이너·코덱, 비트 심도 및 필요한 메타데이터

예를 들어 원본 카메라 Log로 반환하라는 요청이 있다면 단순히 ‘Log’라는 이름만 확인해서는 안 됩니다. 어떤 색역과 Log 곡선을 사용하는지, 쇼 OCIO config에서 어떤 색공간으로 정의되어 있는지까지 일치해야 합니다. Log 곡선이 왜 카메라마다 다른지는 Log 영상이 뿌옇고 회색인 이유에서 정리했습니다.

쇼마다 config와 반환 규격이 다르므로 아래에서는 구체적인 색공간 이름 대신 ‘실제 입력 인코딩’, ‘쇼 작업공간’, ‘반환 인코딩’으로 부르겠습니다. 각 자리에 납품 문서에 적힌 값을 대입하세요.

플레이트 색공간 변환 흐름: Read에서 입력 인코딩을 작업공간으로 바꾸고 Write에서 합의한 납품 인코딩으로 출력, Viewer 변환은 별도 경로로 표시 — Read/Write 색관리 방식에서는 Read와 Write 두 경계에서 변환을 한 번씩 적용합니다. Viewer의 화면 표시 변환은 확인용이라 반환 파일에 굽지 않습니다. 흐름을 설명하는 개념도이며 실제 프로그램 화면이 아닙니다.

Read/Write 색관리 방식에서는 입력을 Read에서, 출력을 Write에서 변환합니다. 수동 노드 방식은 변환 노드가 경계를 맡을 수 있으며, 화면 표시 변환은 납품 파일과 별개인 확인용 경로입니다.

2. Read에서 입력 인코딩을 작업공간으로 변환합니다

Nuke에서 먼저 확인할 것은 프로젝트의 OCIO config와 working space입니다. OCIO 관리가 적용된 Read는 파일의 입력 색공간에서 내부 작업공간으로 변환합니다. Foundry의 OCIO Color Management 문서는 working space를 ‘파일이 Read에서 변환되어 들어오고 Write에서 변환되어 나가는 기준 색공간’으로 설명합니다.

다음 순서로 실제 스크립트를 점검하세요.

프로젝트가 쇼에서 지정한 OCIO config를 사용하고 있는지 확인합니다.
working space가 쇼에서 요구하는 작업공간인지 확인합니다.
Read 노드의 colorspace 설정이 받은 플레이트의 실제 입력 인코딩과 일치하는지 확인합니다.
Read의 변환 결과가 지정된 작업공간으로 들어가는 구성인지 확인합니다.

ACES config의 한 예에서는 scene_linear role이 ACEScg에 연결됩니다. 그러나 이것이 모든 쇼의 작업공간이 ACEScg라는 뜻은 아닙니다. 실제 프로젝트에서 사용하는 config와 working space를 기준으로 판단해야 합니다.

또한 Nuke 버전과 OCIO config에 따라 표시되는 항목이나 기본 선택이 달라질 수 있습니다. 파일 형식을 보고 Read의 색공간을 추측하거나 자동 선택값을 그대로 신뢰하지 말고, 실제 Read 노드에서 선택된 색공간을 확인하세요.

3. 화면 확인용 변환을 납품 파일과 구분합니다

Viewer에서는 작업공간의 값을 모니터에서 판단할 수 있도록 View 또는 Display 변환을 거쳐 보여줄 수 있습니다. 하지만 화면에서 보이는 모습이 곧 Write로 저장할 색공간은 아닙니다. 작업물을 확인하는 변환과 파일을 넘기는 규격을 따로 봐야 합니다.

ACES의 Output Transform은 특정 디스플레이와 시청 조건을 위한 렌더링 및 디스플레이 인코딩을 담당합니다. 따라서 이를 원본 카메라 Log로 되돌리는 변환과 같은 뜻으로 쓰지 않습니다. 그레이딩실이 별도 지시하지 않았다면 Viewer의 표시 변환을 납품 파일에 굽지 마세요.

여기까지는 입력 인코딩과 작업공간, 그리고 화면 확인 방식까지 살펴봤습니다. 이제 출력 규격을 실제 파일 변환에 연결하고, 중복 변환이 없는지 확인해야 합니다.

4. Nuke 색공간 설정에서 중복 변환을 막습니다

Nuke 색공간 설정을 점검할 때는 변환 노드의 존재뿐 아니라 이미 실행된 변환도 확인해야 합니다. Read에서 입력 인코딩을 작업공간으로 변환했다면, 바로 뒤에 같은 입력 변환을 OCIOColorSpace로 다시 수행해서는 안 됩니다.

Foundry의 OCIOColorSpace 문서에 따르면 이 노드는 input과 output 색공간을 지정해 변환합니다. Read/Write에서 담당할 변환과 별도 노드에서 담당할 변환을 명확히 구분해야 합니다.

수동 노드로 변환을 구성하는 별도 워크플로라면 흐름은 다음과 같습니다.

입력 직후 OCIOColorSpace에서 실제 입력 인코딩을 input으로, 쇼 작업공간을 output으로 지정합니다.
변환 이후 합성을 쇼 작업공간에서 진행합니다.
합성이 끝난 뒤 OCIOColorSpace에서 쇼 작업공간을 input으로, 반환 인코딩을 output으로 지정합니다.
최종 Write가 이미 수행한 변환을 다시 적용하지 않는지 확인합니다.

이것은 Read/Write의 OCIO 변환을 그대로 둔 상태에서 추가 노드를 넣으라는 뜻이 아닙니다. 각 변환이 실제로 어디에서 한 번 수행되는지 확인하는 것이 목적입니다. Read/Write 관리 방식을 사용한다면 동일한 OCIOColorSpace 변환을 별도로 추가할 필요가 없습니다.

OCIO config에서 색공간 간 변환이 어떻게 연결되는지 더 확인하고 싶다면 OCIO의 색관리 구조를 정리한 글을 참고할 수 있습니다. 현재 작업에서는 개념보다 실제 노드에 설정된 입출력 색공간을 우선 확인하세요.

5. Read·Write의 default와 raw data가 왕복을 깨는 경우

노드 구성이 맞아도 Read와 Write의 기본값을 그대로 두면 왕복이 틀어질 수 있습니다. Nuke는 색공간 메뉴에 default를 두고, 그 자리에서 실제로 쓰는 변환을 괄호 안에 표시합니다. Foundry 문서에 따르면 Read의 Input Transform과 Write의 output transform을 default로 두면 파일의 데이터 크기와 형식, 파일 헤더의 다른 정보를 바탕으로 LUT가 정해집니다. 따라서 default가 받은 플레이트의 실제 카메라 Log 인코딩을 항상 정확히 선택하거나 납품 규격에 맞는다고 보장할 수 없습니다. 괄호 안에 표시된 실제 변환을 입력·반환 규격과 각각 대조하세요.

설정	생기는 일	확인할 것
Read 색공간이 default	데이터 크기·형식과 헤더 정보를 바탕으로 한 변환이 적용돼 실제 촬영 인코딩과 다를 수 있음	괄호 안 변환 이름이 받은 플레이트의 인코딩과 같은지
Read raw data 켬	입력 변환을 건너뛰며, 일부 포맷은 YUV 변환 등 다른 처리도 생략할 수 있음	색관리 플레이트는 필요한 Input Transform 적용 여부를 확인하고, 비색 데이터는 Raw Data 사용
Write output transform이 default	데이터 크기·형식과 헤더 정보를 바탕으로 한 변환이 적용됨	괄호 안 변환 이름이 반환 인코딩과 같은지
Write raw data 켬	변환 없이 작업공간 값이 그대로 저장됨	Log 반환이 요구된 샷이면 끄고 output transform으로 지정
Write 타깃에 화면 표시 변환 선택	모니터용 톤이 파일에 구워짐	타깃이 display/view가 아닌 색공간인지
DPX transfer 헤더 자동	사용한 변환에 맞춰 헤더가 붙어, 받는 쪽 해석이 달라질 수 있음	헤더 값도 납품 규격과 같은지

raw data는 Read와 Write 모두에서 색변환 없이 데이터를 읽거나 저장하는 옵션입니다. Foundry 문서는 대부분의 파일 형식에서 raw data가 linear 색공간과 같은 동작을 하지만, 일부 형식에서는 YUV 변환 같은 추가 처리도 비활성화할 수 있다고 설명합니다. 따라서 작업공간이 선형이면 일반적인 색상 출력에서는 선형 값이 변환 없이 기록되고, 그레이딩실이 이를 원본 Log로 해석하면 밝기와 대비가 크게 다르게 보일 수 있습니다. 반대로 데이터 패스처럼 색변환하면 안 되는 출력은 raw data가 맞을 수 있으므로, 플레이트 반환용과 데이터 출력용 Read/Write를 구분하세요.

6. 플레이트 색공간 변환이 맞는지 무효과 왕복으로 확인합니다

본 샷을 납품하기 전에 무효과(no-op) 왕복 테스트를 합니다. 합성이나 색보정을 적용하지 않은 원본을 같은 설정으로 통과시켜 반환 결과를 확인하는 검사입니다.

원본 플레이트와 쇼 OCIO config를 준비하고 작업공간을 확인합니다.
Read에서 실제 입력 인코딩을 지정해 작업공간으로 변환합니다.
색보정이나 합성 효과를 추가하지 않고 Write까지 연결합니다.
Write의 출력 색공간과 파일 규격을 실제 납품 조건으로 지정합니다.
출력 파일을 다시 열어 반환 인코딩으로 올바르게 해석되는지 확인합니다.
그레이딩실에서도 같은 색관리 해석과 뷰 조건으로 원본과 왕복 결과를 비교합니다.

플레이트는 Read에서 입력 인코딩을 작업공간으로 변환하고, Write에서 합성 결과를 합의한 납품 인코딩으로 변환합니다. 원본 카메라 Log를 요청받았다면 Write의 타깃을 그 곡선과 색역이 지정된 정확한 색공간으로 설정하세요. 쇼가 다른 중간 형식을 요구하면 그 규격이 우선입니다.

여기서 테스트를 통과했다는 말은 픽셀 숫자가 원본과 완전히 같다는 뜻이 아닙니다. 같은 인코딩으로 되돌렸더라도 사용한 변환과 저장 방식에 따라 차이가 생길 수 있습니다.

OCIO 색공간 정의 문서는 scene reference를 기준으로 정방향과 역방향 변환을 설명합니다. 일부 LUT는 자동으로 역방향을 계산할 수 있지만, 역방향 정의가 없는 복잡한 3D LUT는 표시 전용으로 사용될 수 있습니다. 따라서 모든 변환 경로가 가역적이거나 무손실이라고 가정해서는 안 됩니다.

클리핑과 범위 제한, 정수화, 비트 심도, 코덱, 메타데이터 차이도 왕복 결과에 영향을 줄 수 있습니다. 테스트에서 차이가 보인다면 그 원인을 분리해 확인하고, 허용 가능한 오차는 실제 쇼의 납품 규격에 따라 판단해야 합니다.

7. 색이 다르게 보이는 범위로 검사 위치를 좁힙니다

그레이딩실에서 색이 달라졌다는 피드백을 받았다고 해서 곧바로 Write 설정이 잘못됐다고 결론 내릴 수는 없습니다. 차이가 화면 전체에서 나타나는지, 합성 요소에서만 나타나는지에 따라 먼저 살펴볼 경계가 달라집니다.

증상	우선 확인할 위치
화면 전체가 다름	Read 입력, Write 출력, 그레이딩실 해석·뷰 조건
CG 요소만 다름	CG 입력 색공간과 합성 작업공간
가장자리만 다름	색공간 변환 시 premult/alpha 처리

전체 화면의 차이는 우선 플레이트 입력과 납품 출력의 색공간 지정이 일치하는지 확인하고, 동일한 파일을 서로 다른 뷰 조건에서 비교하고 있지 않은지도 살펴봅니다.

CG 요소에서만 차이가 난다면 플레이트의 반환 경계만 확인할 것이 아니라 CG 소스가 쇼 작업공간에 올바르게 들어왔는지도 검사해야 합니다.

가장자리에서만 현상이 나타난다면 premultiplied 이미지의 변환 순서를 확인할 필요가 있습니다. 경우에 따라 색공간 변환 전에 alpha를 기준으로 unpremult하고, 변환 후 다시 premult해야 할 수 있습니다. Nuke OCIOColorSpace에서도 이러한 처리를 위한 설정을 제공합니다.

이 표는 원인을 확정하는 진단표가 아니라 검사 시작점을 정하는 기준입니다. 증상이 일치하더라도 실제 노드의 입력·출력 설정과 반환 파일의 해석 결과를 확인해야 원인을 좁힐 수 있습니다.