Skip to content

Project Configuration

Creating a new project bundle

  1. Create a directory under configs/: configs/<project-name>/
  2. Copy configs/defaults/kpipe.toml as a starting point
  3. Adjust the [anatomy] section for your file naming convention
  4. Add kpipe-kitsu.toml with the Kitsu server URL
  5. Add kpipe-publish.toml with the publishing pipelines for your product types

Anatomy (file naming)

The [anatomy] section defines path templates for workfiles and published products. Optional path segments are wrapped in </{segment}>.

[anatomy]
workfile = "{project_key}-{sequence}_{shot}-{task}-v{version}.{ext}"
product  = "{project_key}-{sequence}_{shot}-{product_type}-v{version}.{ext}"

DCC paths

Specify the executable path for each DCC:

[dcc.blender]
path = "C:/Program Files/Blender Foundation/Blender 5.0/blender.exe"

[dcc.nuke]
path = "C:/Program Files/Nuke15.0/Nuke15.0.exe"

Kitsu backend

# kpipe-kitsu.toml
[login]
source_url = "https://kitsu.example.com"
project_id = "..."

Login credentials are not stored in config. Each artist runs:

uv run kpipe-manage login

which prompts for a Kitsu email and password and stores them locally (via kpipe.local_storage, rooted under the platformdirs user config directory) — not committed to the config bundle. Use uv run kpipe-manage logout to remove them again.

Optionally, [login] user_email / user_password in kpipe-kitsu.toml can hold fallback credentials (e.g. for a shared render farm service account) used only when no local login is stored.

Formats, media presets and product types

Only the resolutions are project specific. Formats are defined under generic keys, so pipeline configs can use them without naming the project; name is what artists see in the DCCs and publish settings:

[formats.delivery]
name = "Doris 2K"
resolution = [2048, 1024]

[formats.working]
name = "Doris 2K Overscan"
base = "delivery"
overscan = [102, 51]   # pixels per side → 2252x1126

[formats.review]
name = "Doris 1K"
resolution = [1920, 960]

[dcc.nuke]
format = "working"     # root format of new Nuke scripts

OCIO config

[config]
ocio_config = "{pipeline_root}/configs/ocio/config.ocio"                 # set as $OCIO for the DCCs
ocio_config_compat = "{pipeline_root}/configs/ocio/config-v2.4.ocio"     # copy for tools on OCIO 2.4

[dcc.nuke]
ocio_compat = true     # this DCC gets ocio_config_compat

config.ocio is an OCIO 2.5 config (Blender 5). The venv's oiiotool and PyOpenColorIO, and Nuke, are built on OCIO 2.4 and can't read it, so config-v2.4.ocio is the same file with ocio_profile_version: 2.4 — regenerate it whenever config.ocio changes. kpipe.get_ocio_path(compat=True) returns the copy (tools such as ExtractOiioColorConvert, and role resolution in kpipe.media when $OCIO isn't set); launchers call get_ocio_path(dcc="<dcc>"). The config maps compositing_log / color_timing to ACEScct, so pipelines can target ACEScct as role:compositing_log.

Media presets (exr_dwaa, png_8, h264_review, h265_proxy, …) are built in and project independent; add [media.presets.<name>] only for project-specific needs. Product types are set by the pipelines and integrate actions themselves, e.g. product_type = "{task}_review".

See Media Settings & Presets for formats, all preset fields, the built-in presets, color roles and DCC support.

Loading and Publishing pipeline

See Action Pipeline for how kpipe-publish.toml and kpipe-load.toml is structured.