뷰어에서 맞춘 색이 렌더하면 달라질 때: 누크 뷰어 변환과 Grade 노드의 자리

Nuke Grade 노드가 바꾸는 것은 Viewer 화면에 보이는 픽셀이 아니라, Grade 입력으로 흘러온 이미지 값입니다. Foundry의 Grade 노드 문서도 이 노드가 입력 이미지의 밝기·색 값을 조정한다고 설명합니다. 그런데 Viewer에서 맞춘 색이 Write로 렌더한 파일에서 달라 보이면, Grade는 뷰 변환 앞의 장면 기준 값에서 해야 할까요, 화면 기준으로 해야 할까요?

먼저 세 가지를 나눠야 합니다. Grade가 받은 값, Viewer에만 적용된 변환, Write가 파일에 기록한 색공간입니다. 이 경계를 순서대로 보면 렌더와 화면이 왜 달라 보이는지 좁힐 수 있습니다.

Nuke Grade 노드는 화면이 아니라 입력값을 바꿉니다

Node Graph에서 Grade를 Read 뒤에 연결하면 Grade는 Read가 내보낸 이미지 데이터를 처리합니다. 화면에 색이 어떻게 보이는지는 그 다음에 Viewer가 표시하면서 적용하는 View Transform의 영향을 받습니다. Foundry 문서도 Viewer가 연결된 노드의 출력을 보여 줄 뿐, 데이터를 바꾸지 않는다고 설명합니다. Nuke Viewer 노드 설명을 보면 이 경계를 확인할 수 있습니다.

따라서 Nuke Viewer Process를 바꿔도 업스트림 Grade의 입력값이 자동으로 display-referred 값으로 바뀌지는 않습니다. Viewer의 View Transform은 화면에 보내기 위한 표시 경로에 있습니다. Viewer 색공간 변경이 렌더 출력에 영향을 주지 않는다는 점은 Foundry의 Viewer 색공간 설명에도 명시돼 있습니다.

Write도 Viewer와 다른 경로입니다. Write는 자신에게 연결된 노드의 출력을 기록하고, 선택한 Output Transform으로 작업공간에서 파일 색공간으로 변환할 수 있습니다. 그래서 Viewer에서 보이는 룩이 파일에 자동으로 구워진다고 가정하면 안 됩니다. Nuke OCIO 색관리에서 작업공간과 Read·Write 색공간이 정해지는 방식을 함께 확인하세요.

단, Viewer Process와 Node Graph 안에 실제로 연결한 변환 노드는 다릅니다. 그래프에 OCIOColorSpace나 OCIODisplay를 넣으면 그 변환은 다음 노드의 입력 데이터가 됩니다. OCIODisplay 노드는 입력 색공간, display, view transform을 지정해 이미지 시퀀스에 실제 변환을 적용합니다.

Grade 앞뒤에 변환이 끼면 같은 수치도 다른 결과가 됩니다

변환 전 Grade를 G, Viewer 또는 그래프 안의 색 변환을 D라고 해 보겠습니다. 앞에 둘 때는 D(G(x)), 뒤에 둘 때는 G(D(x))입니다. D가 비선형이면 두 계산은 보통 같지 않습니다. 화면에서 본 값에 맞춰 만든 Grade를 작업공간 픽셀에 그대로 적용할 수 없는 이유입니다.

숫자로 보면 차이가 분명합니다. 설명을 위해 선형 값 0.18에 Grade의 multiply=2를 적용하고, 단순 sRGB 전달함수만 통과시키겠습니다. W3C CSS Color 4에 정의된 sRGB 변환식으로 계산하면 아래처럼 나옵니다.

Grade 위치	계산	변환 뒤 값
변환 앞	0.18 × 2 = 0.36 → sRGB 변환	약 0.634
변환 뒤	0.18 → sRGB 변환 약 0.461 → × 2	약 0.923

이 숫자는 ACES나 특정 OCIO View Transform의 결과가 아닙니다. sRGB 전달함수만으로 연산 순서가 달라진다는 점을 보여 주는 예입니다. 실제 View Transform에 톤 매핑이나 색역 처리까지 들어가면 결과는 사용하는 OCIO config와 display/view에 따라 달라집니다.

하이라이트도 같은 원리로 봐야 합니다. 변환 뒤에 둔 Grade가 1보다 큰 값을 만들었다고 해서 그 순간 원본이 잘린 것은 아닙니다. Foundry Grade 문서상 white clamp 기본값은 꺼져 있습니다. 다만 이를 켜거나 뒤 단계에서 0–1로 제한하는 노드를 쓰면 초과값은 잘릴 수 있습니다. 반대로 black clamp는 기본값이 켜져 있어 0보다 작은 출력값을 0으로 제한합니다. 현재 결과가 걱정되면 Grade의 clamp 상태와 뒤쪽 노드를 직접 확인하세요.

Nuke OCIO 색관리에서 Grade가 받는 작업공간을 확인합니다

먼저 Project Settings > Color에서 Color Management 방식과 OCIO config, Working Space를 확인합니다. Foundry의 OCIO 문서에서 Working Space는 Nuke가 내부 이미지 처리를 하는 색공간으로 정의됩니다. OCIO config의 기본값은 보통 scene_linear 역할이지만, 선택한 config와 프로젝트 설정이 실제 기준입니다. 확인한 Foundry 문서는 Nuke 17.1v1/v2 기준이며, 이전 버전은 메뉴명이나 기본값이 다를 수 있습니다.

그다음 Read의 입력 색공간과 Write의 출력 색공간을 확인합니다. Read가 어떤 공간으로 변환돼 들어오고, Grade 이전에 실제 그래프 변환이 있었는지 봅니다. 작업공간과 출력 색공간의 역할을 처음 정리한다면 ACEScg와 sRGB의 작업·출력 색공간 차이가 이어집니다.

합성 중 노출이나 CG와 플레이트의 밝기 관계를 조절한다면, 보통은 Viewer 변환 앞에서 프로젝트의 작업공간을 기준으로 Grade를 둡니다. 작업공간이 scene-linear라면 scene-linear 색보정으로 장면의 밝기 관계를 다루는 방식입니다. 다만 모든 Grade를 반드시 scene-linear에서 해야 한다는 뜻은 아닙니다. Foundry 문서도 일부 연산은 CLog처럼 다른 색공간에서 더 잘 작동할 수 있다고 설명합니다. OCIOColorSpace 문서는 ACEScc에서 scene_linear로 변환해 Grade를 처리한 뒤 다시 ACEScc로 돌아오는 예를 보여 줍니다. Linear Workflow가 필요한 이유도 장면 기준 계산의 배경을 다룹니다.

특정 SDR이나 HDR 출력에 맞춘 최종 화면 조정은 목적에 따라 display-referred 공간에서 할 수 있습니다. 이때는 Viewer Process만 바꾸는 것으로 끝나지 않습니다. 선택한 변환을 그래프의 명시적 노드로 넣고 Grade를 그 뒤에 연결해야 합니다. 출력 파일에 그 변환과 Grade가 함께 포함되는지, Write에서 같은 변환을 한 번 더 적용하지 않는지도 확인하세요. OCIO의 display, view, reference 공간이 궁금하면 OpenColorIO의 구조에서 개념을 더 볼 수 있습니다.

뷰어와 렌더 색이 다를 때는 이 순서로 확인합니다

1. 비교 기준을 고정합니다. 같은 프레임과 같은 Viewer Process로 Grade 앞·뒤를 A/B 비교하세요. Viewer Gain이나 Gamma를 임시 조정했다면 원래 값으로 돌려놓고 비교합니다. 이 조절은 보기 경로의 상태이지, Grade 노드 값이 아닙니다.
2. Read와 Working Space를 확인합니다. Read가 원본 파일을 의도한 입력 색공간으로 해석하는지, Project Settings의 Working Space가 샷 규격과 맞는지 확인하세요. 프로젝트마다 기본값은 달라질 수 있습니다.
3. Grade 앞의 실제 변환 노드를 찾습니다. OCIOColorSpace, OCIODisplay, LUT 같은 노드가 앞에 있으면 Grade는 그 변환 결과를 받습니다. Viewer의 메뉴에서 선택한 Process와 혼동하지 마세요.
4. Grade의 입력과 출력을 직접 샘플링합니다. Grade를 Viewer에 연결한 상태에서 일반 클릭은 출력 샘플, Ctrl/Cmd+Alt+클릭은 입력 샘플입니다. 값이 기대와 다르면 multiply, offset, gamma, black/white point, black clamp, white clamp를 확인하세요.
5. Write의 출력 변환을 별도로 검증합니다. 납품 파일의 목표 색공간과 Write의 Output Transform이 맞는지 확인한 뒤 짧은 테스트를 저장하세요. 다시 읽을 때는 파일에 기록한 색공간을 Read 입력으로 지정하고, 처음과 같은 Viewer Process로 비교합니다. 다른 이미지 뷰어에서만 달라 보인다면 그 뷰어의 색 해석까지 별도로 확인해야 합니다.

Grade 문서는 Viewer에서 입력값과 출력값을 각각 샘플하는 방법을 제공합니다. 따라서 눈에 보이는 화면만 비교하지 말고, Grade가 실제로 받은 수치와 내보낸 수치도 함께 보세요. 이 절차를 밟으면 차이가 Grade 앞, Viewer 표시, Write 변환 중 어디서 생기는지 분리할 수 있습니다.

결론: 장면 기준 보정은 작업공간에서, 화면별 마감은 변환 뒤에서 합니다

일반적인 합성 보정은 Viewer 변환이 아니라 프로젝트의 작업공간에서 합니다. 장면의 밝기와 CG·플레이트 관계를 맞출 때는 Grade를 지정된 작업공간의 값에 적용하고, Viewer는 그 결과를 display/view로 살펴봅니다. 특정 출력 규격을 위한 display-referred 색보정은 의도한 변환을 그래프에 명시한 뒤, 그 출력 전용 Grade로 다룹니다.

정리하면 “화면에서 보고 조절한다”는 것은 맞지만, “Grade가 화면에 보이는 값에서 작동한다”는 뜻은 아닙니다. Nuke Grade 노드 앞의 입력 공간, 그래프에 넣은 변환, Write의 출력 공간을 각각 확인해야 합니다.

Viewer 전용 룩을 만들어 보는 작업은 ASC CDL로 Nuke Viewer 룩을 재현하는 글에서, 납품 파일로 변환을 넘기는 문제는 플레이트 왕복 색공간을 지키는 글에서 이어집니다. 두 글은 각각 Viewer 룩과 파일 왕복에 집중하며, 이 글은 Grade가 어느 값 위에서 동작하는지를 다룹니다.

한 줄 정리

Nuke Grade 노드는 Viewer 화면이 아니라 입력값을 바꿉니다. Grade의 위치는 먼저 작업공간과 변환 경계로 정하세요.