Log 플레이트를 리니어에서 키잉했더니 엣지가 거칠 때: 키어마다 맞는 입력 공간

Log 플레이트 키잉에서 Read를 Linear로 바꾼 뒤 엣지가 더 거칠어졌나요? 변환이 두 번 적용됐는지, 키어가 실제로 어떤 값을 받는지부터 확인해야 합니다. Keylight·IBK·Primatte가 같은 입력 공간을 전제로 하는지도 문서로 나눠 보겠습니다.

먼저 Read 변환과 Viewer 표시를 구분하고, 같은 가장자리 값이 Linear와 F-Log2에서 어디에 놓이는지 계산합니다. 마지막에는 키어별 공식 문서가 밝힌 전제와 직접 확인할 순서를 정리합니다.

1. 화면이 아니라 키어 입력을 확인합니다

Nuke의 Viewer는 연결된 노드의 출력을 보여 주는 창입니다. Viewer의 view transform은 모니터에 표시하기 전에 적용되므로, 화면이 회색이나 대비가 낮아 보인다는 이유만으로 키어 입력도 Log라고 판단할 수 없습니다.

먼저 Read 노드의 Input Transform을 확인하세요. Nuke의 기본 Cineon 처리에서는 Read 단계에서 Log를 Linear로 바꿀 수 있습니다. 프로젝트가 OCIO라면 Read 변환과 작업 공간은 선택한 OCIO 설정에 따라 달라집니다. Read 뒤에 Log2Lin을 따로 붙였다면 변환이 겹치지 않는지도 봅니다.

반대로 모든 플레이트에 같은 Log2Lin 설정을 복사하는 것도 안전하지 않습니다. Cineon, F-Log2, Log C처럼 이름이 다른 Log는 각자 곡선이 다릅니다. 카메라와 색역에 맞는 입력 변환을 써야 합니다. F-Log2도 F-Gamut과 짝을 이룹니다.

즉, Viewer에서 보이는 모양보다 Read의 입력 변환과 키어 앞의 실제 픽셀값을 확인하는 편이 먼저입니다.

2. Log 플레이트 키잉에서 같은 가장자리도 Linear와 Log에서 다른 값이 됩니다

가장자리 픽셀은 전경과 배경의 색이 섞여 있습니다. 예를 들어 전경의 G가 0.080, 그린스크린의 G가 0.700, 전경 불투명도 α가 0.25라면 scene-linear 합성값은 0.25×0.080 + 0.75×0.700 = 0.545입니다.

이 값을 F-Log2의 공식 곡선으로 바꾸면 약 0.505가 됩니다. 전경과 스크린의 끝점도 각각 0.312와 0.531로 이동합니다. 이 예에서는 같은 장면의 가장자리 값이 Linear에서 0.545, F-Log2 정규화 코드값에서 0.505입니다.

G 채널 예시	Scene-linear	F-Log2 코드값
전경	0.080	0.312
가장자리	0.545	0.505
스크린	0.700	0.531

끝점의 Log 코드값을 Linear 합성처럼 바로 섞으면 값이 달라집니다. 위 수치로 계산한 0.25×0.312 + 0.75×0.531은 약 0.476입니다. 실제 카메라 신호를 인코딩한 가장자리 값 0.505와 같지 않습니다. 이 차이는 키어가 내놓을 알파가 아니라, 단일 채널 픽셀값의 계산 예시입니다.

여기서 0–1은 이 F-Log2 예시의 정규화 코드값 범위입니다. 키어가 반드시 RGB 0–1 값만 받는다는 뜻은 아닙니다. Scene-linear EXR은 1보다 밝은 값을 담을 수도 있고, 파일 확장자만으로 내부 값이 Linear라고 단정할 수도 없습니다.

3. 엣지가 거칠 때는 이 순서로 비교합니다

• Read의 입력 변환을 확인합니다. 원본 Log가 어떤 카메라 곡선인지 확인하고, 자동 Input Transform과 수동 Log2Lin이 중복됐는지 봅니다.
• 키어 바로 앞의 값을 확인합니다. Viewer view transform을 바꾸는 것과 노드 그래프에서 Colorspace 변환을 넣는 것은 다릅니다. Screen Color를 찍은 플레이트와 키어에 실제로 들어가는 플레이트가 같은 공간인지 확인합니다.
• 알파와 RGB를 따로 봅니다. 알파에서 가장자리가 계단지면 매트 문제일 수 있습니다. 알파는 부드러운데 합성한 색 가장자리만 거칠거나 튄다면 RGB, 디스필, 변환 순서도 따로 봅니다.
• Keylight와 IBK는 한 번에 한 조건씩 A/B 비교합니다. 같은 프레임과 같은 샘플에서 변환 유무만 바꿔 매트와 합성 결과를 비교합니다. IBK는 clean plate와 키 출력을 함께 봅니다. 문서에 없는 보편적인 입력 범위나 기본 정답을 가정하지 않습니다.
• Primatte는 출력 모드와 합성 경로를 문서에 맞춰 확인합니다. 특히 Primatte 출력을 Merge로 따로 합성하는 경우에는 양쪽의 변환과 합성 순서를 맞춥니다.

비교는 같은 Read에서 두 갈래를 만들고, 같은 프레임·같은 배경에서 변환 유무만 바꾸면 원인을 좁히기 쉽습니다. 한 번에 여러 노브와 변환을 함께 바꾸면 어떤 변경이 가장자리를 바꿨는지 알기 어렵습니다.

입력 공간을 바꾼 가지에서는 Screen Color를 그 가지의 플레이트에서 다시 확인하세요. IBK도 FG와 IBKColor의 clean plate가 같은 변환 경로를 거치는지 봅니다. 알파와 RGB 합성 결과를 각각 비교하면, 매트의 계단인지 색 가장자리의 차이인지 구분하기 편합니다.

컨트롤에 보이는 0–1과 입력 RGB의 0–1은 같은 범위라고 볼 수 없습니다. 정규화 코드값, Screen range 같은 노브 값, 알파 매트는 서로 다른 값이므로 이름과 도움말을 함께 확인합니다.

촬영 조명이나 스크린 불균일이 먼저 의심된다면 크로마키가 깔끔하게 안 빠질 때 촬영본에서 찾는 원인을 확인하세요. 매트는 괜찮은데 머리카락에 초록이 남는 문제라면 매트와 디스필을 나눠 고치는 방법이 다음 단계입니다. Log 곡선 자체가 낯설다면 Log 영상의 색공간 원리부터 보면 좋습니다.

4. 세 키어의 입력 전제는 같지 않습니다

Foundry Nuke 17.1 레퍼런스가 각 키어에 대해 밝히는 내용은 서로 다릅니다. 문서가 적지 않은 고정 범위를 추측해 설정값처럼 쓰면 안 됩니다.

키어	문서에서 확인되는 입력 관련 내용	문서만으로 단정할 수 없는 것
Keylight	Source에서 Screen Color를 고르는 color-difference keyer입니다. Screen Matte 컨트롤로 매트를 다듬습니다.	고정된 Log/Linear 전제나 RGB 0–1 한계를 명시하지 않습니다.
IBKColor·IBKGizmo	IBKColor가 배경색 변화를 담은 clean plate를 만들고, IBKGizmo가 그 정보를 이용해 키를 계산합니다. 프리렌더에는 full-float 정보를 보존하는 EXR을 권장합니다.	고정된 Log/Linear 전제나 전체 RGB의 0–1 입력 범위를 명시하지 않습니다. Screen range 기본값 1은 노브 값이지 입력 범위가 아닙니다.
Primatte	Primatte는 sRGB 색공간에서 동작한다고 명시합니다. 별도 Merge 합성 안내에서 Foundry는 Nuke의 Linear 작업 공간을 전제로 합니다.	Keylight·IBK까지 sRGB를 써야 한다는 뜻은 아닙니다.

Primatte에서 premultiplied 또는 unpremultiplied 출력을 Merge로 다룬다면, Foundry 문서는 Primatte와 원본 배경을 sRGB로 변환해 합성한 뒤 결과를 Linear로 되돌리는 절차를 설명합니다. 이 안내는 Primatte 문서에 적힌 조건입니다. 다른 키어에 그대로 옮기지 마세요.

세 키어의 문서상 전제는 같지 않습니다. Primatte는 sRGB를 명시하지만, 확인한 Keylight·IBK 레퍼런스에는 고정 Log/Linear 입력 공간이나 0–1 범위가 적혀 있지 않습니다.

대부분의 합성은 scene-linear에서 하지만, 오래된 OpenColorIO v1 문서의 한 VFX 파이프라인 안내는 키잉처럼 일부 작업에 show별 Log 공간을 지정할 수 있다고 설명합니다. 최신의 보편적 처방이 아니라 특정 파이프라인 사례입니다. 따라서 “Log면 무조건 키잉이 나쁘다”거나 “Linear면 항상 엣지가 좋아진다”고 결론 내릴 수 없습니다.

한 줄 정리

Log 플레이트의 엣지가 거칠 때는 Linear라는 이름만 보고 변환을 더하지 말고, Read가 만든 실제 입력값과 키어별 문서 전제를 먼저 맞춰 보세요.