Position·Depth·Motion Vector 패스까지 색변환했다면: 데이터 AOV를 Raw로 두는 이유

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

Nuke에서 EXR을 열었을 때 Beauty는 괜찮은데 Depth로 Defocus를 걸면 초점 범위가 어긋나고, Motion Vector를 넣은 VectorBlur가 예상과 다른 방향으로 뻗는다면 데이터 AOV Raw 설정부터 확인하세요. 화면에서는 모두 RGB 숫자로 보이지만 Position·Depth·Motion Vector가 담는 것은 색이 아니라 다른 계산이 기대하는 값입니다. 이번 글에서는 값이 변하는 예, 패스별 영향, Nuke Read에서 확인하는 순서를 짚겠습니다.

1. AOV는 채널 이름보다 데이터의 역할을 먼저 봅니다

EXR 한 파일에 Beauty와 여러 AOV를 함께 담아도, 모든 채널이 같은 종류의 정보가 되는 것은 아닙니다. 파일 안에서 R·G·B로 보이는 세 채널도 어떤 패스에서는 빛의 색이고, 다른 패스에서는 좌표나 벡터의 세 성분일 수 있습니다. EXR의 채널 이름은 프로그램이 정보를 구분하는 단서지만, 이름만으로 단위와 좌표계를 모두 알 수는 없습니다. 멀티채널 EXR의 쓰임은 EXR에 여러 패스를 담는 이유에서 볼 수 있습니다.

색을 표현하는 패스: Beauty, Diffuse color, Emission처럼 화면의 색과 빛을 담습니다. 렌더러가 기록한 색공간에서 합성 작업공간으로 변환해야 할 수 있습니다.
계산용 데이터 패스: Depth/Z, Position/P, Normal/N, Motion Vector/Velocity, Object ID처럼 다음 연산에 넣을 숫자나 식별자를 담습니다. 대개 색상용 변환을 적용하지 않고, 패스가 약속한 값을 유지합니다.

먼저 렌더러나 제작팀의 패스 규격에서 값이 무엇을 뜻하는지 확인하세요. Position이 world space인지 camera space인지, Depth가 어떤 기준의 거리인지, Motion Vector가 어느 프레임을 향하고 어떤 단위로 저장됐는지에 따라 후속 노드의 해석이 달라집니다. 이름이 비슷한 패스라도 규격이 같다고 가정하면 안 됩니다.

2. 색변환은 데이터 채널의 숫자도 바꿀 수 있습니다

색공간 변환은 화면에서 색을 비슷하게 보이도록 하는 표시 장식만은 아닙니다. Read 입력변환이나 색공간 노드가 실제 이미지 데이터에 적용되면 채널 값이 변환됩니다. 예를 들어 파일의 값 0.500을 sRGB로 해석해 sRGB에서 선형으로 디코딩하면 약 0.214가 됩니다. 이 변환은 색을 표현하는 픽셀에는 의미가 있지만, 같은 0.500이 거리나 좌표를 뜻하는 AOV라면 원래 수치와 다른 값이 다음 노드에 전달됩니다.

이 숫자는 sRGB에서 선형으로 바꾸는 한 가지 사례입니다. 변환 종류와 입력값에 따라 결과는 달라집니다. 변환이 항등이면 값이 바뀌지 않을 수도 있습니다. 중요한 점은 데이터 패스에 실제 변환이 걸렸다면 값이 보존된다고 미리 가정하지 않는 것입니다. EXR의 float 수치가 1보다 크거나 음수일 수 있는 배경은 32bit Float 이미지의 값 범위를 참고하세요.

데이터 AOV Raw: sRGB에서 선형으로 변환할 때 0.500이 약 0.214로 달라지는 예시 — 예시: 수치 AOV를 sRGB 색상으로 잘못 해석해 선형으로 디코딩하면 0.500이 약 0.214가 됩니다. 모든 색변환이 같은 결과를 내는 것은 아닙니다.

3. Position·Depth·Motion Vector는 서로 다른 계산이 깨집니다

Depth 패스 색변환은 거리 기준을 바꿉니다

Depth는 보통 화면의 각 픽셀에서 표면까지의 거리나 깊이를 나타냅니다. Blender 매뉴얼의 Depth 패스는 가장 가까운 가시 표면까지의 거리로 정의되지만, 다른 렌더러의 기준과 단위는 별도로 확인해야 합니다. 이 값을 색상용 곡선으로 변환하면, Defocus·깊이 마스크·거리 기반 페이드가 기대하는 초점 거리나 임계값과 맞지 않을 수 있습니다. 값의 순서가 그대로 보이더라도 값 사이 간격과 실제 거리에 대응하는 범위는 달라질 수 있습니다.

Position 패스 Raw는 좌표를 그대로 전달합니다

Position은 픽셀마다 표면의 위치를 기록합니다. Blender의 Position 패스는 world-space 좌표를 출력하지만, 다른 파이프라인은 카메라 기준이나 다른 좌표계를 쓸 수 있습니다. 좌표 성분은 음수이거나 1보다 클 수 있고, 색으로 보기 좋게 만드는 범위에 제한되지 않습니다. 변환이 성분을 휘거나 서로 섞으면 위치 복원, 재투영, 위치 기반 마스크처럼 좌표를 직접 쓰는 연산이 어긋날 수 있습니다. 따라서 Position 패스는 파일에서 읽힌 값과 좌표계 규약을 먼저 보존해야 합니다.

Motion Vector 패스 Raw는 방향과 크기를 지킵니다

Motion Vector는 색상이 아니라 화면에서 픽셀이 이동할 방향과 크기를 나타내는 벡터입니다. Nuke의 VectorBlur는 u/v 채널의 값으로 블러 방향을 정하고, 렌더러별 preset은 해당 벡터의 scale과 offset을 맞춥니다. 중간에 비선형 색변환이나 채널 혼합이 들어가면 저장된 벡터 convention과 달라져 블러 길이 또는 방향이 틀어질 수 있습니다. 단, 값이 0에서 1 사이로 패킹돼 있다면 그 패킹을 풀기 위한 전용 scale·offset은 별도 규약에 따라 적용해야 합니다. Raw는 색변환을 건너뛰는 설정이지, 패킹 규칙을 자동으로 해석하는 기능은 아닙니다.

Raw로 읽었는데도 블러가 어색하다면 색변환 외에 vector scale·offset, 프레임 방향, 셔터 설정을 점검하세요. 모션블러 자체의 샘플·셔터 문제는 CG 모션블러와 셔터 앵글 확인법에서 따로 다룹니다.

4. 데이터 AOV Raw 기준과 Nuke Read Raw Data 확인 순서

여기서 처음 질문에 답하면, 데이터 AOV에 색상용 변환을 걸면 합성 노드가 읽는 숫자가 바뀌어 Depth의 거리, Position의 좌표, Motion Vector의 방향과 크기를 잘못 해석할 수 있습니다. 그래서 해당 패스는 제작 규격에 맞는 Raw 또는 data 경로로 읽고, 색을 표현하는 패스와 분리해서 다루는 것이 기준입니다.

패스 규격을 확인합니다. 렌더러의 문서나 쇼 규격에서 채널 이름, 단위, 좌표계, 정규화·패킹 여부, 벡터 프레임 방향을 확인합니다. AOV 이름만 보고 넘기지 않습니다.
색과 데이터를 분리합니다. 같은 EXR에 Beauty와 data AOV가 함께 있으면 Read 전체를 무조건 Raw로 바꾸지 마세요. 데이터 전용 Read나 채널별 변환 범위를 사용해 Beauty에는 올바른 색공간 변환을, data AOV에는 색상용 변환을 적용하지 않도록 구성합니다.
데이터 전용 Read에서 Raw Data를 확인합니다. Foundry Nuke Read 문서에서 Raw Data를 켜면 Nuke가 데이터를 변환하지 않는다고 설명합니다. 단, 대부분의 파일에서 linear와 같더라도 일부 파일 형식에서는 YUV 변환 같은 다른 처리가 함께 꺼질 수 있습니다. 따라서 Raw와 linear를 같은 말로 취급하지 말고, 프로젝트 색관리 규격과 입력 형식을 확인하세요.
뒤에 붙은 변환 노드의 대상 채널을 확인합니다. OCIOColorSpace 같은 노드가 어느 채널과 레이어에 적용되는지 살펴봅니다. 변환 대상이 전체 채널이면 별도 AOV까지 건드리지 않는지 확인하고, 필요한 색상 채널로 범위를 제한합니다.
같은 픽셀의 수치를 비교합니다. 변환 전 Read 출력과 변환 후, 같은 픽셀·같은 채널을 숫자로 샘플링합니다. 화면에서 회색으로 보이는지만 판단하지 말고, 데이터 전용 경로에서 의도하지 않은 변화가 시작되는 첫 노드를 찾습니다.

Raw를 켜도 이미 렌더 파일에 기록되기 전에 색변환된 데이터가 원래 값으로 돌아오지는 않습니다. 변환 전 원본을 다시 받거나 렌더 단계에서 올바른 패스를 출력해야 합니다. 또한 Raw는 잘못된 좌표계, 축 방향, 단위, 벡터 패킹을 고쳐 주지 않습니다. 값이 손상되지 않았는데 후속 노드가 기대하는 형식과 다르면, 제작 규격에 맞춰 명시적인 변환을 적용해야 합니다.