본문 바로가기
vfxai 잡학지식 vfxai 잡학지식

서브스턴스 페인터에서 본 색과 렌더 색이 다를 때: 페인터 OCIO·ACES 설정과 내보내기 색공간

vfx 잡학지식 읽는 시간 약 15분

서브스턴스 페인터 색공간 설정을 그대로 두고 마야로 넘기면, 페인터에서 딱 맞게 칠한 주황이 렌더에서는 더 어둡고 진하게 나옵니다. 어떤 날은 반대로 물 빠진 듯 연하게 나옵니다. 텍스처 파일은 한 픽셀도 바뀌지 않았는데, 그렇다면 둘 중 어느 화면이 진짜 색일까요?

이럴 때 흔한 대응은 페인터로 돌아가 채도를 내리고 밝기를 올리는 것입니다. 렌더를 다시 돌리면 이번엔 다른 색이 어긋납니다. 페인터 화면과 렌더를 맞추는 일은 색을 다시 칠하는 일이 아니라, 세 자리의 짝을 맞추는 일입니다. 이 글은 그 세 자리를 차례로 봅니다. 첫째 보기 변환, 둘째 내보내기 색공간과 입력 색공간, 셋째 작업 공간입니다. 어느 화면이 진짜였는지는 세 자리를 다 본 뒤에 답합니다.

메뉴 이름은 Substance 3D Painter 12 문서, 마야는 2022 이후 기본 OCIO 설정, 후디니는 현행 SideFX 문서 기준입니다.

서브스턴스 페인터 색공간 비교: 톤매핑 없는 보기, ACES 보기 변환, sRGB 텍스처를 Raw로 읽은 경우의 같은 색 공 네 개
같은 네 가지 색, 같은 조명입니다. 가운데 줄은 보기 변환만, 아래 줄은 텍스처를 읽는 규칙까지 바꿨습니다. three.js로 계산한 그림이며 ACES 줄은 ACES Filmic 근사 커브라 마야의 ACES 1.0 SDR-video와 수치가 똑같지는 않습니다.

서브스턴스 페인터 색공간은 세 자리에서 짝을 맞춥니다

텍스처 파일에 든 것은 색이 아니라 숫자입니다. 그 숫자가 화면의 색이 되기까지 규칙이 세 번 끼어듭니다. 프로그램 안에서 숫자를 섞는 공간이 있고, 파일로 내보내고 다시 읽을 때의 규칙이 있고, 마지막으로 모니터에 보여 줄 때의 규칙이 있습니다. 페인터와 마야가 이 세 규칙을 같은 짝으로 쓰면 색의 해석 차이가 줄어듭니다.

서브스턴스 페인터와 마야에서 짝을 맞출 세 자리: 작업 공간과 렌더 공간, 내보내기 색공간과 입력 색공간, 양쪽 보기 변환
세 등호가 모두 맞아야 색의 해석을 맞출 수 있습니다. 번호는 이 글에서 보는 순서입니다. 개념도이며 실제 프로그램 화면이 아닙니다.

위 그림의 세 등호가 이 글의 순서입니다. 증상으로 보면 대략 이렇게 갈립니다. 렌더가 전체적으로 더 진하고 대비가 세다면 보기 변환을 먼저 봅니다. 렌더가 뿌옇고 연하다면 내보내기와 입력 색공간을 먼저 봅니다. 채도가 아주 높은 색만 어긋난다면 작업 공간을 봅니다.

1. 보기 변환: 렌더가 더 진하고 어둡게 보일 때

사진 앱에서 같은 사진에 필터를 바꿔 끼우면 색이 달라 보이죠. 원본 파일은 그대로입니다. 3D 프로그램도 화면에 보여 주기 직전에 이런 필터를 하나 씌웁니다. 계산에 쓰는 선형 값을 모니터에 맞게 바꾸고, 밝은 부분을 부드럽게 눌러 담습니다. 이 필터를 보기 변환(View transform)이라고 부릅니다.

문제는 프로그램마다 기본 필터가 다르다는 점입니다. 페인터의 Legacy 모드는 Display Settings > Camera settings > Tone mapping의 Function 기본값이 Linear입니다. Adobe 문서는 이것을 변환 없음, 1.0을 넘는 값은 잘라 냄이라고 설명합니다. 반면 마야는 2022부터 렌더 공간이 ACEScg, 기본 보기 변환이 sRGB 모니터용 ACES 출력 변환(ACES 1.0 SDR-video)입니다. 같은 텍스처라도 마야 쪽은 S자 커브가 한 번 더 걸린 화면입니다. 위 그림 가운데 줄처럼 어두운 쪽은 더 가라앉고 채도는 올라가며, 흰색은 살짝 회색으로 눌립니다.

후디니는 또 다릅니다. SideFX 문서에 따르면 뷰포트의 Color Correction 바 기본값은 sRGB – Display와 Un-tone-mapped, Render Working Space 기본값은 Linear Rec.709(sRGB)입니다. 톤매핑이 없다는 점에서 페인터 Legacy 화면에 가깝지만, 스튜디오 OCIO 설정을 쓰면 또 바뀝니다.

프로그램기본 보기 변환바꾸는 곳
Painter (Legacy)Linear, 톤매핑 없음Display Settings > Camera settings > Tone mapping > Function (Linear / ACES)
Painter (OpenColorIO)OCIO 설정이 정한 값뷰포트 위쪽 드롭다운. 왼쪽 버튼은 보기 변환 끄기
Maya 2022 이후sRGB / ACES 1.0 SDR-videoPreferences > Color Management > Display, View. Render View 툴바에서 임시로 바꾸기
HoudinisRGB – Display / Un-tone-mapped뷰포트 Color Correction 바, OCIO 설정의 View Transform

맞추는 방법은 한쪽으로 통일하는 것입니다. 최종 렌더를 ACES 보기로 판단할 거라면 페인터도 ACES로 봅니다. Legacy 모드에서는 Tone mapping Function을 ACES로 바꾸면 가까워지고, OpenColorIO 모드에서는 마야와 같은 설정의 같은 보기를 고르면 됩니다. 반대로 지금 당장 텍스처 값만 비교하고 싶다면 마야 Render View에서 View를 Un-tone-mapped로 잠깐 바꿔 봅니다. 마야 문서도 이 View는 미리보기용이고, Apply Output Transform to Renderer를 켜지 않으면 렌더 파일에 굽히지 않는다고 적고 있습니다.

페인터 OCIO 모드의 보기 드롭다운에는 하나 주의할 점이 있습니다. 이 값은 모니터마다 다를 수 있어서 프로젝트에 저장되지 않습니다. 동료 자리에서 프로젝트를 열면 다른 보기로 보고 있을 수 있습니다. 그리고 페인터에는 화면과 숫자가 다르다는 걸 스스로 인정하는 기능이 하나 있습니다. 뷰포트에서 Shift를 누른 채 스포이드로 찍으면 화면에 보이는 색이 아니라 채널에 저장된 값을 가져옵니다. 이 기능은 뒤에서 다시 꺼냅니다.

보기 변환을 맞췄는데도 렌더가 뿌옇고 연하다면, 필터가 아니라 파일을 건네는 쪽에서 어긋난 것입니다.

2. 내보내기 색공간과 입력 색공간: 렌더가 연하게 뜰 때

섭페 마야 색감을 묻는 질문에도 “너무 연하게 나온다”는 말이 있습니다. 이 증상은 보통 파일을 쓴 규칙과 읽은 규칙이 다를 때 생깁니다. Adobe 직원은 포럼에서 Legacy의 색관리 채널이 sRGB 감마 인코딩으로 나간다고 확인했습니다. 다만 답변은 파일 형식별 차이를 구분하지 않으므로, EXR의 인코딩은 여기서 단정하지 않습니다. 이처럼 sRGB로 인코딩된 파일을 마야가 Raw로 읽으면 감마를 벗기지 않은 숫자가 그대로 빛 계산에 들어갑니다. 중간 밝기 값이 실제보다 커지니, 위 그림 아래 줄처럼 밝고 물 빠진 색이 됩니다.

어떤 채널이 색으로 나가고 어떤 채널이 데이터로 나가는지는 페인터가 정해 둡니다. Base color, Diffuse, Specular, Coat color, Sheen color, Scattering color, Specular edge color, Transmissive가 색관리 채널이고, Roughness, Metallic, Normal, Height, AO, Opacity는 데이터입니다. User 채널은 기본이 데이터이고 Texture Set 설정에서 Color channel을 켜야 색으로 다룹니다. 채널 저장 형식(sRGB8, RGB16F 등)은 이 구분과 상관없다고 문서에 따로 적혀 있습니다.

페인터에서 나간 파일마야 file 노드 Color Space
Legacy, Base color 8·16비트 PNG·TGA·TIFFsRGB
OCIO, 내보내기 색공간이 sRGB 계열 텍스처같은 이름의 sRGB 텍스처 색공간
OCIO, 내보내기 색공간이 ACEScg인 EXRACEScg
Roughness, Metallic, Normal, HeightRaw

데이터 맵을 왜 Raw로 읽는지는 마야 Color Space에서 sRGB와 Raw를 고르는 기준과 Roughness·Metallic 맵을 Raw로 두는 이유에 정리해 두었습니다. 여기서는 페인터 쪽에서 내보내기 색공간을 어디서 확인하는지만 봅니다.

OpenColorIO 모드로 바꾸면 내보내기 색공간이 화면에 드러납니다. 프로젝트 설정의 Export color spaces 칸이 8 bit, 16 bit, Floating point 세 개로 나뉘어 있습니다. 같은 Base color라도 PNG로 내보내느냐 EXR로 내보내느냐에 따라 다른 색공간으로 나갈 수 있습니다. 실제로 어떻게 나가는지는 Export textures 창의 Output maps 목록에서 파일마다 확인할 수 있습니다. 출력 템플릿의 파일 이름에 $colorSpace를 넣으면 색공간 이름이 파일명에 붙습니다. 마야 Input Color Space Rules의 Add Color Space Name Rule을 쓰면 파일 경로 속 색공간 이름으로 입력 색공간을 자동 지정할 수 있습니다. 이 방식은 두 프로그램이 같은 OCIO 설정의 같은 이름을 쓸 때만 맞아떨어집니다.

Legacy 모드에서 색 채널을 EXR로 넘겨야 한다면 OCIO 모드로 바꿔 Floating point 칸을 직접 정해 두는 편이 안전합니다. Legacy에는 형식별 내보내기 색공간을 고르는 칸이 없어서 파일에 무엇이 담겼는지 화면에서 볼 수 없습니다.

3. 작업 공간: 페인터 OCIO·ACES 설정을 고르는 기준

마지막 자리는 프로그램 안에서 색을 섞는 공간입니다. 페인터 OCIO 설정은 새 프로젝트 창이나 Project configuration 창의 색관리 항목에서 고릅니다. Color management를 OpenColorIO로 두면 설정 파일을 고를 수 있습니다. 문서 기준으로 Substance는 Linear(선형) 작업 공간을, ACES 1.0.3과 ACES 1.2는 ACEScg를 작업 공간으로 씁니다. Custom을 고르면 스튜디오의 config.ocio를 지정합니다. 버전에 따라 목록이 다르고, 11.0.3부터는 ACES 2.0 설정도 들어 있습니다.

고르는 기준은 렌더 쪽입니다. 마야가 ACEScg로 렌더한다면 서브스턴스 페인터 ACES 설정이나 마야와 같은 config.ocio를 쓰는 것이 짝입니다. 작업 공간이 선형 sRGB와 ACEScg로 다르면 채도가 아주 높은 색에서 차이가 먼저 드러납니다. ACEScg가 담을 수 있는 색의 범위가 더 넓기 때문입니다. 스튜디오에서 OCIO 환경 변수를 잡아 두었다면 페인터는 그 설정을 따르고 UI의 색관리 설정은 잠깁니다. 같은 환경 변수를 마야도 읽으니, 이때는 두 프로그램이 처음부터 같은 규칙집을 씁니다. OCIO 설정 파일이 무엇인지는 OCIO의 구조, ACEScg를 쓰는 이유는 ACES 개요에서 다뤘습니다.

ACES 작업 공간에서 내보낼 때는 비트 깊이를 같이 정합니다. 넓은 밝기 범위의 선형 값은 8비트로 저장할 때 계조가 부족해질 수 있습니다. 그래서 8·16비트 파일은 sRGB 계열 텍스처로, EXR은 작업 공간인 ACEScg로 내보내는 구성이 무난합니다. 어느 쪽이든 마야에서는 페인터가 쓴 이름 그대로 입력 색공간을 고르면 됩니다.

정할 시점도 중요합니다. 색관리 모드는 Project configuration에서 나중에 바꿀 수 있지만, 이미 칠한 레이어의 색이 새 작업 공간에서 어떻게 보일지는 다시 봐야 합니다. 프로젝트를 시작할 때 정하고, 중간에 바꿀 거라면 사본으로 먼저 열어 봅니다. 브랜드 색처럼 정확한 값이 필요하면 색 선택기의 헥스 칸을 쓰세요. 문서에 따르면 헥스 값은 색관리 중에도 늘 표준 sRGB로 해석됩니다.

여기까지 정리하면, 화면이 진하면 보기 변환, 연하면 내보내기와 입력, 원색만 어긋나면 작업 공간입니다. 이제 처음 질문으로 돌아갑니다.

어느 쪽 화면이 진짜 색이었을까

앞에서 Shift 스포이드를 기억하시나요? 화면에 보이는 색이 아니라 채널에 저장된 값을 가져오는 기능이었습니다. 페인터가 이 기능을 따로 둔 이유는 화면의 색과 채널의 숫자가 같지 않기 때문입니다. 페인터 화면은 그 숫자에 페인터의 보기 변환을 씌운 모습이고, 마야 렌더 뷰는 같은 숫자를 마야의 입력 규칙으로 읽어 마야의 보기 변환을 씌운 모습입니다.

파일 속 숫자와 그 색공간이 색을 정하고, 두 화면은 그 값을 각자의 규칙으로 읽어 보여 줍니다.

그래서 색을 다시 칠해 맞추면 한쪽 규칙에 맞춘 숫자가 생깁니다. 다음 샷에서 보기 변환이 바뀌면 그 숫자는 다시 틀립니다. 규칙의 짝을 맞추면 숫자는 그대로 두고 두 화면의 색 해석을 맞출 수 있습니다.

짝을 맞췄는지 확인하는 순서

  1. 보기 변환: 페인터 뷰포트 드롭다운(또는 Legacy의 Tone mapping Function)과 마야 Render View의 View 이름을 나란히 적어 봅니다. 다르면 한쪽으로 통일합니다.
  2. 내보내기: Export textures 창 Output maps에서 Base color 파일의 형식과 색공간을 확인합니다. Legacy에서 8·16비트 색 채널은 일반적으로 sRGB 인코딩으로 다룹니다. EXR의 인코딩은 파일 형식별 근거가 없어 단정하지 않습니다.
  3. 입력: 마야 file 노드의 Color Space를 2번에서 본 이름과 같게 둡니다. 데이터 맵은 Raw입니다.
  4. 작업 공간: 페인터 OCIO 설정과 마야 Rendering Space가 같은 계열인지 봅니다. ACEScg로 렌더한다면 페인터도 ACES 설정이나 같은 config.ocio를 씁니다.
  5. 비교: 마야에서 같은 HDRI 하나만 켜고 페인터와 같은 각도에서 봅니다. 연함과 진함이 사라졌다면 짝이 맞은 것입니다.

그래도 남는 차이는 조명과 셰이더입니다

세 자리를 맞추면 색공간과 보기 변환에서 오는 차이는 줄어듭니다. 그래도 조명과 셰이더 차이는 남을 수 있습니다. 페인터 뷰포트는 실시간 셰이더와 자체 환경맵으로 그리고, 아놀드는 씬의 조명으로 경로를 추적합니다. 환경맵이 다르면 같은 재질도 다르게 보입니다. 비교할 때는 같은 HDRI를 양쪽에 걸고, 페인터에서는 Display settings의 Override environment map color space로 그 HDRI의 색공간까지 맞춥니다. 베이크한 맵 자체에 얼룩이 보인다면 색이 아니라 베이크 문제이니 페인터 베이크 검은 얼룩 점검을 먼저 보세요.

한 줄 정리

페인터 색이 렌더와 다르면 색을 다시 칠하지 말고, 보기 변환과 색공간과 작업 공간의 짝부터 맞추세요.

메뉴 이름과 기본값은 Adobe·Autodesk·SideFX 공식 문서에서 가져왔습니다.

vfx 잡학지식

함께 보면 좋은 글

댓글 0

첫 댓글을 남겨보세요.