설정(configs)에 DisplayViewTransforms가 포함되어 있지 않은 것 같습니다. 이것들을 추가하는 것을 고려해보셨나요?
모든 디스플레이/뷰 조합에 대해서가 아니더라도, 가장 일반적인 시나리오를 커버하는 몇 가지 정도는 어떨까요?:
VFX에서 오프라인 편집으로 프록시 미디어를 보내기 위한 ACES 1.0 SDR - Rec709 CG 데일리를 위한 ACES 1.0 SDR - sRGB
이러한 예시들은 설정 작성자들이 필요에 따라 더 많은 것들을 추가할 때 참고할 수 있는 예시가 될 수 있을 것 같습니다.

- !<ColorSpace>
name: Output - ACES 1.0 - SDR Video (Rec.1886 Rec.709)
family: Output
description: ACES 1.0 SDR-video for Rec.709 HD video with Rec.1886 gamma (2.4)
isdata: false
categories: [ file-io ]
encoding: sdr-video
from_reference: !<GroupTransform>
children:
- !<DisplayViewTransform> {src: ACES2065-1, display: "Rec.1886 Rec.709 - Display", view: "ACES 1.0 - SDR Video"}
- !<RangeTransform> {min_in_value: 0., min_out_value: 0., max_in_value: 1., max_out_value: 1.}
- !<ColorSpace>
name: Output - ACES 1.0 - SDR Video (sRGB)
family: Output
description: ACES 1.0 SDR-video for sRGB monitor (piecewise EOTF)
isdata: false
categories: [ file-io ]
encoding: sdr-video
from_reference: !<GroupTransform>
children:
- !<DisplayViewTransform> {src: ACES2065-1, display: "sRGB - Display", view: "ACES 1.0 - SDR Video"}
- !<RangeTransform> {min_in_value: 0., min_out_value: 0., max_in_value: 1., max_out_value: 1.}

위 처럼 컬러스페이스를 추가해서 사용하는 것에 대한 반대의견
OCIO v2에서는 "컬러 스페이스"가 무엇인지에 대해 더욱 엄격한 정의를 시도하고 있습니다. 이러한 이유로, 새로운 설정에서는 뷰 트랜스폼이나 룩(look)을 디스플레이 컬러 스페이스에 베이크(bake)하지 않습니다.
앞으로 예상되는 주요 트렌드는 다음과 같습니다:
- 사람들이 사용하고자 하는 다양한 뷰와 룩이 계속해서 증가할 것입니다. 이는 이미 ACES(새 버전 개발 중)뿐만 아니라 시네마 카메라 제조사들과 다른 업체들의 뷰 트랜스폼에서도 진행 중입니다. (ACES 설정은 물론 ACES에 초점을 맞추고 있지만, 다른 설정들도 다른 소스의 뷰 트랜스폼을 포함하길 원할 것입니다.)
- 툴 간의 워크플로우에서 미디어를 주고받을 때, 해당 미디어가 어떤 컬러 스페이스에 있는지 태그할 수 있는 기능에 대한 요구가 증가할 것입니다.
각각의 뷰 트랜스폼이나 룩이 자체 컬러 스페이스를 가지게 되면, 이는 지속 불가능한 상황이 됩니다. 다시 말해, sRGB 디스플레이를 위한 컬러 스페이스는 하나여야 하며, 각기 다른 뷰나 룩이 베이크된 수십 개의 컬러 스페이스가 있어서는 안 됩니다.
결과적으로, 우리는 소프트웨어 제공업체들에게 다음 두 가지 도구를 포함하도록 권장하고 있습니다:
- 실제 컬러 스페이스 간 변환을 위한 ColorSpaceTransform
- 디스플레이 컬러 스페이스로 변환하면서 뷰(그리고 가능하다면 룩)를 베이크하는 DisplayViewTransform
이는 컬러 관리 관점에서 더욱 엄격할 뿐만 아니라, 최종 사용자들에게 뷰 트랜스폼의 중요한 역할을 명확히 이해시키는 데 도움이 됩니다. 뷰 트랜스폼을 베이크하는 것은 단순히 컬러 스페이스 인코딩 간의 변환과는 근본적으로 다른 프로세스이며, 사용자들도 이를 그렇게 인식해야 합니다.
두 번째 도구를 추가하는 것은 그리 많은 추가 작업을 필요로 하지 않으며, 많은 애플리케이션들이 이미 이를 구현했거나 계획 중에 있습니다. 위에서 제시한 이유들로 인해, 저는 다양한 뷰를 베이크한 많은 "pseudo 컬러 스페이스" 출력을 추가하여 새로운 v2 설정을 v1 스타일로 되돌리는 것에 강하게 반대합니다. 따라서, 귀하의 두 번째 질문에 대해, 저는 이러한 것들을 몇 개만이라도 추가하기 시작하는 것은 바람직하지 않다고 생각합니다. 제안해 주셔서 감사하며, 이러한 설계 배경에 대한 설명이 도움이 되었기를 바랍니다.
마야의 경우
Maya에서의 사용 사례:
Maya에서 PNG 플레이블라스트를 할 때 Output sRGB 사용 이미지 플레인으로 플레이트를 로드했을 때 높은 다이나믹 레인지 유지 가능 이후 Nuke에서 이미지를 선형화하고 룩을 적용할 때 이미지 깨짐 현상 방지 utility - srgb texture 사용 시 이미지가 깨지는 경우가 있었음 Output sRGB 컬러스페이스의 "technical" 톤 매핑이 매우 유용했음
아티스트 관점에서의 우려사항:
ACES 도입 자체가 이미 도전적이었음 새 버전의 변경사항을 가르치고 적용하는 것이 쉽지 않을 것 같음 다음 메이저 버전은 덜 도전적이기를 희망
현재 상황:
새로운 설정과 기능, 변경사항에 대해 아직 학습이 필요함 전환 과정이 너무 어렵지 않기를 바람
새로운 설정에서도 말씀하신 작업을 계속 수행할 수 있다는 점을 참고해 주세요.
예를 들어 Maya에서는 다음과 같이 설정하시면 됩니다:
Color Management 환경설정에서 "Apply Output Transform to Playblast" 활성화 Transform Type을 "View Transform"으로 설정 Output Transform을 "ACES 1.0 SDR-video (sRGB)"로 설정
https://github.com/AcademySoftwareFoundation/OpenColorIO-Config-ACES/issues/82
DisplayViewTransforms for output? · Issue #82 · AcademySoftwareFoundation/OpenColorIO-Config-ACES
I'm noting that the configs do not appear to have any DisplayViewTransforms. Have you considered adding these? If not for all display/view combinations, then perhaps just a couple to cover the most...
github.com
'커뮤니티 스크랩' 카테고리의 다른 글
ACES (0) | 2025.02.06 |
---|---|
Do we need to change ACEScct (0) | 2025.02.04 |
프로그램별 ACES & OCIO setting정리 (0) | 2025.02.03 |
Cinematic Color - VES (0) | 2025.01.26 |
OCIO2와 ACES1.3으로의 전환 과정에서 발생하는 주요 변화와 문제점 (0) | 2025.01.18 |