Topics to be Covered
- Have clear and explicit settings to set up colormanaged review
- Document when Openpype automatically detects the source colorspace for renders to transcode
- Provide documentation on supported automatic detection contexts
- Improve global settings to allow setting both source and destination colorspace
- Simplify the process of selecting source and destination colorspace
- Implement a drop-down menu that lists all available colorspaces from ocio.config file.
If there are any additional topics that need to be covered, please let me know. Now lets cover all of them.
Have clear and explicit settings to set up colormanaged review
It encompasses various factors that cannot be accurately addressed through tagging alone. However, let’s assume that your project involves enabling colorspace management with a specific OCIO config set in paths. By default, your hosts will inherit the OCIO config set globally unless you explicitly override it with a different configuration for the host. This serves as the foundation. Upon opening the application, it will be set to the expected configuration, allowing you to choose from the available colorspace profiles listed in the OCIO config file.
To ensure consistent color representation in a particular application’s workflow, it is important to define the minimum colorspaces for working, display, and view purposes. These settings can be used to bake the appropriate colorspace into the reviewable files transcoded using the
ExtractOIIOTranscode plugin. Currently, Maya is the only host application that supports this feature. However, Nuke has its own baking technique that bypasses
ExtractOIIOTranscode entirely for generating reviewable files (
ExtractOIIOTranscode plugin is processing input representation only in case that the representation dictionary is having available
colorspaceData and if not then those representations are skipped. It means that each host application should maintain the representations the way
colorspaceData are detected and added to representations before the plugin.
Document when Openpype automatically detects the source colorspace for renders to transcode.
This is very good point. Since this feature is still quite experimental we haven’t been able to cover this topic in documentation.
Provide documentation on supported automatic detection contexts.
Also good point. At the moment I am working on PR which is solving some issues with file rules and once this will be settled I will create the documentation for it.
Improve global settings to allow setting both source and destination colorspace
colorspaceData representation key, which is expected to be defined upstream by a different process, should be used as the source. By defining source as input field in a preset it would by posing the risk of incorrect configuration and operations that could lead to the generation of false data. It is important to ensure accurate colorspace settings and operations to prevent such issues.
ExtractColorspaceData plugin in the stack is intended to handle this task, but its logic is flawed and will soon be removed. Moving forward, any plugins that require the detection of colorspace data should implement the
publish.ColormanagedPyblishPluginMixin parent class.
Simplify the process of selecting source and destination colorspace
I agree there should be done something about this. For example with use of enumerators which would clearly be telling user that we are passing values from
colorspaceData found in a representation or we are overriding them with our own colorpace settings inputs. But this would need to wait to Ayon since the settings are more interactive in web interface.
Implement a drop-down menu that lists all available colorspaces from ocio.config file
This sounds pretty good to me; quite tedious how invisible the colorspace detection is. On the ayon side I could imagine parsing the ocio config could become troublesome, e.g. the shared ocio location would have to be accessible to the server for one thing, and different configs for different apps/shots, 80000+ entries etc. That could ‘solved’ by a pre-filled list of values (in yet another setting somewhere) you want in the dropdown. Or just leave it as it is to reduce settings clutter.
@sjt that is right. We can address this issue by treating OCIO configs as separate product types and using a linking workflow to refer to them. By publishing OCIO configs, we can also extract the available colorspaces as JSON data, which can be easily accessed for the Settings enumerators. However, this is just an initial idea and further research is needed to explore this topic in more detail.
Just in case someone might find it usefull I am enclosing also link to the colorspace documentation.