ProRes·H.264 플레이트를 누크에 넣었더니 검정이 뜰 때: 비디오 레벨 16-235와 풀 레인지

vfx 잡학지식 2026년 10월 14일 읽는 시간 약 14분 조회 2

ProRes·H.264 플레이트를 Nuke에 불러왔는데 검정이 회색처럼 보이면 색 보정부터 만지고 싶어집니다. 하지만 비디오 레벨 16-235와 풀 레인지가 서로 어떻게 읽혔는지 확인하지 않으면 값이 달라진 지점을 찾기 어렵습니다. 왜 같은 파일에서 검정이 뜨거나 어두운 부분이 뭉개질까요?

문제는 코덱 이름만으로 어느 범위를 사용했는지 알 수 없다는 점입니다. ProRes라고 항상 리미티드 레인지는 아닙니다. H.264도 마찬가지입니다. 파일의 범위 메타데이터를 확인하고 실제 코드값과 비교해야 합니다.

이 글에서는 먼저 잘못된 범위 해석이 만드는 증상을 계산합니다. 이어서 ffprobe로 파일 정보를 확인하고 Nuke Read의 메타데이터와 대조하는 순서를 정리합니다.

비디오 레벨 16-235는 어떤 값인가?

먼저 계산 대상부터 구분해야 합니다. 아래 수치는 일반적인 Y′CbCr 신호의 nominal 코드 범위입니다. 밝기 신호인 Y′와 색차 신호인 Cb·Cr의 범위는 서로 다릅니다.

구분	8-bit	10-bit
Full Y′	0–255	0–1023
Video Y′	16–235	64–940
Video Y′ 구간 폭	219	876
Nominal Cb/Cr	16–240	64–960
Cb/Cr 중간값	128	512

8-bit 비디오 Y′에서는 16이 기준 검정이고 235가 기준 흰색입니다. 10-bit에서는 각각 64와 940입니다.

이 범위는 RGB의 모든 채널에 동일하게 적용하는 규칙이 아닙니다. 또한 nominal 범위 밖에 superblack, superwhite 및 headroom 값이 존재할 수 있습니다. 범위 밖의 값을 발견했다는 이유만으로 무조건 잘라서는 안 됩니다.

비디오 Y′를 풀 레인지 기준으로 계산하면?

8-bit 비디오 Y′의 16을 풀 레인지의 0–255 기준으로 정규화하면 다음과 같습니다.

8-bit video Y′ → full 해석

검정: 16 / 255 × 100 = 6.27%
중간: 126 / 255 × 100 = 49.41%
흰색: 235 / 255 × 100 = 92.16%

여기서는 입력 코드값을 전체 0–255 기준으로 나눈 결과만 계산했습니다. 10-bit의 대응 값도 같은 방식으로 확인합니다.

10-bit에서도 같은 문제가 나타납니다.

10-bit video Y′ → full 해석

검정: 64 / 1023 × 100 = 6.26%
중간: 502 / 1023 × 100 = 49.07%
흰색: 940 / 1023 × 100 = 91.89%

여기서 계산한 비율은 원래 Y′ 코드값을 풀 범위로 정규화한 결과입니다. Nuke Viewer에서 측정한 linear RGB 값이나 표시 밝기를 뜻하지 않습니다. 실제 화면의 밝기는 Y′CbCr 변환과 색 변환의 영향도 받습니다.

풀 Y′를 비디오 범위 공식에 넣으면?

반대 방향에서는 비디오 범위를 풀 범위로 확장하는 수식이 풀 레인지 데이터에 잘못 적용됩니다.

8-bit 해석식
(v − 16) × 255 / 219

입력 0   → -18.63
입력 128 → 130.41
입력 255 → 278.29

10-bit 해석식
(v − 64) × 1023 / 876

입력 0    → -74.74
입력 512  → 523.18
입력 1023 → 1119.93

8-bit의 경우 결과가 0 미만 또는 255 초과로 나갑니다. 후단에서 0–255로 clamp하면 각각 0과 255로 잘립니다. 10-bit도 후단에서 0–1023으로 clamp하면 같은 문제가 발생합니다.

비디오를 풀로 읽으면 검정이 뜨고, 풀을 비디오로 읽은 뒤 끝점을 clamp하면 그림자와 하이라이트가 손실될 수 있다는 것이 계산의 핵심입니다.

다만 이 값은 범위 변환식을 이용한 이상적 계산입니다. Nuke의 실제 디코딩 결과를 측정한 수치가 아닙니다. 범위 밖의 정보를 유지하는 처리 경로에서는 즉시 클립된다고 단정할 수 없습니다.

ffprobe로 ProRes·H.264의 범위 태그 확인하기

파일을 받았다면 색 보정 노드를 추가하기 전에 메타데이터부터 확인합니다. FFmpeg에 포함된 ffprobe를 사용하면 비디오 스트림에 기록된 범위와 색 관련 정보를 조회할 수 있습니다.

터미널에서 다음 명령을 실행합니다. input.mov는 실제 플레이트 파일명 또는 경로로 교체합니다.

ffprobe -v error -select_streams v:0 -show_entries stream=codec_name,pix_fmt,bits_per_raw_sample,color_range,color_space,color_transfer,color_primaries -of default=noprint_wrappers=1 input.mov

출력에서는 다음 필드를 구분합니다.

codec_name: ProRes, H.264 등 비디오 코덱 이름입니다.
pix_fmt: 디코딩에 사용되는 픽셀 형식입니다.
bits_per_raw_sample: 제공되는 경우 비트 깊이를 확인할 수 있는 필드입니다.
color_range: video 또는 full 범위 구분에 사용하는 정보입니다.
color_space: Y′CbCr와 RGB 변환 등에 관계된 매트릭스 정보입니다.
color_transfer: 전달 함수 정보입니다.
color_primaries: 색 원색 정보입니다.

가장 먼저 볼 값은 color_range입니다.

color_range=tv: 제한 범위 또는 비디오 레인지로 표시된 상태입니다.
color_range=pc: 풀 레인지로 표시된 상태입니다.
값이 없거나 unspecified·unknown 상태: 이 결과만으로 범위를 판정할 수 없습니다.

여기서 주의할 점이 있습니다. color_range는 확인해야 할 첫 번째 단서이지 실제 픽셀 코드값이 태그와 일치한다는 증명은 아닙니다. 잘못 기록된 메타데이터가 있을 가능성을 배제할 수 없습니다.

또한 range와 matrix, transfer, primaries는 서로 다른 정보입니다. color_range가 맞더라도 다른 색 정보의 해석이 다르면 화면이 달라질 수 있습니다. 범위 불일치와 감마 문제를 같은 현상으로 취급해서는 안 됩니다.

합성 파일 테스트에서는 어떤 값이 나왔나?

제공된 PC 테스트에서는 FFmpeg/ffprobe의 2022-07-21 빌드를 사용했습니다. H.264는 합성한 1프레임 파일로 범위 플래그를 비교했습니다. ProRes는 422 10-bit 합성 MOV 파일을 확인했습니다.

합성 테스트 파일	ffprobe 확인 결과
H.264 video flag 0	`color_range=tv` `pix_fmt=yuv420p`
H.264 full flag 1	`color_range=pc` `pix_fmt=yuvj420p`
ProRes 422 10-bit MOV	`codec_name=prores` `pix_fmt=yuv422p10le` `bits_per_raw_sample=10` `color_range=tv`

이 결과에서 확인된 것은 합성 파일에 설정된 범위 정보가 ffprobe에 어떻게 표시되는지입니다. H.264에서 해당 테스트의 두 플래그가 다른 결과를 반환했습니다. ProRes 합성 파일에서는 tv가 확인됐습니다.

다만 이 태그는 인코더가 기록한 표시일 뿐, 실제 픽셀 코드값이 그 범위 안에 있다는 보장은 아닙니다. 태그가 잘못 붙은 파일도 있으므로, 코덱이나 픽셀 형식 하나만 보고 범위를 확정하지 말고 아래 순서로 Nuke에서 읽힌 값까지 확인합니다.

Nuke Read에서 범위 해석을 확인하는 순서

Foundry 공식 문서에 따르면 Read 노드는 입력 미디어를 Nuke의 32-bit linear RGB 작업 환경으로 가져옵니다. 따라서 Read 이후의 픽셀 수치를 원본의 Y′ 코드값과 그대로 비교해서는 안 됩니다.

아래 순서로 파일 정보와 Nuke에 노출된 정보를 대조합니다.

원본 파일 확인: 문제가 발생한 ProRes·H.264 파일에 ffprobe를 실행합니다. color_range와 다른 색 관련 필드를 기록합니다.
Read Metadata 확인: Nuke에서 파일을 읽은 뒤 Read 속성의 Metadata 탭을 엽니다. 검색 기능을 사용해 range 관련 키가 노출되는지 확인합니다.
필요하면 ViewMetaData 사용: Read 뒤에 ViewMetaData 노드를 연결해 이용 가능한 메타데이터를 확인합니다.
두 결과 대조: ffprobe에서 확인한 범위 태그와 Read에서 노출된 범위 정보를 비교합니다. Nuke에 해당 키가 없다면 추측으로 값을 채우지 않습니다.
실제 코드값 검증: 가능하면 원본 Y′ 샘플값과 신뢰할 수 있는 기준 프레임을 별도로 비교합니다. 태그만으로 실제 코드 범위가 맞는지 판정하지 않습니다.

검정과 흰색이 명확한 기준 자료가 없다면 일반 영상의 최솟값과 최댓값만으로 리미티드 또는 풀 레인지를 확정하기 어렵습니다. 장면 자체에 순수 검정이나 기준 흰색이 없을 수 있기 때문입니다.

Read의 MOV Data Range를 바로 바꾸면 될까?

범위 문제가 의심된다는 이유만으로 Read의 Data Range를 먼저 변경해서는 안 됩니다.

Foundry 공식 Read 문서에서 MOV의 Data Range 컨트롤은 DNxHD 디코딩에 대한 기능으로 설명됩니다. 이를 모든 ProRes와 H.264 파일에 적용되는 범용 레인지 스위치라고 해석할 근거는 없습니다.

우선 파일에서 확인한 범위 정보와 Read가 노출하는 메타데이터를 대조해야 합니다. 그다음 해당 미디어의 실제 디코딩 경로와 코드값을 확인해야 합니다. 설정 변경은 이 판단 뒤에 진행해야 합니다.

영상 전체가 완전히 검은 화면으로 표시된다면 범위 불일치만으로 단정할 수 없습니다. 파일 경로, 프레임 범위, 알파 등의 다른 가능성도 확인해야 합니다.

그래서 어떤 해석이 검정을 띄우고, 어떤 해석이 뭉개나?

리미티드 레인지 Y′를 풀 범위로 읽으면 검정이 들뜨며 대비가 줄고, 풀 범위를 비디오로 읽어 끝점을 clamp하면 그림자와 하이라이트가 뭉개질 수 있습니다.

증상은 서로 반대 방향입니다

두 경우는 같은 불일치라도 결과가 반대 방향입니다.

비디오 → 풀 레인지: 비디오 검정 코드값을 풀 범위의 0보다 높은 값으로 취급합니다. 검정이 들뜨고 흰색은 충분히 밝아지지 않아 대비가 줄어듭니다.
풀 → 비디오 레인지: 풀 범위의 양 끝을 제한 범위 밖으로 해석합니다. 후단에서 값을 잘라내면 그림자가 뭉개지고 하이라이트가 클립될 수 있습니다.

따라서 검정이 밝아졌다는 증상과 검정 내부의 디테일이 사라졌다는 증상을 구분해야 합니다. 후자의 다른 원인은 블랙 레벨로 그림자가 뭉개질 때 확인할 항목에서 별도로 다룹니다.