누크 Read 노드 색공간이 자꾸 틀리게 잡힐 때: OCIO 2 File Rules로 자동 지정 정리

누크 Read 노드 색공간이 파일마다 엇갈리면, 먼저 현재 프로젝트의 OCIO config와 파일 경로 규칙을 확인합니다. 파일 이름에 색공간을 넣으면 Nuke가 자동으로 알아낼까요? OCIO 2 File Rules를 config에 추가하는 것만으로 Read가 항상 그 규칙을 따를까요?

File Rules는 픽셀을 분석하지 않습니다. 파일 경로와 이름을 규칙에 대조해 기본 색공간을 반환합니다. Foundry 문서는 Nuke의 파일 형식별 기본 색공간과 Python callback 확장을 설명하지만, 모든 Nuke 버전이 File Rules를 Read에 직접 자동 적용한다고 보장하지는 않습니다. 규칙 작성과 Nuke에 결과를 연결하는 일을 따로 확인해야 합니다.

이 글에서는 경로 규칙을 좁고 안전하게 설계하고, 미일치 파일에는 Nuke의 기존 기본값을 남기는 방법을 정리합니다. OCIO 전체 구조가 낯설다면 OpenColorIO가 config에서 색공간과 변환을 관리하는 방식부터 확인할 수 있습니다.

1. 같은 EXR인데 Read 색공간이 다른 이유부터 좁힙니다

EXR은 파일 형식이지, RGB 값이 어떤 색공간인지 알려 주는 이름은 아닙니다. 같은 확장자를 써도 한 파일은 카메라 Log이고 다른 파일은 렌더의 scene-linear일 수 있습니다. 파일 경로와 제작 규약을 확인하지 않고 모든 EXR을 한 색공간으로 지정하면 일부 파일은 맞아도 다른 소스는 틀어질 수 있습니다.

보이는 증상	먼저 확인할 항목	다음 판단
같은 확장자인데 일부 Read만 색이 틀어짐	현재 Read의 colorspace, 파일명 규약, 메타데이터	확장자만 쓰는 규칙 대신 구분 가능한 경로·이름 토큰을 찾습니다.
규칙을 넣었는데 색공간이 바뀌지 않음	현재 프로젝트의 Color Management와 선택한 OCIO config	File Rules가 config에 있는지, Nuke callback이 그 config를 읽는지 분리합니다.
예상과 다른 규칙이 먼저 선택됨	File Rules 목록의 위쪽 규칙과 대소문자	첫 매치만 적용되므로 더 구체적인 규칙을 앞에 둡니다.
규칙에 없는 파일도 색공간이 지정됨	마지막 Default 규칙	Default가 색공간을 반환합니다. 미매치는 별도 판별해야 합니다.

색공간 지정과 색 변환은 다릅니다. Read의 입력 색공간은 Nuke가 들어온 픽셀을 어떤 인코딩으로 해석할지 정합니다. OCIO 변환은 그 입력에서 프로젝트 작업 색공간으로 값을 옮깁니다. Viewer의 Display/View가 다르게 보이는 문제와 Read의 입력 색공간 자동 지정은 같은 설정이 아닙니다.

2. OCIO 2 File Rules는 위에서부터 첫 매치만 사용합니다

File Rules는 config의 file_rules 절에 둡니다. OCIO는 목록을 위에서 아래로 평가하고 처음 조건에 맞은 규칙의 색공간을 반환합니다. 넓은 확장자 규칙을 먼저 두면 파일 이름에 더 정확한 토큰이 있어도 앞 규칙이 먼저 잡을 수 있습니다.

아래는 같은 파이프라인의 LogC EXR과 ACEScg 렌더가 파일 이름으로 구분된다는 가정의 예입니다. 실제 색공간 이름은 프로젝트 config의 이름과 맞춰야 합니다.

file_rules:
  - !<Rule> {name: show_logc_exr, extension: "exr", pattern: "*_logc3_*", colorspace: "ARRI LogC3 (EI800)"}
  - !<Rule> {name: render_acescg_exr, extension: "exr", pattern: "*_acescg_*", colorspace: "ACEScg"}
  - !<Rule> {name: ColorSpaceNamePathSearch}
  - !<Rule> {name: Default, colorspace: "default"}

pattern은 대소문자를 구분합니다. 실제 파일명이 SHOT_logc3_plate.1001.exr라면 규칙 토큰과 맞지만, SHOT_LogC3_plate.1001.exr처럼 대문자가 섞이면 일치하지 않을 수 있습니다. glob 문자가 없는 extension의 exr는 기본적으로 .exr와 .EXR을 모두 허용합니다.

ColorSpaceNamePathSearch는 경로에서 config의 색공간 이름을 찾는 OCIO v1 방식의 규칙입니다. 필요하다면 구체적인 show 규칙 뒤, Default 바로 앞에 둡니다. 이 규칙은 목록에 최대 한 번만 넣을 수 있습니다.

규칙 설계	맞는 경우	주의할 점
확장자와 파일명 토큰 조합	팀이 색공간을 나타내는 이름 규약을 지킬 때	토큰이 실제 인코딩을 뜻하는지 제작 부서와 합의합니다.
ColorSpaceNamePathSearch	경로에 OCIO 색공간 이름을 넣는 기존 파이프라인	일반 단어가 우연히 색공간 이름과 같아지는 경로는 피합니다.
Default 규칙	앞선 규칙과 매치하지 않은 파일	항상 값을 반환하므로 미매치를 자동으로 경고하지 않습니다.

확장자만으로 모든 EXR을 ACEScg에 연결하지 마세요. EXR 안에는 서로 다른 파이프라인의 이미지가 함께 들어올 수 있습니다. 경로 규칙이 보장하지 못하는 입력을 억지로 분류하는 것보다, 파일명을 고치거나 Nuke의 기존 기본값을 유지하는 편이 안전합니다.

3. Nuke 색공간 자동 지정은 config 선택과 별도로 확인합니다

Nuke에서 OCIO 모드를 사용하면 현재 프로젝트가 선택한 config의 색공간을 Read와 Write에서 사용할 수 있습니다. Foundry 설명에 따르면 Read 기본 색공간은 파일 유형에 따라 달라질 수 있고 Python callback으로 매핑을 바꿀 수 있습니다. config에 규칙이 존재하는 것과 Nuke Read가 규칙을 호출하는 것은 다른 확인 항목입니다.

1. 프로젝트용 config를 준비합니다. Nuke 설치 폴더의 기본 config를 덮어쓰지 말고 사본을 둡니다. 여러 작업자가 쓴다면 공용 경로를 정합니다.
2. Project Settings > Color에서 그 config를 선택합니다. Color Management가 OCIO인지 확인하고 custom config 경로를 기록합니다.
3. callback이 같은 파일을 읽게 합니다. 아래 코드의 CONFIG_PATH를 Project Settings의 custom OCIO config와 동일한 파일로 바꿉니다.
4. 새 Read로 먼저 시험합니다. callback 등록만으로 기존 스크립트의 Read가 다시 매핑된다고 가정하지 말고, 새 노드와 기존 노드를 각각 비교합니다.

Nuke의 기본 색공간 매핑은 addDefaultColorspaceMapper로 바꿀 수 있습니다. callback은 Reader가 요청한 색공간과 데이터 유형 힌트를 받아 새 색공간 이름을 반환합니다. 아래 예시는 File Rules에 명시적으로 매치될 때만 바꾸고, Default만 매치하거나 Read 메뉴에 없는 결과면 기존 요청을 돌려줍니다.

import nuke
import PyOpenColorIO as ocio

# Nuke Project Settings > Color에서 선택한 것과 같은 파일로 바꿉니다.
CONFIG_PATH = r"/show/pipeline/color/config.ocio"
_RULE_CONFIG = None


def _get_file_rule_config():
    global _RULE_CONFIG
    if _RULE_CONFIG is None:
        _RULE_CONFIG = ocio.Config.CreateFromFile(CONFIG_PATH)
    return _RULE_CONFIG


def map_read_colorspace(requested_name, data_type_hint):
    try:
        node = nuke.thisNode()
        if node.Class() != "Read" or node.knob("file") is None:
            return requested_name
        path = node["file"].evaluate()
        if not path:
            return requested_name
        config = _get_file_rule_config()
        if config.filepathOnlyMatchesDefaultRule(path):
            return requested_name
        result = config.getColorSpaceFromFilepath(path)
        matched_name = result[0] if isinstance(result, tuple) else result
        choices = nuke.colorspaces.getColorspaceList(node.knob("colorspace"))[1:]
        if matched_name in choices:
            return matched_name
    except Exception as error:
        nuke.tprint("OCIO File Rules mapping skipped: %s" % error)
    return requested_name


nuke.addDefaultColorspaceMapper(map_read_colorspace)

이 코드는 Nuke 내 OCIO 버전과 Python binding에서 확인해야 합니다. 특히 getColorSpaceFromFilepath의 반환 형식과 Read 메뉴의 색공간 이름을 Nuke Python Console에서 확인합니다. 메서드가 없거나 config를 읽지 못하면 경고를 출력하고 원래 요청 색공간을 유지합니다.

callback을 등록한 뒤 규칙에 맞는 경로와 일부러 맞지 않는 경로를 각각 새 Read로 불러옵니다. LogC 파일은 LogC로, 렌더 파일은 ACEScg로 매핑되는지 확인합니다. 토큰을 제거한 경로에서 Nuke가 원래 선택하던 값이 유지되는지도 봅니다.

4. config 통과와 Read 화면 확인은 따로 합니다

먼저 config 문법과 색공간 참조 오류를 검사합니다. OCIO 도구가 설치된 환경에서 아래 명령을 실행합니다.

ociocheck --iconfig /show/pipeline/color/config.ocio

ociocheck는 YAML 구조나 정의되지 않은 색공간 참조 같은 오류를 찾습니다. 규칙이 의도한 파일을 잡는지, 그 색공간이 실제 소스에 맞는지, Nuke가 File Rules를 불러오는지는 별도로 Nuke에서 검증해야 합니다.

• 결과가 Default뿐이면 규칙 토큰, pattern의 대소문자, extension을 확인합니다.
• OCIO API는 기대한 색공간을 반환하지만 Read가 그대로면 callback 등록과 프로젝트 config 경로를 확인합니다.
• callback이 색공간을 반환했지만 메뉴에서 선택되지 않으면 config 이름·alias와 Read 메뉴 이름을 대조합니다.
• Read 색공간은 기대값인데 영상만 다르면 입력 인코딩, 작업 색공간, Viewer Display/View를 따로 확인합니다.

여기까지 보면 답이 정리됩니다. 누크 Read 노드 색공간을 경로 규칙으로 자동 지정하려면, OCIO File Rules를 작성하는 데서 멈추지 말고 Nuke 기본 색공간 callback이 같은 config의 규칙 결과를 읽도록 연결해야 합니다. 규칙에 매치되지 않는 파일은 Nuke의 기본값을 유지하고, 새 Read와 기존 스크립트에서 각각 확인합니다.

색공간 자동 지정은 규칙과 Nuke 연결이 함께 완성합니다.

공식 문서