렌더 색공간을 ACEScg로 바꾸자 간접광 색이 진해졌다면: 원색이 GI 계산을 바꾸는 이유

ACEScg로 작업 색공간을 바꾸자 빨간 벽끼리 마주 보는 모서리의 간접광이 더 진해졌습니다. 같은 PNG 알베도인데 반사색까지 바뀌는 이유는 무엇일까요? 먼저 화면에 보이는 룩과 빛을 계산하는 공간을 나눠야 합니다.

확인할 것은 세 가지입니다. 화면 표시 변환인지, 텍스처 입력 변환인지, 아니면 GI가 계산되는 작업 색공간인지 차례로 분리하면 원인을 찾을 수 있습니다.

1. ACEScg 색 변화, 표시와 계산부터 나눕니다

같은 렌더 결과도 View Transform을 바꾸면 모니터에 보이는 대비와 색이 달라집니다. 하지만 이때는 이미 계산된 장면을 어떻게 표시할지 달라진 것입니다. 반면 Working Space는 재질·조명·합성이 사용하는 RGB 기준이므로, 렌더 계산 자체가 달라질 수 있습니다.

Blender 5.0에서는 파일의 작업 색공간을 Render Properties > Color Management > Working Space에서 고릅니다. 기본은 Linear Rec.709이며 Linear Rec.2020과 ACEScg도 있습니다. ACEScg와 sRGB의 역할 차이는 작업용 색공간과 출력용 색공간 비교에서 먼저 확인할 수 있습니다.

2. 같은 텍스처도 작업 공간의 숫자는 다릅니다

PNG의 sRGB 값은 화면에 맞춘 코드값입니다. 렌더러는 이를 선형 빛 값으로 풀고, 현재 작업 색공간의 원색 기준으로 변환해 사용합니다. 따라서 올바르게 태그된 같은 색 텍스처라도 Rec.709와 ACEScg 안의 RGB 숫자는 서로 다릅니다.

ACEScg는 선형 전달함수와 AP1 원색을 씁니다. sRGB는 Rec.709 원색과 D65 백색점을 씁니다. 색공간은 R·G·B 숫자에 어떤 색을 뜻하게 할지 정하는 기준입니다. 수치가 다르다는 사실만으로 화면 색이 틀렸다고 판단할 수는 없습니다.

또 텍스처가 sRGB로 제대로 변환되지 않으면 최초 색부터 달라집니다. 색상 알베도 PNG/JPG는 sRGB 입력으로 읽고, 노멀·러프니스 같은 데이터 맵은 Non-Color로 읽어야 합니다. 기존 프로젝트의 색공간을 바꿀 때는 재질 색상과 이미지 태그가 어떻게 변환됐는지 따로 확인합니다.

3. 한 번 곱할 때와 여러 번 곱할 때

간접광이 표면을 한 번 더 반사할 때, 간단한 확산 모델에서는 빛에 알베도 ρ를 채널별로 곱합니다. 같은 색의 표면을 반복해서 통과한다고 가정하면 n회 결과는 ρ의 n제곱입니다. 리니어 공간에서 빛을 계산하는 이유는 Linear Workflow의 빛 계산과 연결됩니다.

예를 들어 8비트 sRGB 코드값 (204, 51, 26)을 255로 나눈 색을 넣습니다. 이를 각 작업 공간으로 올바르게 변환하면 알베도는 Linear Rec.709에서 (0.603831, 0.033104, 0.010330), ACEScg에서 (0.381936, 0.072859, 0.025061)입니다. 숫자는 다르지만 첫 반사에서는 공통 XYZ 기준의 색이 같습니다.

두 번째 반사에서는 Rec.709의 누적 RGB가 (0.364612, 0.001096, 0.000107), ACEScg는 (0.145875, 0.005308, 0.000628)입니다. RGB 좌표는 공간마다 기준이 다르므로 이 숫자끼리 직접 비교하지 않았습니다. 각 결과를 공통 Linear CIE-XYZ D65로 변환한 값은 다음과 같습니다.

바운스	Linear Rec.709: Y / 색도 x,y	ACEScg: Y / 색도 x,y
1회	0.152819 / 0.59577, 0.34655	0.152819 / 0.59577, 0.34655
2회	0.078322 / 0.63785, 0.33135	0.042663 / 0.69263, 0.30803
3회	0.046842 / 0.63989, 0.33008	0.015175 / 0.70960, 0.29590
4회	0.028270 / 0.63999, 0.33000	0.005715 / 0.71254, 0.29332

첫 회는 색도와 Y가 일치합니다. 반복 곱셈이 들어가면 채널 비율이 달라집니다. AP1 결과는 AP1 빨강 원색 (0.713, 0.293) 쪽으로, Rec.709 결과는 Rec.709 빨강 원색 (약 0.64, 0.33) 쪽으로 이동합니다. 색을 다른 RGB 기준으로 변환한 뒤 채널별 곱셈을 하면, 변환과 곱셈의 순서가 서로 교환되지 않기 때문입니다.

4. Blender 5.0에서 같은 씬을 비교했습니다

Blender 5.0.0에서 같은 sRGB 알베도 텍스처와 확산 재질, 조명, 카메라를 사용했습니다. 파일의 Working Space만 Linear Rec.709와 ACEScg로 바꾸고 각각 Cycles로 렌더했습니다. 두 출력은 같은 AgX View Transform과 sRGB 디스플레이를 사용했습니다.

빨간 벽 위 모서리는 Rec.709에서 (206, 58, 24), ACEScg에서 (191, 33, 1)로 눈에 띄게 진해졌습니다. 반면 흰 천장·뒷벽·바닥은 0~2 코드 차이에 그쳤습니다. 흰 면은 세 채널에 같은 값을 곱하므로 어느 원색 기준에서 곱해도 결과가 같고, 빨간 면을 두 번 이상 거친 빛에서만 위 표처럼 색도가 갈라지기 때문입니다. 변화의 크기는 씬의 재질·광원·설정에 따라 달라지므로 이 결과를 모든 렌더러의 기준으로 보면 안 됩니다. Blender 공식 문서도 작업공간 간 색 변환은 근사치일 수 있어 수동 보정이 필요하다고 안내합니다.

간접광 색 차이는 넓은 색역이 자동으로 만든 효과가 아니라, 서로 다른 RGB 원색 기준에서 색이 있는 면을 거칠 때마다 채널별 곱셈이 누적된 결과입니다.

색상 태그가 제대로 된 입력도 작업 공간에 따라 GI 계산이 달라질 수 있습니다. 반대로 텍스처가 잘못 해석되면 직접광과 첫 반사부터 색이 달라질 수 있습니다. 두 원인을 분리해서 보는 것이 핵심입니다.

5. 렌더에서 바로 확인할 순서

• 먼저 같은 렌더 파일을 두 View Transform으로 표시해 봅니다. 화면 룩만 달라지고 픽셀 계산이 같다면 표시 변환 쪽입니다.
• 렌더 계산이 달라졌다면 파일의 Working Space가 바뀌었는지 확인합니다. 프로젝트 중간에 바꿨다면 기존 데이터 블록의 색 변환 여부도 확인합니다.
• 알베도 텍스처는 sRGB, 노멀·러프니스 등 데이터 맵은 Non-Color인지 확인합니다. 같은 RGB 코드값을 색 변환 없이 두 작업공간에서 읽으면 애초에 같은 색이 아닙니다.
• 재질·광원·View Transform을 고정한 작은 테스트 씬에서 직접광 영역과 간접광 영역을 따로 비교합니다.

Maya에서 ACES를 켠 뒤 화면 색이 바뀐 상황도 표시 변환과 입력·작업 공간을 나누어야 합니다. 차이가 화면에만 보이는지, GI 계산에도 들어갔는지 먼저 구분하면 Maya ACES 색 변화의 원인을 확인할 때도 도움이 됩니다.

결국 먼저 확인할 것은 원색 기준과 텍스처 변환입니다. Working Space를 바꾸면 RGB 숫자뿐 아니라, 그 숫자를 다시 곱해 얻는 간접광도 달라질 수 있습니다.