mirror of
https://github.com/ynput/ayon-core.git
synced 2025-12-24 21:04:40 +01:00
updating documentation
This commit is contained in:
Jakub Jezek
parent
84806f1745
commit
e1ac21a112
4 changed files with 125 additions and 34 deletions
|
|
@ -1,29 +0,0 @@
|
|||
# Colorspace
|
||||
1. Each host handling pixle data is requiring setting schema.
|
||||
```json
|
||||
{
|
||||
"key": "imageio",
|
||||
"type": "dict",
|
||||
"label": "Color Management (ImageIO)",
|
||||
"is_group": true,
|
||||
"children": [
|
||||
{
|
||||
"type": "schema",
|
||||
"name": "schema_imageio_config"
|
||||
},
|
||||
{
|
||||
"type": "schema",
|
||||
"name": "schema_imageio_file_rules"
|
||||
}
|
||||
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
1. Use any mechanism to set OCIO config to host app resolved from `openpype\pipeline\colorspace.py:get_imageio_config`
|
||||
- either set OCIO environment during host launching via pre-launch hook
|
||||
- or to set workfile ocio config path if host api is available
|
||||
|
||||
2. Each pixle related exporter plugins has to use parent class `openpype\pipeline\publish\publish_plugins.py:ExtractorColormanaged` and use it similarly as it is already implemented here `openpype\hosts\nuke\plugins\publish\extract_render_local.py`
|
||||
- **get_colorspace_settings**: is solving all settings for the host context
|
||||
- **set_representation_colorspace**: is adding colorspaceData to representation. If the colorspace is known then it is added directly to the representation with resolved config path.
|
||||
113
website/docs/dev_colorspace.md
Normal file
113
website/docs/dev_colorspace.md
Normal file
|
|
@ -0,0 +1,113 @@
|
|||
---
|
||||
id: dev_colorspace
|
||||
title: Colorspace Management and Distribution
|
||||
sidebar_label: Colorspace
|
||||
---
|
||||
|
||||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
## Introduction
|
||||
Defines the distribution of colors and OCIO config during publishing. Once colorspace data are captured and integrated into representation loaders could use them for loading image and video data with correct colorspace.
|
||||
|
||||
:::warning Color Management (ImageIO)
|
||||
Settings schema is requred for any host or module which is processing pixel data.
|
||||
:::
|
||||
|
||||
## Data model
|
||||
The *colorspaceData* are stored at root of representation dictionary during publishing. Once they are integrated into representation db document they are stored as *representation_doc.data["colorspaceData"]*
|
||||
|
||||
### Keys
|
||||
- **colorspace** - string value used in other publish plugins and loaders
|
||||
- **configData** - storing two versions of path.
|
||||
- **path** - is formated and with baked platform root. It is used for posible need to find out where we were sourcing color config during publishing.
|
||||
- **template** - unformated tempate resolved from settings. It is used for other plugins targeted to remote publish which could be processed at different platform.
|
||||
|
||||
### Example
|
||||
{
|
||||
"colorspace": "linear",
|
||||
"configData": {
|
||||
"path": "/abs/path/to/config.ocio",
|
||||
"template": "{project[root]}/path/to/config.ocio"
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
## How to integrate it into a host
|
||||
1. Each host setting schema should have following shemas. Ideally at top of all categories so it mimic already defined order at other hosts.
|
||||
```json
|
||||
{
|
||||
"key": "imageio",
|
||||
"type": "dict",
|
||||
"label": "Color Management (ImageIO)",
|
||||
"is_group": true,
|
||||
"children": [
|
||||
{
|
||||
"type": "schema",
|
||||
"name": "schema_imageio_config"
|
||||
},
|
||||
{
|
||||
"type": "schema",
|
||||
"name": "schema_imageio_file_rules"
|
||||
}
|
||||
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
2. Use any mechanism to set OCIO config to host app resolved from `openpype\pipeline\colorspace.py:get_imageio_config`
|
||||
- either set OCIO environment during host launching via pre-launch hook
|
||||
- or to set workfile ocio config path if host api is available
|
||||
|
||||
3. Each pixle related exporter plugins has to use parent class `openpype\pipeline\publish\publish_plugins.py:ExtractorColormanaged` and use it similarly as it is already implemented here `openpype\hosts\nuke\plugins\publish\extract_render_local.py`
|
||||
- **get_colorspace_settings**: is solving all settings for the host context
|
||||
- **set_representation_colorspace**: is adding colorspaceData to representation. If the colorspace is known then it is added directly to the representation with resolved config path.
|
||||
|
||||
4. Implement the loading procedure. Each loader which needs to have colorspace (detected from representation doc) set to DCC reader nodes should implement following code.
|
||||
```python
|
||||
from openpype.pipeline.colorspace import (
|
||||
get_imageio_colorspace_from_filepath,
|
||||
get_imageio_config,
|
||||
get_imageio_file_rules
|
||||
)
|
||||
|
||||
class YourLoader(api.Loader):
|
||||
def load(self, context, name=None, namespace=None, options=None):
|
||||
path = self.fname
|
||||
colorspace_data = context["representation"]["data"].get("colorspaceData", {})
|
||||
colorspace = (
|
||||
colorspace_data.get("colorspace")
|
||||
# try to match colorspace from file rules
|
||||
or self.get_colorspace_from_file_rules(path, context)
|
||||
)
|
||||
|
||||
# pseudocode
|
||||
load_file(path, colorspace=colorspace)
|
||||
|
||||
def get_colorspace_from_file_rules(self, path, context)
|
||||
project_name = context.data["projectName"]
|
||||
host_name = context.data["hostName"]
|
||||
anatomy_data = context.data["anatomyData"]
|
||||
project_settings_ = context.data["project_settings"]
|
||||
|
||||
config_data = get_imageio_config(
|
||||
project_name, host_name,
|
||||
project_settings=project_settings_,
|
||||
anatomy_data=anatomy_data
|
||||
)
|
||||
file_rules = get_imageio_file_rules(
|
||||
project_name, host_name,
|
||||
project_settings=project_settings_
|
||||
)
|
||||
# get matching colorspace from rules
|
||||
colorspace = get_imageio_colorspace_from_filepath(
|
||||
path, host_name, project_name,
|
||||
config_data=config_data,
|
||||
file_rules=file_rules,
|
||||
project_settings=project_settings
|
||||
)
|
||||
```
|
||||
|
||||
:::warning Loading
|
||||
Current loader's host will be using a different OCIO.config file than the original context **colorspaceData** have been published with. There is no way at the moment a DCC can use multiple ocio configs at one workfile.
|
||||
:::
|
||||
|
|
@ -20,19 +20,25 @@ OpenPype distributes its own OCIO configs. Those can be found in `{openpype inst
|
|||
:::
|
||||
|
||||
### Using OCIO config
|
||||
Each OCIO config path input supports formatting using environment variables and [anatomy template keys](../admin_settings_project_anatomy#available-template-keys). The default global OCIO config path is `{OPENPYPE_ROOT}/vendor/bin/ocioconfig/OpenColorIOConfigs/aces_1.2/config.ocio`.
|
||||
Global config path is set by default to OpenPype distributed configs. At the moment there are only two - **aces_1.2** and **nuke-default**. Since this path input is not platform specific it is required to use at least an environment variable do platform specific config root directory. Order of paths matter so first path found and existing first served.
|
||||
|
||||
If the project settings for a particular host has its own OCIO config **enabled** and set to any path it overrides the global OCIO config for that host.
|
||||
Each OCIO config path input supports formatting using environment variables and [anatomy template keys](../admin_settings_project_anatomy#available-template-keys). The default global OCIO config path is `{OPENPYPE_ROOT}/vendor/bin/ocioconfig/OpenColorIOConfigs/aces_1.2/config.ocio`.
|
||||
|
||||
If the project settings for a particular host has its own OCIO config **enabled** and set to at least one path and the path exists, it overrides the global OCIO config for that host.
|
||||
|
||||
**For example**
|
||||
|
||||
Project global OCIO config: `project_settings/global/imageio/ocio_config`
|
||||
Project nuke-specific OCIO config: `project_settings/nuke/imageio/ocio_config`
|
||||
|
||||
Config path can be defined to particular shot target with following path input `{root[work]}/{project[name]}/{hierarchy}/{asset}/config/aces.ocio`
|
||||
Config path can be defined to particular shot target with following path inputs:
|
||||
1. `{root[work]}/{project[name]}/{hierarchy}/{asset}/config/aces.ocio`
|
||||
2. `{root[work]}/{project[name]}/{hierarchy}/config/aces.ocio`
|
||||
|
||||
Procedure of resolving path (from above example) will look first into path 1st and if the path is not existing then it will try 2nd and if even that is not existing then it will fall back to global default.
|
||||
|
||||
### Using File rules
|
||||
File rules are inspired by [OCIO v2 configuration]((https://opencolorio.readthedocs.io/en/latest/guides/authoring/rules.html)). Each rule has a unique name which can be overridden by host-specific _File rules_ (example: `project_settings/nuke/imageio/file_rules/rules`).
|
||||
File rules are inspired by [OCIO v2 configuration]((https://opencolorio.readthedocs.io/en/latest/guides/authoring/rules.html)). Each rule has a unique name which can be overridden by host-specific _File rules_ (example: `project_settings/nuke/imageio/file_rules/rules`).
|
||||
|
||||
The _input pattern_ matching uses REGEX expression syntax (try [regexr.com](https://regexr.com/)). Matching rules procedure's intention is to be used during publishing or loading of representation. Since the publishing procedure is run before integrator formate publish template path, make sure the pattern is working or any work render path.
|
||||
|
||||
|
|
|
|||
|
|
@ -158,6 +158,7 @@ module.exports = {
|
|||
"dev_publishing"
|
||||
]
|
||||
},
|
||||
"dev_deadline"
|
||||
"dev_deadline",
|
||||
"dev_colorspace"
|
||||
]
|
||||
};
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue