[번역]Color-management in Substance Painter with OCIO
jplee2023. 8. 29. 01:30
번역자 코멘트. 개인적으로는 가장 그것에 대해 정리를 잘 해 논 토픽이다. 이 토픽을 잘 읽어봐야 하는 이유는 군데 군데 매우 정교한 지적이 숨어 있기 때문이다. 서브스턴스 페인터의 자잘한 버그 라던가 숨은 기능이라든가 말이다. ACES 관련 된 잘 정리 된 mrlixm 의 토픽을 개인적으로 리마인드 할 생각으로 번역 했습니다. 사실 번역이라기 보다는 구글 번역기로 쭉 돌린 후에 처음부터 하나 하나 읽어 내려가면서 어색한 어휘를 수정 했고 영어 어휘보다는 한국사람에게 친근한 문장으로 교정 했다고 볼 수 있어요. 모든 한글작성은 직접 모두 타이핑 한 겁니다. 그래서 오타가 있을 수도 있어요. 번역의 오류가 있으면 직접 수정 가능 합니다. 번역문 교정 제안이 있다면 leegoonz@163.com 으로 연락 할 수 있습니다.
드디어! 너무 오랜 시간이 흘렀지만 결국 서브스턴스 페인터는 마침내 OCIO 지원으로 빛나는 새로운 색상 관리 시스템을 추가 했어요. 이제 이것이 어떻게 작동하는지 깊이 있게 살펴보자.
이 문서는 크게 두 부분으로 나뉜다. 먼저 생상관리 작동방식을 설명하는 이론적인 부분.
이렇게 하면 문제를 디버깅하고 감춰져있는 설정들을 조정하지 않을 수 있어요.
OCIO 는 서브스턴스 페인터 버전 7.4에 도입되었다. 이 문서에서 사용하는 버전이며 일부 기능은 이 문서를 읽을 때 변경 될 수 있습니다. 나는 이 토픽을 변경 사항에 따라 업데이트 정보를 유지 할 생각입니다.
Color-managed Workflow 색상관리 워크플로우
이 부분은 초보자를 대상으로 하지만, 이 문서에 대한 너무 광대 한 주제를 소개하고 있습니다. 나는 당신이 여기에 사용 된 기술 어휘의 일부를 이해하기 위해, 먼저 색상영역에 대한 Chris Brejon 의 토픽 섹션을 먼저 읽어 보길 추천 드립니다.
워크플로우를 4개의 섹션으로 나눌 수 있어요. Input, Workspace, Display 그리고 Output
이러한 각 센션 간에 전송합니다. 섹션에 필요한 항목에 따라 디코딩한 다음 인코딩해야 합니다. 서브스턴스 페이터에서 이것은 RGB 색상 모델을 사용하여 인코딩 된 대부분의 타임픽셀입니다.
이러한 모든 데이터 전송을 통해 가장 중요한 규칙을 도입할 수 있습니다. 예를 들어 위의 다이어그램에서 입력데이터를 작업공간 데이터로 변환하려면 데이터가 인코딩 되는 방식(색상의 경우)을 알아야 합니다.
Data types: Color and Scalar 데이터 유형:생상 및 스칼라.
“어디서 부터 시작하느냐”의 첫 번째 의미는 어떤 데이터 타입을 조작 할 것인가? 입니다.
여기에는 color 그리고 Scalar 이 두 가지 유형만 있습니다.
스칼라 데이터는 데이터가 색상 관리를 요구하지 않고 이 때문에 복잡한 부분을 건너뛸 수 있으므로 데이터가 어느 데이터에 속하는지 아는 것이 중요합니다.
스칼라
스칼라 데이터는 직접 표시할 수단이 없으며 다른 유형의 데이터를 구동하는 데 사용할 수 있는 데이터 저장소의 번호입니다. 우리는 이 숫자의 원래 값에만 관심이 있으므로 이러한 종류의 데이터는 색상변환에 의해 변경되어서는 안됩니다.
더 구체적인 예를 보려면 스칼라 데이터에는 거칠기, 법선, 마스크, 변위 또는 벡터등의 다양한 것들이 이에 속합니다.
데이터가 표시될 때 회색조가 아닌 컬러 데이터라고 할지라도 이것은 스칼라 데이터인 경우가 있습니다. 예를 들어 노멀맵은 생상이 지정되어 있어도 스칼라 데이터 입니다.
컬러
스칼라가 아닌 모든 것. 저장된 값은 직접 표시하기 위한 것입니다. 이러한 값은 항상 일부 색상 공간으로 인코딩되며 올바르게 디코딩되어야 합니다.
여기에는 디퓨즈/알비도/기본색상, 표면 아래 색상, 반사 색상, 굴절 색상, 웹에 표시되는 모든 이미지 등이 포함될 수 있어요.
In Substance / 서브스턴스에서...
서브스턴스에서는 작접 중인 채널에 따라 이 분리를 찾을 수 있습니다.서브스턴스는 채널의 색상관리가 필요한지 알고 있으므로 일부 작업은 조정을 건너 뜁니다. 스칼라 채널을 볼 때 비활성 되는 어플리케이션 입니다.
이 개념은 리소스(이미지,알파, 재료 등) 의 색상 공간 인코딩을 지정해야 할 때 스스로 적용됩니다.
거칠기 텍스처를 가져오는 경우 스칼라 데이터이므로”색상공간”을 “raw”로 지정해야 하므로 특별한 디코딩이 적용되지 않습니다.
Workflow Sections 워크플로 섹션
Input 입력
처리해야 하는 데이터는 무엇이든 될 수 있지만 우리의 경우 이미지 텍스처, 브러시 스트로크, 절차적 노이즈와 같은 픽셀데이터 등입니다.
스칼라라면 디코딩할 필요가 없습니다. 예를 들어 colorspace=”raw” 를 지정하여 색상변환을 원하지 않음을 지정 할 수 있죠.
색상인 경우 데이터가 지정된 색상 공간에서 필수로 인코딩되었음을 의미합니다. 이 인코딩이 이름, 메타데이터 어딘가에 지정되기를 바랄 수 있습니다. 그러나 색상관리는 2021년에도 여전히 혼란스럽기 때문에 대부분의 경우 전송 기능이 있는 sRGB 색상공간에 존재 한다고 가정합니다.
SP 에서 입력 섹션은 각 레이어의 이미지 슬롯에서 지정자를 찾을 수 있습니다.
Workspace / 작업공간
당신이 만들고 수정하는 모든 것은 거처가는 공간이에요. 입력을 변환할 때 항상 “가야 할 위치”를 알수 있도록 구성방법등을 정의합니다. SP 에서 이것은 “작업 색상 공간(Working color space)”입니다. OCIO 용어로 scene_linear역할(또한 reference 의 하나입니다.)에 해당합니다.
SP는 OCIO 역할을 지원하지 않지만 Working Colorsapce 로 사용하기 위해 scene_linear 의 하나를 읽어 드립니다.
Display / 표시
데이터가 workspace 를 통해 처리되면 당신은 그것을 프리뷰 할 수 있어요.
그렇게 하기 위해 모두 일종의 하드웨어 디스플레이 모니터를 사용하게 될겁니다. 이것은 꽤 어리석게 들릴지 모르지만 중요한 단계입니다. 따라서 여기에서 workspace 데이터를 디스플레이 데이터로 변환해야 하고 이 단계에서 할 일들이 꽤 많습니다.
작업공간을 “개방형 영역”으로 볼 수 있습니다. 데이터를 멋진 색상공간에 저장할 수 있고 매우 높은 값에 도달할 수 있습니다. 그런 다음 디스플레이를 “폐쇄 영역”으로 볼 수 있습니다. 단,특별히 인코딩 된 신호를 제외하고 명확하게 정의 된 한계가 있습니다. 소스(작업공간)를 알면 대상(디스플레이)으로 변환하는 데 필요한 변환을 정의할 수 있습니다. 이것은 그것의 핵심,색상공간 기본 변환(작업 공간 색상 공간이 디스플레이 생상 공간과 다른 경우),전달 기능 인코딩/재인코딩(선형작업 공간을 sRGB 로 전달하는 기능이 필요한 디스플레이로 변환하기 위해...)및 기타 고급 단계, 동적 범위 변환(필요한 경우 여전히...).
복잡한 일이지만 어쨌든 명심해야 할 것은 우리가 사용중인 디스플레이에 의해 정의 된 구분된 영역(도메인)에 대한 데이터를 인코딩한다는 것입니다.
SP 에서 디스플레이 섹션은 view-transform 뷰포트의 오른쪽 상단에서 찾을 수 있는 드롭다운 메뉴로 처리됩니다. SP 의 디스플레이 설정을 참조하십시오.
Output
그러나 디스플레이가 출력의 끝이 아닌거죠? 네, 당신이 작업단계의 끝에 있다면 그럴 수 있습니다. 그러나 여기 SP 에서 단계의 끝은 내보낸 텍스처 파일입니다. 디스플레이를 통해 어떻게 보일 수 있는지 미리 볼 수만 있습니다.
따라서 여기에서는 다음 파이프라인 단계에 필요한 작업 공간 데이터를 인코딩 합니다. 인코딩은 다음 단계에서 필요한 것과 선택한 이미지 형식에 따라 달라집니다.
SP 에서 출력 섹션은 텍스처 내보내기 프로세스 중에 발생합니다. SP 의 출력 설정을 참조 하십시오.
Example
이론을 설명하기 위해 임의로 제가 구성한 VFX 파이프라인 섹션을 나타내는 다이어그램이 있습니다.(역자 주> 지극히 예를 들기 위한 구성) 이것은 어쩌면 주제보다 더 당신을 혼란스겁게 할 수도 있겠네요.☹️
각 섹션에 사용되는 다양한 색상 공간 구성이 있는 색상 관리 파이프라인의 예.
잠재적인 변형을 강조하기 위해 부서와 섹션에 걸쳐 다른 색상 공간을 임의로 선택 했어요.
색상 관리를 위해 ACES 와 함께 작동하도록 선택 함.
이 파이프라인에서 작업하는 모든 사용자가 DCI-P3 보정 모니터인 동일한 디스플레이에 액서스 할 수 있다고 가정 해 보겠습니다.
Substance Painter SP 부분을 보면 작업공간이 linear - sRGB 이며 아티스트는 ACEScg 색상공단 작업을 귀찮게 하지 않고 대신 sRGB 원색을 사용하기로 결정 했습니다. 이것은 디스플레이의 경우 색상 변환 체인이 다음과 같다는 것을 의미 합니다. linear - sRGB > linear - ACES 2065-1 + ACES RRT > 2.6 gamma - DCI-P3
뷰포트의 오른쪽 상단에 위치
그리고 이러한 모든 변환은 OCIO 구성에 의해 마술처럼 처리되며 아티스트는 미리보기 의 색상공간 변환 섹션을 수정하여 사용중인 디스플레이만 지정합니다. 마지막으로 동일한 Workspace 색상공간에서 텍스처를 내보냅니다.
Maya 이제 우리는 Maya 단계에 있습니다. Assets 에 텍스처를 적용해야 하면 최종 목표는 자산에서 렌더를 만드는 것입니다. 작업공간은 이제 ACEScg 입니다. 이것은 sRGB에 있는 텍스처를 이 색상 공간으로 변환해야 함을 의미 합니다. 디스플레이는 동일하여 현재 ACEScg인 소스 색상 공간만 변경됩니다.
Nuke Nuke는 입력 렌더링이 이미 ACEScg에 있으므로 변환이 필요하지 않기 때문에 Maya 와 동일한 작업공간을 유지합니다. 이것이 파이프라인 끝이므로 여기에 출력에 대한 몇 가지 가능성이 더 있습니다. 여기서 우리는 sRGB 디스플레이에서 합성된 렌더를 볼 수도 있기를 원합니다. 따라서 출력은 sRGB 디스플레이용으로 인코딩되어야 하므로 DCI-P3 디스플레이용으로 인코딩 된 출력을 사용할 수 없습니다.
Now, let’s put into practice the theory …
결국 해 내겼군요! 색상 과학은 복잡한 주제이므로 처음에 모든것을 이해하지 못하더라고 걱정하지 마세요. 이문서의 끝 부분에서 더 깊에 이것에 대해 알아갈 수 있는 추가 리소스를 찾을 수 있을겁니다. 이제 이론을 실천 해 봅시다.
Substance Setup & Workflow
Color-management is not application-dependent but project-dependant.
New Project
이러한 새 옵션의 첫 번째 항목은 New Project 창에서 찾을 수 있습니다. Color management 하단에 하위 메뉴가 있습니다.
💡 프로젝트 설정에서 언제든지 모든 색상관리 설정을 변경할 수 있습니다. 그러나 큰 변경으로 인해 프로젝트가 중단될 수 있습니다.
SP 에서 제공하던 Legacy 와 OpneColorIO 컨피그레이션 모드는 더 이상 유용하지 않기때문에 건너 뜁니다.
💡 특정 OCIO 구성을 사용할 필요가 없더라고 OCIO 모드를 사용하도록 권장하는 sRGB 워크플로에 대한 기본 구성을 제공합니다.
OCIO config
여기서 잠깐! OCIO 란 무엇입니까? 왜 사용해야 합니까?
OCIO 는 원래 Sony Picrture Imageworks 에서 DCC 간의 색상관리 일관성을 강화하기 위해 개발한 색상 관리 솔루션 입니다.
OCIO 자체는 활용 기준만 정의하고 작업 도구를 제공하지만 시스템의 핵심은 OCIO 구성(.ocio 파일) 입니다. 여기에서 모든 색상 변환 및 옵션이 정의됩니다. 예를 들어 ACES는 자체적으로 색상 관리 시스템이지만 OCIO를 통해 버전을 제공합니다.
주요 장점은 OCIO 가 대부분의 소프트웨어에서 지원되므로 모든 DCC 를 통해 이론적으로 동일한 결과를 얻을 수 있습니다.
편의를 위해 SP 는 이미 3자기 OCIO 구성을 제공하고 있어요.
Substance
ACES 1.0.3
ACES 1.2
다음과 같은 SP 설치 폴더에서 찾을 수 있습니다.
C:\Program Files\Allegorithmic\Adobe Substance 3D Painter\resources\ocio
솔직히 말해서, 왜 그들이 두 개의 ACES 버전을 포함했는지 이해할 수 없지만 아무튼 우리는 마지막 버전만 필요 하며 또한 기본 구성이 있다는 것은 매우 멋진 일이죠.
여기에 많은 유연성이 있습니다. 첫 번째 옵션은 제공 된 구성을 사용하는 것입니다. 2개의 ACES 구성은 절대 필요하지 않을 것 같은 수백 개의 색상공간이 있는”기본”개발 구성입니다.
사용하는 것이 좋겠죠. Cave academy 에서 제공하는 것과 같은 가벼운 ACES 구성( ACES 워크플로 섹션 참고)
기존의 Substance sRGB 선형 워크플로를 사용하고 모든 DCC에서 OCIO 구성을 사용하지 않으려는 경우 구성이 적합합니다. 적절한 색상관리 워크플로를 가질 수 있는 충분한 제어권이 있습니다.
이제 사용자 지정 OCIO 구성을 로드하는 방법을 살펴보겠습니다.
Custom config / 사용자 구성.
첫 번째 옵션은 사용자 옵션을 사용하고 수동으로 config.ocio 파일을 여러분의 디스크에서 불러 오는 것입니다.
구성 경로에 대한 참조만 프로젝트에 저장됩니다. Custom 옵션을 통해 OCIO 구성을 호출할 때 구성은 항상 디스크에서 실시간으로 로드 됩니다. 즉, 동일한 경로에 구성이 없는 다른 아티스트와 프로젝트를 공유하는 경우 아래와 같은 경고 문구가 표시됩니다.(The configuration file cannot be found.please choose a valid file path.)
설정을 계속하려면 하단 섹션 OCIO 구성에 대한 물질 매개변수를 참조 하세요.
Environment variable / 환경 변수.
위의 사항은 개별 아티스트에게 충분할 수 있지만 파이프라인 환경에 있는 경우 OCIO를 자동으로 설정하는 다른 방법이 필요합니다.
OCIO 환경변수가 있고 유효한 구성파일이 있는 경우 UI 설정을 무시하고 비활성화하는 작업을 인계받습니다.
Windows에서는 환경변수를 설정하는 두 가지 방법이 있습니다.
Global Settings / 전역설정.
구성 경로를 사용하여 OCIO 라는 새 변수를 생성합니다. 이 변수는 이를 읽을 수 있는 모든 소프트웨어에서 사용 할 수 있습니다. ( 별도로 다시 정의 하지 않는 한...) 이것은 환경변수를 수정하는 것이기 때문에 권장되는 방법은 아닙니다.(저자 주) 다른 구성으로 전환하기로 결정하면 이전 프로젝트에 모두 영향을 미칩니다.
Set locally at startup / 시작 시 로컬로 설정
Start-up 스크립트에서 환경 변수를 정의했습니다. 이것은 가장 깔끔한 방법이지만 Windows 바로가기를 사용하여 소프트웨어를 시작 할 수 없음을 의미 합니다.
.bat 는 소프트웨어를 구성하고 실행하기 위해 사용 합니다. 다음은 .bat 안에 OCIO 변수를 설정하고 SP 를 실행하는 가장 기본 적인 스크립트 구조를 보여줍니다.
set "OCIO=C:\aces_1.1\config.ocio"
start "" "C:\Program Files\Allegorithmic\Adobe Substance 3D Painter\Adobe
Substance 3D Painter.exe"
Substance parameters for OCIO configs / OCIO 구성을 위한 매개변수.
Substance 구성이 올바르게 구성된 OCIO.
색상관리 모드 모든 섹션에 해당하며 기본적으로 어떤 색상공간이 할당되는지와 같이 입력이 OCIO 구성과 반응하는 방식을 구성할 수 있습니다.
일반적으로 다른 소프트웨어의 이러한 섹션은 OCIO 구성에 정의된 OCIO Roles를 사용하여 구성되지만 현재 SP 는 OCIO Roles를 지원하지 않습니다.
대신 working color space 모든 곳에서 기본 색상공간으로 사용하므로 수동으로 설정 할 수 있습니다. 섹션을 참조하여 자동설정과 같은 올바른 결과를 얻으십시오.
위의 이미지를 보면 Substance config를 선택했을 때의 모습니며 기본적으로 8비트와 16비트 이미지는 sRGB 이며 Substance designer 도 마찬가지입니다.
ACES 구성을 사용하는 경우 이것이 어떻게 고려되어야 하는지 알아보려면 ACES Workflow 섹션을 확인하세요
New Project : Conclusion
자 이제 새 프로젝트에 필요한 모든 것을 요약하자면 다음과 같습니다.
색상관리 모드를 OCIO 로 변경.
OCIO 구성 선택(env 변수가 설정된 경우 이미 선택됨)
Edit the OCIO options to have the correct default colorspaces working. 올바른 기본 색상공간이 작동하도록 OCIO 옵션을 편집합니다.
그리고 물론, 텍스처링과 관련된 다른 매개변수를 설정합니다. 이제 텍스처링 워크플로를 시작할 수 있습니다. 워크플로는 이 문서의 이론적 부분에서 설명한 것과 동일한 섹션으로 나뉩니다. (색상 관리 워크플로 참조)
Workspace Setup in Sp / SP에서 작업 공간 설정.
소프트웨어에서 작업공간은 실제로 “추상적인”섹션입니다. 모든 색상변환에 대한 참조,대상 또는 소스로 사용되는 색상공간을 나타냅니다. OCIO 구성에 정의되어 있으며 외부에서 변경할 수 없습니다.
💡 OCIO 구성에서는 scene_linear 역할에 해당합니다.
프로젝트 색상관리 섹션에서 볼수 있음.(여기에서는 ACES 1.2 OCIO 구성 사용)
여기서 사용되는 색상 공간이 무엇인지 아는 것이 좋습니다.
Display Setup in Sp
작업하기 전에 좋은 첫 번째 단계는 잘못된 색상을 보는 동안 텍스처링을 시작하지 않도록 Display 부분이 올바르게 구성됬는지 확인하는 것입니다. 이 Display 부분은 일반적으로 보기-변환 메뉴라고 하는 것을 사용하여 구성할 수 있습니다. SP 에서는 뷰포트의 오른쪽 상단에서 찾을 수 있습니다.
기억해야할 것은 디스플레이에 해당하는 옵션을 선택해야 하다는 것입니다. 디스플레이가 Display P3 색상공간(Apple Display)으로 보정된 경우 Display P3 옵션을 선택하세요.
But what if I don’t know what my display is calibrated to ?
하지만 내 디스플레이가 무엇으로 보정되었는지 모른다면 어덯게 해야합니까?
안전한 선택은 sRGB와 유사한 디스플레이를 사용하고 있다고 가정하는 것입니다.
sRGB 대신 Rec.709를 사용하는 사람들이 있습니다. 그 이유는 무엇입니까?
sRGB와 Rec.709는 같은 원색을 공유하므로 서로 다른 원색으로 인한 색상 변화를 보지않고 둘 다 사용할 수 있습니다. 변경되는 것은 전달 함수가 사용되는 것입니다. 그러나 여기에서 엉망이 됩니다. Rec.709 데이터는 디스플레이 인코딩이 아닌 카메라 신호 인코딩을 위한 OEFT만 정의했습니다! Rec.709 색상공간을 사용한 디스플레이 인코딩의 경우 간단한 2.4의 거듭제곱으로 재개할 수 있는 BT.1886 표준을 사용해야 합니다. 그렇다면 이 둘 중 어느것이 사용되고 있는지 어떻게 알 수 있습니까? 간단히 sRGB와 비교할 때 이미지가 더 어둡게 보이면 OETF 이고 덜 대조적으로 보이면 BT.1886 입니다. 테스트를 수행하면 Substance 구성은 OETF(사용해서는 안됨)를 사용하고 ACES 구성은 BT.1886을 사용합니다.
내 질문에 대답하지 않았자나요? 나는 지금 더 혼란스럽네요.
앞서 쓴 것처럼 디스플레이에 맞는 옵션을 선택해야 하므로 디스플레이가 Rec.709+BT1886으로 교정되지 않았을 경우 사용하지 마세요. 그러나 디스플레이가 창의적인 선택이 되어서는 안됩니다. 덜 대조적인 모양을 좋아한다면 Look 에 적용해야 합니다.(아래 참조)
예를 들어 미리보기를 위해 Roughness 채널을 선택하면 view-transform 이 비활성화 된다.
Shelf Resources
SP에서 이 설정은 이상하게도 각 레이어의 이미지 슬롯에서 해야합니다. Shelf 에서 색상공간을 지정하는 옵션이 없어요.
기본적으로 자동(auto)으로 설정되어 있고 위에서 설명한 프로젝트 지정 설정을 사용합니다. (OCIO 구성을 위한 SP 매개변수) 리소스가 적절하게 생상 관리되는지 확인하려면 항상 이 옵션을 적절한 색상공간으로 수정해주는 것이 좋아요. 또 다른 옵션은 리소스 색상공간을 파일 이름으로 지정하는 것입니다. 색상공간이 구성에 사용된 정확한 이름이어야 하기 떄문에 제 생각에는 네이밍이 약간 지저분하더라도 그렇게 해 주는 것이 좋다고 생각해요. 2개의 구성이 다른 이름을 사용한 경우 이미지는 하나만 작동합니다. 예를 들어 ACES 구성에 사용된 색상공간 이름을 사용하면 다음과 같이 표시될 수 있죠. bricks_wall_albedo_Utility - Linear - sRGB.exr
The color-picker
사용 된 약어:
tcd : top colorspace dropdown 상단 색상 공간 드롭다운
eds : editable sliders, where you can manually enter your color components. 색상 구성요소를 수동으로 입력할 수 있는 편집 가능한 슬라이더.
첫 번째로 정말 좋은 기능은 위젯 작동방식에 대한 명시적인 정보를 제공하는 작은 정보 아이콘 입니다. 그러나 주어진 정보는 나쁜 소식을 가져오네요. tcd 옆에 있는 정보메시지를 보면:
이것은 화면 이미지를 표시하는 데 사용되는 표시 색 공간입니다. 편집 가능한 색상 값은 프로젝트의 작업 색상 공간 내에서 지정됩니다.
이것이 의미하는 바는 아래의 값 슬라이더에서 입력된 값이 항상 프로젝트의 작업 색상 공간에 의해 정의된 색상 공간에 있다는 것입니다. 따라서 tcb 에서 변경할 수 있지만 입력한 값은 수정되지 않습니다.
“tcb”는 인터페이스에 색상이 표시되는 방식만 수정합니다.(아래에 있는 “eds” 에서 표시된 값을 볼 수 있습니다.
따라서 tcd 보기 변환에서 사용되는 것과 동일한 색상 공간으로 설정하는 것이 좋습니다.
What about the actual picker? 실제 피커는 이제 어떻습니까?
마찬가지로 선택되는 값은 색상 공간으로 표현됩니다. tcd 의 영향을 받지 않아요. 그러나 약간의 큰 반전이 있습니다!
광범위한 테스트를 거친 후 불행히도 사용중인 OCIO 구성에 따라 색상피커는 일관되지 않았다. 난 여전히 그 문제의 원인이 무엇인지 확실하게 알수는 없었어요. 아래 두 가지 사례가 있습니다.
Case 1 : Display colorspaces and Shared Views (OCIO v2 new features)를 사용하는 OCIO v2 구성을 사용하고 있다.
컬러픽커는 디스플레이에서 값을 가져와(view-transform 이 적용된 후)반환됩니다. 이것은 view-transform 변환이 없는 경우에만 작동합니다. 즉, 비활성화되거나”passtrough/raw” 인코딩이 있는 디스플레이를 사용합니다. 적절한 보기 변환으로 색상 데이터를 보고 있는 경우 선택한 값은 사용한 원래의 값과 일치하지 않아요.
Case 2 : You are using an OCIO v1 config or v2 without the new features: 새로운 기능 없는 OCIO v1 구성 또는 v2 를 사용할 때.
컬러피커는 표시 할 때 값(보기 변환 포함)을 취한 다음 역시 디스플레이 변환을 적용합니다. 기본 설정, 즉 구성 또는 active_displays key에 정의 된 첫 번째 항목을 선택합니다. 슬라이더가 1을 초과하지 않기 때문에 결과는 0-1 범위 사이에서 고정되죠.
<aside> 💡 컬러 피커 정밀도 문제도 고려해야 합니다. 반전색상 변환을 적용하면 경우에 따라 부정확한 값이 리턴 될 수 있습니다. 또한 피커 작업 자체의 정밀도 문제도 있습니다.
</aside>
이것은 color picker 가 불행히도 다시 문제가 있음을 의미 합니다. 그러나 위의 사항을 염두에 두고 올바른 값을 얻을 수 있습니다.
**For Case 1 : • 값을 선택하고 싶을 때마다 보기 변환을 비활성화 하세요.
**For Case 2 : • Set the tcd to the default view-transform colorspace. tcd 기본 보기변환 색상공간으로 설정 합니다. • 값을 선택(피킹)합니다. • Display colorspace 에거 값을 확인 하고 그것을 eds 로 복사하세요.
There is no direct option to modify the environment image colorspace.
환경 이미지 색상 공간을 수정하는 직접적인 옵션은 없습니다.
원래 옵션은 아래와 같아요.
Linear 프로젝트 설정에서 기본 색상 공간을 수정합니다. 환경 맵에서 이를 사용.
HDRI의 이름에 소스 색상 공간을 포함합니다. 구성에 정의 된 것과 정확히 동일한 이름이어야 합니다. 예로 들어: myhdri_ACES-ACEScg.exr (ACES-Environment 예를 찾아볼 수 있어)
사전 통합된 HDRI는 linear-sRGB 색상 공간으로 인코딩 됩니다.
Masks
마스크를 마우스 오른쪽 버튼으로 클릭하면 Export mask as File 옵션이 있습니다. 마크스는 항상 스칼라로 간주외어 아무런 처리 없이 내보내지는 것 같으니 걱정마세요.
Output Setup in SP
텍스처 수출(export) 창은 그다지 새로운 것이 없어요. 창에서 수출(Eport) 할 때 색상 변환을 적용하는 옵션이 없습니다. 유일한 옵션은 프로젝트 설정에서 사용할 수 있는 것들이 전부입니다.
기본적으로 정수 형식은 sRGB 디스플레이로 인코딩 되어야합니다. 부동 소수점 형식은 동일한 작업 색상 공간을 사용해야 합니다.
하지만 새로운 기능 $colorspace token 은 출력 템플릿 에서 찾을 수 있다.
이는 단순히 프로젝트 설정에 정의된 색상공단으로 대체됩니다. LIST OF EXPORT 탭에서 파일 이름을 미리 볼 수 있음.)
저는 개인적으로 이 옵션을 선호하지 않아요. 색상 공간의 이름 지정 방식에 따라 파일 이름에 특수문자가 포함될 수 있기 때문이죠. 색상 공간 없이 텍스처 이름을 사용하는 것이 더 나은 옵션이지만 색상 공간 이름이 있는 디렉토리로 출력하는 것도 좋은 선택이라고 봅니다.
스칼라 채널의 경우 SP 는 색상 변환을 적용하지 않고 raw(구성에 상관없이) 색상공간을 사용하여 고려합니다. 흥미롭게도 이 색상공간은 토큰에 raw 를 기록하지 않아요.(7.4.1에서 수정)
ACES Workflow
나는 무엇을, 왜, 어떻게만 설명하지 않을겁니다. 잠재적인 다음 기사를 위해 남겨둘 필요가 있을가요?
ACES - Config setup
Substance와 함께 제공되는 것을 사용할 수 있지만 그렇게 권장하지는 않습니다. 그것들은 당신이 하나를 선택하야 할 때 당신을 느려지게 할 수백개의 색 공간을 가진 것들입니다.
대신 CAVE academy에서와 같이 필요한 것만으로 구성을 사용하는 것이 더 똑똑한 방법일 것입니다.
그런 다음 기본 색상 공간을 구성해야 합니다. 공식 ACES 와 동일한 명명법을 가진 Cave 구성을 사용하는 것이 좋습니다.
가져오기 설정은 일반적인 것이지만 대부분의 8비트 텍스처는 모두 sRGB가 아닌 경우 인코딩 된 파일을 표시하므로 utility-sRGB-Texture 에 해당합니다. EXR과 같은 부동소수점 이미지는 항상 선형이어야 하므로 대체 버전 Utility -Linear-sRGB 이 올바른 선택입니다. 이 옵션은 기본적으로 (auto 색상 공간과 함께) 적용되지만 언제든지 변경할 수 있음을 기업하십시오.
출력이 항상 쇼 아래의 스크린샷으로 인코딩된 sRGB 디스플레이인 것 같아서 Utility-sRGB-Texture 를 선택했습니다. (Substance materials 색상공간 옵션은 어쨌든 재료에서 수정 할 수 있습니다.)
출력을 위한 선택이 유일한 것은 아니다. ACEScg8 비트 파일을 내보내면 안된다. 그렇기 때문에 Utility - sRGB - Texture 를 사용하여 sRGB로 다시 인코딩한다. 올바른 옵션은 동일한 작업 색상 공간 ACEScg 에서 EXT 을 내보내는 것이다. 스칼라 채널은 내보낼 때 자동으로 처리되므로 걱정하지 마세요. 이러한 옵션은 경우에 따라 수정할 수 없는 유일한 옵션이다. 변경할 수 있는 유일한 곳이다.
ACES - What to do when working
ACES에 특정한 것이 있을 때만 자세한 설명을 드릴게요. 한편 substance setup & workflow 에 제공된 설명은 여전히 적용되므로 이 섹션을 제대로 이해했는지 확인 하십시오.
ACES - Display
그다지 새로운 것은 아니지만 사용중인 디스플레이에 해당하는 view-transform 을 사용하십시오.
ACES - Inputs
가져오는 모든 외부 리소스에 대해 자동 색상공간이 해당하지 않는 경우 올바른 입력 색상공간을 할당해야 합니다. ACES 워크플로에 대한 일반적인 규칙이 적용됩니다.
ACES - Environment
안타깝게도 환경의 색상공간을 변경하는 직접적인 옵션이 없어요. 그러나 기본 색상 공간 규범을 따른다. 그리고 부동 소수점 이미지니까 사전 정의 된 “유틸리티-선형-sRGB” 색상 공간을 사용한다. 따라서 sRGB(선형 인코딩)인 한에는 올바르게 표시 될거에요.
그러나 이미 변환 된 ACEScg HDRI 를 가져오면 어떻게 해야 할까요?
작동시키는 방법이 있어. 파일 이름에 색 공간을 지정할 수 있음. 색상 공간구성에 정의 된 것과 정확히 이름이 같아야 한다. be: myhdri_ACES - ACEScg.exr. 왼쪽은 sRGB 인코딩, 중간 및 오른쪽은 ACEScg 인코딩이다. 오른쪽은 제대로 변환되지 않고 Shift 된 것 처럼 보이네요.
OCIO v2를 사용하면 구성 빌드 방법을 개선할 수 있는 다른 방법이 있다. 그러나 이 수정을 사용하더라도 대부분의 경우 하나의 디스플레이가 필요하지만 병합된(디스플레이 + 보기)의 긴 목록을 갖는 것은 그다지 친숙하지 않죠. 여기서 가장 좋은 해결책은 2개의 드롭다운 메뉴를 갖는 것입니다. 하나는 디스플레이를 선택하고 다른 하나는 사용 가능한 해당 보기를 선택하는 것입니다. 다음 섹션에서 보게 될 것처럼 우리는 세번째 Look 에 대한 것을 이야기 해 볼거야.
Partial Look support
위의 설명에서 OCIO 디스플레이가 3가지 구성 요소로 되어 있다고 언급했죠! 이제 마지막 구성 요소인 Look 에 대해 언급하지 않을 수 없습니다. Look 은 창의적인 방식으로 데이터를 수정하는 것을 목표로 하는 모든 색상 공간에서 수행되는 색상 변환 입니다. 예를 들어 아티스트가 렌더링 한 페스들이 어떻게 보일 수 있는지 먼저 확인 할 수 있습니다. 일반적으로 Look 은 색상 공간과 유사하게 목록으로 정의 되지만 디스플레이 보기에서 Look 을 사용할 수도 있습니다.
리소스(이미지,...)의 색상공간은 레이어 슬롯이 아니라 Shelf 에서 수행할 수 있어야 합니다. 리소스는 사용 위치에 따라 원래 색상 공간이 변경되지 않습니다!
ㅎ환경 이미지 색상공간을 변경하는 직접적인 옵션이 없습니다. 위의 제안을 구현하면 이 문제도 해결할 수 있습니다. (see Environment )
Color-picker : 상단 색상공간을 수정하면 편집 가능한 값에 영향을 미칩니다. 여기서 상단 색상 공간은 값을 입력하는 데 사용되는 색상 공간을 나타내며 장면 뒤에서 작업 색상공간으로 변환 될 수 있습니다.
위와 같이 작업공간에서 어떤 값이 사용되고 있는지 확인하는 방법을 추가합니다.
Color-picker 가 깨져 OCIO config 버전 사용에 따라 다르게 반응합니다.(see picker section for details)
내보낼 때 텍스처에 대한 특정 색상공간을 설정하는 옵션이 없습니다.
다음 OCIO v2 색상공간 이름 토큰을 사용하면 오류가 기록됩니다.그러나 디스플레이는 여전히 문제 없이 작동합니다.
[ColorManagement] Error while creating OpenColorIO colorspace transform: Color space '<USE_DISPLAY_NAME>' could not be found
Conclusion 결론
정말 긴 글이었습니다. 끝까지 다 읽으셨다면 축하드려요. 이제 Substance Painter 에서 OCIO를 사용할 수 있는 방법에 대한 여러가지 아이디어를 얻으셨기를 바랍니다. 그렇지 않은 경우 주저하지 말고 저에게 연락하여 이 기사가 어떻게 수정되야 할 지 제안해 주세요. (디스코드에 참여 할 수도 있습니다. 이 페이지 하단의 보라색 버튼을 클릭하세요.)
이 게시물이 마음에 들고 저를 서포트 하고 싶다면 Gumroad 에서 제 스크립트 일부를 구입할 수 있습니다.
