PNG와 EXR, 왜 같은 렌더인데 색이 다르게 보일까?

렌더러에서 뽑은 파일을 PNG로 저장했더니, 같은 프레임의 EXR과 색이 미묘하게 다르게 보인 경험 다들 있으실 거예요. 이건 버그가 아니라 EXR과 PNG가 애초에 “다른 종류의 데이터”를 담고 있기 때문입니다.

EXR은 씬 리퍼드, PNG는 디스플레이 리퍼드

가장 먼저 이해해야 할 개념이 바로 이겁니다. EXR 파일은 보통 리니어 씬 리퍼드(scene-referred) 데이터를 담고 있어요. 쉽게 말하면 “실제 세상의 빛의 양”을 최대한 있는 그대로 숫자로 옮겨놓은 상태입니다. 태양광은 밝은 만큼 아주 큰 숫자로, 그림자는 작은 숫자로 저장되고, 그 값에는 위아래 제한이 거의 없어요(1.0을 훌쩍 넘는 값도 흔합니다).

반면 PNG는 디스플레이 리퍼드(display-referred) 결과물입니다. 이건 “모니터 화면에 실제로 어떻게 보여야 하는가”를 이미 계산해서 구워넣은 파일이에요. 비유하자면 EXR은 아직 요리되지 않은 원재료(식재료 그대로의 정보)이고, PNG는 이미 조리되고 플레이팅까지 끝난 완성 요리라고 생각하면 됩니다. 원재료는 여러 방식으로 조리할 수 있지만, 완성된 요리는 이미 하나의 결과로 고정돼 있죠.

PNG로 저장하는 순간 뷰 트랜스폼이 ‘구워진다’

이 차이가 실제로 생기는 지점이 바로 저장(export) 과정입니다. 렌더러나 컴포지팅 소프트웨어에서 리니어 이미지를 화면에 띄우려면 반드시 **뷰 트랜스폼(view transform)**이라는 변환을 거칩니다. 뷰 트랜스폼은 “이 리니어 숫자를 사람 눈에 자연스럽게 보이는 밝기와 색으로 바꿔주는 규칙”이에요. sRGB 감마 커브를 적용하는 단순한 방식일 수도 있고, ACES의 필름릭(filmic) 톤매핑처럼 하이라이트를 부드럽게 눌러주는 복잡한 방식일 수도 있습니다.

EXR로 저장할 때는 이 변환을 적용하지 않고 리니어 값을 그대로 파일에 남겨둡니다. 반면 PNG로 저장하는 순간에는 소프트웨어가 “지금 화면에 보이는 그 모습”을 픽셀 값으로 굳혀버려요. 이걸 흔히 “베이크(bake)한다”고 표현합니다. 한 번 PNG로 구워지면 원래의 리니어 정보는 사라지고, 이미 조리된 결과만 남습니다. 그래서 나중에 노출을 다시 조절하거나 톤매핑을 바꾸고 싶어도 되돌릴 수가 없는 거예요.

뷰어가 EXR을 해석하는 방식에 따라 화면이 달라진다

EXR 파일 자체에는 원칙적으로 “정답 색”이 없습니다. 순수한 숫자 데이터일 뿐이라서, 이걸 화면에 띄우는 뷰어(nuke, DJV, RV, 포토샵, 파인더 미리보기 등)가 어떤 뷰 트랜스폼을 적용하느냐에 따라 완전히 다른 그림으로 보일 수 있어요.

• 어떤 뷰어는 기본적으로 sRGB 감마만 살짝 씌워서 보여줍니다.
• 어떤 뷰어는 OCIO(OpenColorIO) 설정에 따라 ACES 필름릭 룩을 적용해서 보여줍니다.
• 어떤 뷰어는 아무 변환 없이 리니어 값을 그대로(감마 1.0으로) 보여줘서 전체적으로 씻겨나간 듯 뿌옇게 보이기도 합니다.

똑같은 EXR 파일을 켰는데 프로그램마다 색감, 대비, 채도가 다 다르게 보인다면 바로 이 때문입니다. 결국 EXR을 정확하게 보려면 “어떤 색공간과 뷰 트랜스폼으로 봐야 하는지”에 대한 약속(파이프라인 컬러 스크립트)이 팀 안에서 통일되어 있어야 합니다.

비트 뎁스 차이: 8비트 PNG vs Half/Full Float EXR

PNG는 보통 채널당 8비트(0~255)로 정보를 저장합니다. 값이 256단계로 딱 나뉘어 있죠. 반면 EXR은 보통 채널당 16비트 하프 플로트(half float)나 32비트 풀 플로트(full float)를 사용해서 사실상 거의 무한대에 가까운 밝기 범위와 미세한 단계를 표현할 수 있습니다.

이 차이는 특히 그레이딩이나 합성 작업에서 크게 드러납니다. 8비트 PNG의 어두운 영역을 억지로 밝게 끌어올리면 계단처럼 뚝뚝 끊기는 밴딩(banding) 현상이 바로 보이는데, float EXR은 원래 담고 있던 세밀한 값 덕분에 훨씬 부드럽게 조정이 가능합니다.

1.0을 넘는 값의 클리핑 문제

리니어 EXR에서는 밝은 하이라이트, 반사광, 발광체 등의 값이 1.0(흔히 말하는 “흰색”)을 훨씬 넘어서는 경우가 많습니다. 이런 값들은 나중에 톤매핑을 거치며 부드럽게 압축되어 화면에 표현돼요.

하지만 PNG는 8비트 안에서 최대값이 정해져 있기 때문에 1.0을 넘는 값은 그냥 뭉텅 잘려버립니다. 이걸 **클리핑(clipping)**이라고 부르는데, 한 번 클리핑된 정보는 복구가 불가능합니다. 밝은 창문이나 하이라이트 부분이 PNG에서는 밋밋하게 하얗게 날아가 보이는데 EXR에서는 구름의 질감까지 살아있는 경우가 바로 이 차이 때문이에요.

알파 채널과 프리멀티플라이 처리

합성 작업에서 알파(투명도) 채널을 다룰 때도 두 포맷은 다르게 동작할 수 있습니다. 프리멀티플라이(premultiplied) 알파란, RGB 색상 값에 미리 알파 값을 곱해놓아서 반투명한 가장자리의 색이 배경색과 섞이지 않고 자연스럽게 표현되도록 하는 방식이에요.

EXR은 렌더러 설정에 따라 프리멀티플라이 여부를 선택할 수 있고, 파이프라인에서 이를 명확히 관리하는 경우가 많습니다. 반면 PNG는 언스트레이트(unpremultiplied, 스트레이트) 알파로 저장되는 경우가 흔한데, 이 상태의 파일을 프리멀티플라이 처리 방식으로 잘못 합성하면 반투명한 가장자리에 이상한 색 테두리(할로 현상)가 생깁니다. 두 파일을 같은 방식으로 합성했는데 결과물의 가장자리 색이 다르게 보인다면 이 알파 처리 방식 차이를 의심해봐야 합니다.

감마 이중 적용이라는 흔한 함정

실무에서 정말 자주 일어나는 실수가 바로 **감마 이중 적용(double gamma)**입니다. EXR을 열 때 이미 뷰 트랜스폼(예: sRGB)이 적용된 상태로 화면에 보고 있는데, 이걸 다시 PNG로 저장하면서 프로그램이 한 번 더 sRGB 감마를 씌워버리면 최종 결과물이 원래보다 훨씬 밝고 색이 바랜 듯한 이미지가 됩니다.

반대의 경우도 있어요. 이미 감마가 적용된 PNG를 리니어 데이터인 것처럼 잘못 불러와서 다시 감마를 걸어버리면 이번엔 과도하게 어둡고 대비가 센 이미지가 나옵니다. 이런 사고를 막으려면 각 소프트웨어의 “이 파일을 어떤 색공간으로 읽어들일지” 설정을 항상 확인하는 습관이 중요합니다.

PNG vs EXR 비교표

항목	PNG	EXR
데이터 성격	디스플레이 리퍼드(화면용 완성본)	씬 리퍼드(리니어 원본 데이터)
뷰 트랜스폼	이미 구워짐(되돌리기 불가)	적용 안 됨(뷰어가 매번 해석)
비트 뎁스	보통 8비트	보통 16비트 half / 32비트 full float
값의 범위	0~1 사이로 고정, 초과값 클리핑	1.0을 훌쩍 넘는 값도 표현 가능
알파 처리	대개 언스트레이트(스트레이트)	프리멀티플라이 여부를 파이프라인에서 선택
용도	최종 딜리버리, 참고용 스틸	렌더 패스, 컴포지팅용 중간 소스
재편집 여지	낮음(정보 손실됨)	높음(원본 정보 보존)

어느 쪽이 ‘맞는 색’일까?

결론부터 말하면 둘 다 각자의 역할에서는 “맞는” 색입니다. EXR은 아직 최종 결정을 내리지 않은 원본 데이터이므로 그 자체로 옳고 그름을 따질 수 없어요. 다만 어떤 뷰 트랜스폼으로 봤을 때 우리 파이프라인의 컬러 스크립트와 일치하느냐가 기준이 됩니다.

PNG는 이미 하나의 최종 해석을 담고 있으므로, 그 PNG가 만들어질 때 사용된 뷰 트랜스몬(예: sRGB, ACES Output Transform 등)이 클라이언트나 상영 환경의 기준과 맞는지가 판단 기준이 됩니다. 즉 “정답 색”을 찾으려 하기보다는, 우리가 지금 보고 있는 이미지가 어떤 색공간과 트랜스폼을 거쳤는지를 항상 명확히 알고 있는 것이 진짜 색관리의 핵심입니다.

자주 묻는 질문(FAQ)

Q1. EXR 파일을 그냥 포토샵이나 파인더에서 열어봤는데 왜 색이 이상하게 뿌옇게 나올까요? A1. 대부분의 경우 뷰어가 리니어 값을 그대로 화면에 뿌리면서 적절한 뷰 트랜스폼(감마 보정)을 적용하지 않았기 때문입니다. OCIO나 컬러 매니지먼트 설정을 지원하는 뷰어(Nuke, DJV 등)에서 sRGB나 ACES 뷰 트랜스폼을 걸어 확인해보시는 걸 추천드립니다.

Q2. 컴포지팅 작업은 EXR로 하고 클라이언트 리뷰용은 PNG로 뽑는 게 맞는 방법인가요? A2. 네, 일반적인 실무 방식입니다. 작업 중에는 정보 손실이 없는 EXR로 유연하게 그레이딩과 합성을 하고, 최종 확인이나 공유용으로는 뷰 트랜스몬이 적용된 PNG나 JPG로 내보내는 것이 효율적입니다. 다만 리뷰용 PNG를 만들 때 사용한 뷰 트랜스폼이 최종 딜리버리 스펙과 같은지는 꼭 확인해야 합니다.

Q3. PNG로 이미 저장한 파일을 다시 리니어로 되돌려서 작업할 수 있나요? A3. 완전히 원래대로 되돌리는 것은 불가능합니다. 뷰 트랜스몬이 적용되면서 클리핑된 하이라이트나 압축된 계조 정보는 이미 사라진 상태이기 때문이에요. 역감마를 걸어 대략적인 근사치는 만들 수 있지만, 원본 EXR과 완전히 같아지지는 않으므로 되도록 원본 소스를 보관해두는 것이 좋습니다.