Simplify color transcode workflow for review

Olivier · 24 July 2023 16:48

For now the settings available to setup colormanaged review are all over the place and not very explicit in what they do.

There is the files rules that enable us to set the source colorspace of the conversion we want to do when it is not automatically detected by Openpype.

We don’t know when Openpype detect the source colorspace of the “renders” to transcode. Inside Maya it works of the render for exemple but not for the review type
There is in general no documentation of what context is supported to be automaticly detected

Then there is a global settings that we can set per host / per task. But we cannot in this place set the source colorspace, only the destination colorspace.

Then there is another settings specific to the host where we can set also only the destination colorspace

In all these settings, the notion of settings the source or the destination colorspace is never explicit

Having 1 global settings

Wouldn’t it be better to only have the global Extract OIIO Transcode and be able there to :

set the source colorspace either to automatic (detected by openpype) / ocio working space (scene linear)/ custom

set de destination colorspace (like we can already) and that it.
We will have only 1 place where we can set the kind of review we want

For now choosing the source colorspace or the destination colorspace is very tedious, we have to find the .ocio config file, find the right colorspace we want copy paste. Very error prone.

Drop down menu to choose colorspace

Having a drop down that parse the ocio.config and list all the available colorspace would be perfect.

sjt · 25 July 2023 12:00

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.

jakub.jezek · 28 July 2023 16:36

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 (ExtractReviewDataMov).

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

The 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.

Currently, the 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.