Colormanagement improvements

[jakubjezek001]

Is there an existing issue for this?

• I have searched the existing issues.

Please describe the feature you have in mind and explain what the current shortcomings are?

The current state of AYON color management is confusing, mostly regarding Display and View settings at the DCC level, as well as transcoding and metadata storage.

How would you imagine the implementation of the feature?

• Enhance OCIO Config Profiles to include:
  • DCC Display & View (for unified settings across DCCs).
  • Video colorspace (default target for OIIO web review transcoding).
• Implement DCC-level acceptance for new OCIO Config Profiles with Display & View.
  • Remove equivalent settings from host-level configurations.
• ExtractOIIOTranscode: Define target output Colorspace or Display & View inheritance/override.
  • Inherit from core preset OR override with explicit values and only use override if toggled ON (like ayon+settings://nuke/imageio/baking_target).
  
• Fix CG Rendering Bug: AOV EXRs must use scene_linear or data roles.
  • Stop adding display/view keys to colorspaceData. (Reference: GH Issue 1500).
• Remove Nuke Monitor preset; allow users to define it.
• Map use cases for ExtractOIIOTranscode using Display & View as source keys in colorspaceData (Current known use: Batch Delivery / Simple Template processing).
• Standardize colorspaceData in representation entities:
  • Only include the colorspace key to reflect the source colorspace (e.g., acescg, p3), not roles.

Are there any labels you wish to add?

• I have added the relevant labels to the enhancement request.

Describe alternatives you've considered:

No response

Additional context:

No response

[MustafaJafar]

For information, I'm adding a summary for this and #1500 from an internal discussion:

Expected Data Keys During Publishing

These keys represents suggested state:

# These keys are expected by `create_instances_for_aov` and `ExtractOIIOTranscode`
instance.data["colorspaceConfig"]  # Current (Source) colorspace.
# this should be removed in future since it should be driven from settings on OCIO Config profiles
instance.data["display"]  # Current (Source) Display used in the viewport.
instance.data["view"]  # Current (Source) View used in the viewport.

# `colorspaceData` key is expected on representations
representation["colorspaceData"]["config"]["path"]  # Absolute path of current OCIO config
representation["colorspaceData"]["config"]["template"]  # Current OCIO config with root anatomy key.
# it is expected that if display&view keys are in colorspace data then `colorspace` key is empty
representation["colorspaceData"]["colorspace"]  # Current colorspace baked into pixels.
representation["colorspaceData"]["display"]  # Current Display baked into pixels.
representation["colorspaceData"]["view"]  # Current View baked into pixels.

# Some Relations
# `ayon_core.pipeline.farm.pyblish_functions.create_instances_for_aov` boils down to
colorspace_template = remap_source(instance.data["colorspaceConfig"], anatomy)

representation["colorspaceData"].update({
    "colorspace": RenderProduct.colorspace,
    "config": {
        "path": instance.data["colorspaceConfig"],
        "template": colorspace_template
    }
})

Cleanup the Extract OIIO Transcode Plugin logic

Imo, the bottom line is that the plugin should follow the transcoding type. which is either Use Colorspace or Use Display&View.

However, the plugin initializes some variables at the beginning of the process which pollutes the function arguments.

we set target_display, target_view, source_display, source_view and source_colorspace.

ayon-core/client/ayon_core/plugins/publish/extract_color_transcode.py

Lines 95 to 96 in 5ac4dd0

	target_display = instance.data.get("colorspaceDisplay")
	target_view = instance.data.get("colorspaceView")

ayon-core/client/ayon_core/plugins/publish/extract_color_transcode.py

Lines 105 to 108 in 5ac4dd0

	colorspace_data = repre["colorspaceData"]
	source_colorspace = colorspace_data["colorspace"]
	source_display = colorspace_data.get("display")
	source_view = colorspace_data.get("view")

and later on in the code we override them

ayon-core/client/ayon_core/plugins/publish/extract_color_transcode.py

Lines 141 to 156 in 5ac4dd0

	if transcoding_type == "colorspace":
	# TODO: Should we fallback to the colorspace
	# (which used as source above) ?
	# or should we compute the target colorspace from
	# current view and display ?
	target_colorspace = (output_def["colorspace"] or
	colorspace_data.get("colorspace"))
	elif transcoding_type == "display_view":
	display_view = output_def["display_view"]
	target_view = (
	display_view["view"]
	or colorspace_data.get("view"))
	target_display = (
	display_view["display"]
	or colorspace_data.get("display")
	)

then we pass on all of them

ayon-core/client/ayon_core/plugins/publish/extract_color_transcode.py

Lines 182 to 194 in 5ac4dd0

	oiio_color_convert(
	input_path=input_path,
	output_path=output_path,
	config_path=config_path,
	source_colorspace=source_colorspace,
	target_colorspace=target_colorspace,
	target_display=target_display,
	target_view=target_view,
	source_display=source_display,
	source_view=source_view,
	additional_command_args=additional_command_args,
	logger=self.log
	)