EXR 시퀀스 용량 계산기: 해상도·채널·비트·압축으로 저장 공간 미리 보기

EXR 용량은 압축률을 먼저 추측하지 말고, 해상도 × 실제 저장 채널 수 × 채널당 바이트 × 프레임 수로 무압축 바닥값을 계산한 뒤 대표 프레임을 저장해 압축 범위를 좁히세요. 1920×1080, RGBA half, 2,400프레임이면 픽셀 데이터만 약 39.81GB이고 float라면 약 79.63GB입니다. 압축 후 크기는 화면 내용과 노이즈에 따라 달라지므로 아래 계산기는 실측 예시 범위로 계획을 돕고, 최종 값은 내 장면에서 저장한 파일로 확인해야 합니다.

EXR 용량 계산기로 먼저 저장 공간 범위를 잡으세요

아래 계산기는 가로·세로 픽셀, 저장 채널 수, 채널 자료형, 압축 방식, 프레임 수를 받아 무압축 픽셀 데이터와 압축 후 참고 범위를 계산합니다. 기본값은 1920×1080, RGBA 4채널, half, ZIP, 2,400프레임입니다. 이 값에서 무압축 이론값은 39.81GB이고, ZIP은 이 글의 테스트 장면에서 나온 비율을 적용해 약 14.93~19.97GB로 표시됩니다.

이 범위는 사용자의 렌더를 미리 측정한 결과가 아닙니다. 같은 픽셀 수라도 평평한 배경, 미세한 질감, 밝은 불꽃, 노이즈가 많은 그림은 압축되는 정도가 다릅니다. 계산기는 작업을 시작하기 전 디스크 규모를 가늠하는 자이고, 완성된 파일 크기를 약속하는 보증서는 아닙니다.

무압축 데이터부터 계산하면 필요한 공간의 바닥이 보입니다

압축을 빼고 생각하면 계산은 간단합니다. 화면의 픽셀 한 칸마다 몇 개의 숫자를 저장하는지 세고, 숫자 한 개의 크기와 픽셀 수, 프레임 수를 곱하면 됩니다. 작은 상자 하나에 숫자를 담는다고 생각하면, 해상도는 상자의 개수이고 채널 수는 각 상자에 들어가는 숫자의 개수입니다.

1920×1080은 2,073,600픽셀입니다. RGBA는 빨강·초록·파랑·알파 네 채널이고, half는 채널 하나당 2바이트이므로 픽셀 하나가 8바이트를 차지합니다. 따라서 한 프레임은 2,073,600 × 4 × 2 = 16,588,800바이트, 십진 기준 약 16.59MB입니다. 여기에 2,400프레임을 곱하면 39,813,120,000바이트, 즉 약 39.81GB가 됩니다.

조건	계산	무압축 픽셀 데이터
1920×1080 RGBA half, 1프레임	1920 × 1080 × 4 × 2	16.59MB
1920×1080 RGBA half, 2,400프레임	16,588,800 × 2,400	39.81GB
1920×1080 RGBA float, 2,400프레임	1920 × 1080 × 4 × 4 × 2,400	79.63GB
3840×2160 RGBA half, 300프레임	3840 × 2160 × 4 × 2 × 300	19.91GB

이 글의 MB와 GB는 십진 단위입니다. 1MB는 1,000,000바이트, 1GB는 1,000,000,000바이트입니다. 이진 단위는 1MiB가 1,048,576바이트, 1GiB가 1,073,741,824바이트입니다. 따라서 39.81GB는 약 37.08GiB, 79.63GB는 약 74.16GiB입니다. 운영체제나 프로그램이 이진 크기를 MB·GB로 표시할 수도 있으니 숫자와 함께 단위 기준을 확인하세요.

이 숫자는 픽셀 데이터만 더한 값입니다. 실제 EXR에는 파일 헤더와 청크 정보가 들어가므로 파일 크기는 이론값보다 조금 커집니다. 테스트 장면의 1280×720 RGBA half 픽셀 데이터는 7,372,800바이트였고, NONE으로 저장한 파일은 7,385,167~7,385,169바이트였습니다. 보관 계획을 세울 때는 무압축 계산값을 최저선으로 보고, 헤더·프로젝트 파일·캐시·백업 공간을 별도로 남겨 두세요.

AOV 개수가 아니라 파일에 기록되는 채널 성분을 세세요

AOV는 조명·깊이·노멀처럼 합성에서 따로 쓸 렌더 결과를 나누는 이름입니다. 이름표가 붙은 패스 하나가 항상 채널 하나인 것은 아닙니다. RGB 패스는 세 성분이고 RGBA는 네 성분이며, Z 깊이처럼 값 하나만 기록하는 채널도 있습니다. 그래서 ‘AOV 5개’라고만 세기보다 최종 파일 안에 실제로 저장되는 숫자의 총개수를 세어야 합니다.

예시 구성	채널 성분 수	확인할 점
RGB	3	색 채널만 저장
RGBA	4	투명도 A까지 저장
RGBA + Z	5	깊이 채널 한 개 추가
RGBA + Z + Normal X/Y/Z	8	노멀은 세 성분으로 계산
위 구성 + Motion X/Y	10	벡터 출력의 실제 성분 수를 파일에서 확인

예를 들어 RGBA, Z, Normal XYZ, Motion XY를 모두 half로 저장하면 픽셀당 10 × 2 = 20바이트입니다. 같은 설정에서 채널이 4개인 RGBA만 저장할 때보다 픽셀 데이터가 2.5배입니다. AOV를 켜면 파일이 커지는 이유는 패스 이름이 늘어나서가 아니라, 각 픽셀마다 저장할 숫자가 더 생기기 때문입니다.

멀티레이어 EXR 한 파일에 합치든 패스별 파일로 나누든, 보관해야 하는 전체 픽셀 데이터는 각 패스의 채널을 모두 더해 생각해야 합니다. 별도 파일로 나누면 폴더에 파일이 많이 생길 뿐, 저장 공간 합계가 저절로 줄지는 않습니다. 다만 패스마다 해상도나 크롭 영역이 다르다면 각 패스의 실제 픽셀 수로 따로 계산하세요.

Half와 float는 채널당 바이트가 두 배 차이 납니다

half는 16비트 부동소수점으로 채널당 2바이트이고 float는 32비트 부동소수점으로 4바이트입니다. 같은 해상도·채널 수·프레임 수라면 모든 채널을 half에서 float로 바꿀 때 무압축 픽셀 데이터가 두 배가 됩니다. 1920×1080 RGBA half는 프레임당 16.59MB지만 float는 33.18MB입니다.

여기서 ‘비트 수가 두 배면 파일이 정확히 두 배’라는 말은 압축 전 크기에 대한 설명입니다. 압축 후 파일은 값의 변화 양상에 따라 비율이 바뀌므로 두 배로 계산되지 않을 수 있습니다. float를 선택할지는 숫자가 더 정밀하다는 이유만으로 정하지 말고, 합성에서 다루는 값의 범위와 실제 출력 자료형을 기준으로 결정하세요. half와 float의 표현 범위 자체는 32bit Float와 비트 깊이 글에서 이어서 볼 수 있습니다.

OpenEXR 형식에는 HALF와 FLOAT 외에 UINT 정수 채널도 있습니다. 오브젝트 ID처럼 정수로 저장되는 데이터는 채널당 4바이트로 계산해야 합니다. 아래 도구의 자료형 선택은 모든 채널이 같은 half 또는 float인 경우만 처리하므로, 예를 들어 RGBA half 네 채널과 Z float 한 채널을 섞었다면 (4 × 2) + (1 × 4)처럼 자료형별 바이트를 먼저 더하세요. ID용 UINT 채널도 별도 4바이트 그룹으로 더해야 합니다.

채널마다 서로 다른 자료형을 쓸 수 있는 EXR도 있지만, DCC나 렌더러의 출력 메뉴가 채널별 자료형 지정을 제공하는지는 별도 문제입니다. 파일에 어떤 채널과 자료형이 실제로 들어갔는지 확인하는 것이 계산보다 중요합니다. 채널 비트 깊이의 의미가 더 궁금하면 8bit·16bit·32bit 차이를 참고하세요.

같은 테스트 렌더도 노이즈에 따라 압축 크기가 달랐습니다

압축률은 화면의 숫자가 얼마나 반복되고 예측 가능한지에 따라 달라집니다. 매끈한 그라데이션은 이웃 픽셀의 값이 비슷해 줄여 저장하기 쉽고, 고주파 질감이나 렌더 노이즈는 픽셀마다 값이 흔들려 같은 방식으로 줄이기 어렵습니다. 이는 같은 책을 글자 수만 세어 상자에 담는 것과, 같은 글자 수라도 반복 단어가 많은 책을 압축하는 것의 차이와 비슷합니다.

이를 확인하려고 Blender 5.0.0의 Cycles CPU로 반사 구체와 Suzanne, 절차 텍스처가 있는 바닥, Area Light 세 개를 1280×720으로 렌더했습니다. RGBA half, 디노이즈 끔, 카메라와 재질은 그대로 두고 샘플 수만 8 spp와 128 spp로 바꿨습니다. 각 렌더 결과 한 장을 NONE, ZIP, PIZ, DWAA, DWAB로 각각 저장했습니다. 아래 크기는 십진 MB이고, 비율은 같은 샘플 수의 NONE 파일 대비입니다.

코덱	128 spp 저노이즈	NONE 대비	8 spp 고노이즈	NONE 대비
NONE	7.385 MB	100.0%	7.385 MB	100.0%
ZIP	2.770 MB	37.5%	3.704 MB	50.2%
PIZ	2.699 MB	36.5%	3.670 MB	49.7%
DWAA	1.018 MB	13.8%	1.960 MB	26.5%
DWAB	1.000 MB	13.5%	1.948 MB	26.4%

이 장면에서는 8 spp 노이즈 렌더가 128 spp 결과보다 ZIP에서 약 0.93MB, PIZ에서 약 0.97MB 더 컸습니다. 무압축 파일은 거의 같은 크기였지만, 압축 파일은 이미지 내용 때문에 달라졌습니다. 그래서 ‘EXR은 ZIP이면 절반’ 같은 하나의 숫자를 모든 샷에 적용하면 저장 공간을 적게 잡거나 지나치게 크게 잡을 수 있습니다.

OpenEXR 공식 문서에서 ZIP은 가로로 이웃한 픽셀 차이를 zlib로 줄이는 무손실 압축이며 스캔라인 16줄을 한 블록으로 묶습니다. PIZ도 무손실이고 wavelet 기반이며 32줄씩 묶습니다. DWAA와 DWAB는 DCT 기반 손실 압축으로, 각각 32줄과 256줄을 한 블록으로 저장하므로 원본 픽셀 값이 달라질 수 있습니다. 표에서 DWAA·DWAB가 가장 작았지만 작은 파일만 보고 선택하면 안 됩니다. 이 글은 용량 계획에 집중하므로 압축으로 픽셀 값이 바뀌는 조건과 무손실 방식의 차이는 EXR 압축의 무손실 여부와 DWAA·B44 비교에서 확인하세요.

이 결과는 특정 장면, 해상도, 채널 구성, Blender 버전에서 나온 실측값입니다. 다른 렌더러나 다른 코덱 품질값, 많은 AOV가 들어간 멀티레이어 파일에 그대로 적용할 비율은 아닙니다. 계산기에서 ZIP 37~50%, PIZ 36~50%, DWAA 14~27%, DWAB 13~26%로 표시한 이유도 보편 공식이라서가 아니라, 이 테스트의 두 노이즈 조건에서 관측한 범위를 참고값으로 보여주기 위해서입니다.

프레임 수에는 시작 번호와 끝 번호를 모두 포함하세요

한 프레임 크기를 구했다면 프레임 수를 곱합니다. 프레임 1001부터 1120까지라면 1120 – 1001이 아니라 양 끝을 포함해 120프레임입니다. 파일명이 0001부터 시작하든 1001부터 시작하든 저장 공간 계산에서는 실제로 렌더하고 보관할 장수만 세면 됩니다.

시퀀스가 2,400프레임이고 샷 내용이 장면마다 다르면 한 프레임만 골라 확정하지 마세요. 초반·중간·복잡한 액션 구간처럼 내용이 달라지는 대표 프레임을 같은 설정으로 저장해 크기를 비교하고, 평균 크기에 전체 프레임 수를 곱해 예상치를 잡으세요. 동시에 가장 큰 표본 파일도 확인하면 프레임마다 용량이 달라지는 폭을 볼 수 있습니다. 장면 변화가 거의 없는 제품 턴테이블과 연기·불꽃이 크게 움직이는 샷은 같은 압축률로 묶을 이유가 없습니다.

렌더 시퀀스 외에도 멀티레이어 파일, 프록시, 임시 캐시, 재렌더 구간, 백업본이 같은 볼륨에 쌓인다면 계산 결과만큼의 빈 공간으로는 부족할 수 있습니다. 이 항목들은 프로젝트마다 다르므로 계산기에 일정한 여유율을 넣지 않았습니다. 먼저 원본 시퀀스가 차지할 크기를 계산하고, 실제 저장 정책에 따라 작업 공간과 백업 공간을 별도로 더하세요.

Blender에서 대표 프레임을 저장해 예상치를 좁히는 순서

계산기로는 무압축 최저선과 실측 기반 범위를 잡고, 마지막 판단은 실제 출력에서 합니다. Blender 5.0에서는 Output Properties의 File Format에서 OpenEXR 또는 OpenEXR MultiLayer를 고릅니다. OpenEXR은 한 이미지 출력에, OpenEXR MultiLayer는 여러 입력·패스를 한 파일에 담을 때 쓰는 선택지입니다. 어느 쪽이든 파일을 받는 합성 프로그램이 레이어와 채널을 읽을 수 있는지 확인하세요.

1. 출력 구성을 먼저 고르세요. 프레임 크기와 RGBA 필요 여부를 정하고, View Layer에서 필요한 AOV만 켭니다. 최종 파일의 채널을 열어 RGBA, Z, Normal, Vector 등 실제 들어갈 성분 수를 확인하세요.
2. 자료형과 압축을 정하세요. Color Depth에서 half 또는 float를 선택하고, EXR 코덱 선택 항목에서 비교할 방식을 정합니다. ZIP·PIZ처럼 무손실 압축을 기준으로 삼고 DWAA·DWAB를 시험할 때는 결과가 원본과 달라질 수 있다는 점을 같이 비교하세요.
3. 대표 프레임을 저장하세요. 완성 장면에서 노이즈가 많거나 효과가 복잡한 프레임을 포함해 같은 해상도·채널·자료형·코덱으로 표본을 만듭니다. 압축 방식을 비교하려면 렌더를 각각 다시 돌리지 말고 같은 Render Result를 코덱만 바꿔 저장하면 렌더 내용 차이를 줄일 수 있습니다.
4. 파일 크기와 읽히는 결과를 함께 확인하세요. 파일 속성으로 표본의 실제 크기를 기록하고, 합성 프로그램에서 채널·알파·AOV가 제대로 열리는지 봅니다. DWAA·DWAB를 쓴다면 확대 Viewer에서 미세한 질감이나 경계가 달라지지 않는지도 확인하세요.
5. 시퀀스 전체로 환산하세요. 대표 표본의 평균 크기에 프레임 수를 곱하고, 가장 큰 표본과 캐시·백업에 필요한 공간을 별도로 더하세요. 렌더가 시작된 뒤에는 초반 몇 프레임의 실제 파일 크기를 다시 비교해 예상과 차이가 큰지 확인하세요.

압축 코덱의 이름만 비교하는 것보다 출력 채널과 자료형을 먼저 고정하는 편이 중요합니다. 같은 장면에서 채널 수를 두 배로 늘리면 저장할 픽셀 성분도 두 배가 되고, half에서 float로 바꾸면 채널당 데이터가 두 배가 됩니다. 코덱은 그 다음에 표본 파일 크기와 합성 결과를 함께 보고 고르세요.

주의할 예외도 있습니다. EXR이 크롭된 data window를 쓰면 프레임 크기 전체가 아닌 실제 저장 영역의 픽셀 수가 기준이 됩니다. Deep EXR은 한 픽셀에 여러 깊이 샘플을 담을 수 있어 픽셀당 고정 채널 수만으로 계산하기 어렵습니다. 멀티뷰, 서브샘플링 채널, AOV마다 다른 자료형을 쓰는 경우도 계산기 결과와 파일 크기가 어긋날 수 있으니, 최종 형식으로 표본을 저장해 확인하세요.

한 줄 정리: 채널과 비트로 바닥값을 잡고, 압축은 샘플로 좁히세요

EXR 용량은 해상도 × 저장 채널 × 채널당 바이트 × 프레임 수로 바닥값을 잡고, 압축은 대표 프레임을 저장해 좁히세요. 노이즈와 화면 내용이 달라지면 같은 코덱도 파일 크기가 달라집니다. 계산기의 범위는 출발점으로 쓰고, 실제 샷의 파일 크기와 필요한 채널이 보존되는지 확인한 뒤 저장 공간을 확정하세요.

공식 문서와 함께 보면 좋은 글