AY-7025_OCIO path hardcoded into the metadata json

[ynbot]

Please describe the issue you have encountered?

"config": { "path": "C:/Users/FCervenka/AppData/Local/Ynput/AYON/addons/ayon_ocio_1.1.1/ayon_ocio/configs/OpenColorIOConfigs/aces_1.2/config.ocio", "template": "C:/Users/FCervenka/AppData/Local/Ynput/AYON/addons/ayon_ocio_1.1.1/ayon_ocio/configs/OpenColorIOConfigs/aces_1.2/config.ocio" },

That template key should've kept the templating string from ayon itself, which would be {BUILTIN_OCIO_ROOT} as part of that template

How to replicate the issue?

No response

Additional context:

link to discussion on Discord
(might be a private channel)

This issue was automatically created from Clickup ticket AY-7025

[jakubjezek001]

We were discussing this recently with @iLLiCiTiT and figured out that best approach here would be to set following data into representation's colorspaceData:

{
	"colorsapce": "ACES - ACEScg",
	"config" {
		"path": "{root[work]}/path/to/config.ocio
	}
}

[iLLiCiTiT]

"config": { "path": "C:/Users/FCervenka/AppData/Local/Ynput/AYON/addons/ayon_ocio_1.1.1/ayon_ocio/configs/OpenColorIOConfigs/aces_1.2/config.ocio", "template": "C:/Users/FCervenka/AppData/Local/Ynput/AYON/addons/ayon_ocio_1.1.1/ayon_ocio/configs/OpenColorIOConfigs/aces_1.2/config.ocio" },

This is something we were not able to reproduce. When we send job to deadline, the "template" is kept unfilled. We should find out what version of ayon-core they used, as it maybe was broken in past, but I don't remember any PR that would touch colorpaces for long time.

Overall:
I would keep it as it is now. We just have to make sure that the "path" is filled again based on "template" on the farm. If custom path, or built-in are used then use just the template as is, and if is used published representation, then use rootless path to the file. There is not much else we can do.

Issue is the same as #945 .

[iLLiCiTiT]

So, this is source of the issue

ayon-core/client/ayon_core/pipeline/farm/pyblish_functions.py

Line 491 in b239cdd

additional_color_data["colorspaceTemplate"] = remap_source(

.

Maya does use colorspace path from scene, and does not count on being able to set custom or built-in paths.

[BigRoy]

That logic is not maya specific though - also used by e.g. Houdini passing through that.
What we could do instead is this: Get the current hosts' ocio config from settings.

        settings_ocio_config_data = get_imageio_config_preset(
            self.data["project_name"],
            self.data["folder_path"],
            self.data["task_name"],
            self.host_name,
            anatomy=self.data["anatomy"],
            project_settings=self.data["project_settings"],
            template_data=template_data,
            env=self.launch_context.env,
            folder_id=folder_entity["id"],
        )

Similar to here.

And then do in that 'back-resolving':

    if os.path.realpath(ocio_path) == os.path.realpath(settings_ocio_config_data["path"]):
        template = settings_ocio_config_data["template"]
    else:
        self.log.warning(f"Reconstructing OCIO path template because it's not from settings: {ocio_path}")
        # do what it does now

We can't just supply the template directly because in many cases we're actually collectiong the OCIO data from the scenefile and are not relying on what the settings defined if the local scene file is actually for whatever reason using something else. (Because e.g. renderer attributes may override it and whatnot). Like you also said.

So basically: if the ocio path is the path from settings, then use that template.

[iLLiCiTiT]

I don't think we're able to reliable find correct template from only path, the path which is set in scene does not have to do anything with current state of settings, it could be set to path which can't be accessed with current settings, we would have to go through all possible templates in settings to guess which should be used (PR #970 trid to achieve).

But after some discussion with @antirotor we actually want to make sure it is set to correct colorpsace, in that regards I would rather collect color config from settings, validate if colorconfig from scene is set to same path, and if is not then don't allow to publish. With that approach we will just use template from settings and validate if the path from scene is matching...

Question is what to do if colorspace is not enabled in settings? In that case the key should not be used at all, probably.