fix: Fix SYNDisplay property regression

[williamwira]

Linked issues

Fixes #1034

Summarize your change.

Updated initialization step in OCIOIPNode used by SYNDisplay, so outTransform.url would be checked.

Describe the reason for the change.

Regression caused SYNDisplay outTransform.url property to be ignored, so we could not set the display colorspace with an icc filepath.

Describe what you have tested and on which operating system.

Confirmed this update worked on Linux RHEL 9.6. Executed this python code on a single-monitor system to validate the change. The code switches the display group's color pipeline node to a SYNDisplay node, and then assigns an icc profile file to the node's outTransform.url property.

icc_file = '<path-to>/colorspace.icc'
commands.setStringProperty("displayGroup0_colorPipeline.pipeline.nodes", ["SYNDisplay"])
syn_display_node = commands.nodesOfType("SYNDisplay")[0]
commands.setStringProperty(f"{syn_display_node}.outTransform.url", [icc_file])

[Copilot]

Pull request overview

This PR aims to fix a regression where the SYNDisplay node ignored the outTransform.url property, preventing ICC filepaths from affecting the display pipeline (Fixes #1034).

Changes:

• Adjusts OCIOIPNode::updateConfig() to accept an initializing flag and changes constructor initialization flow.
• Updates OCIOIPNode::updateFunction() to not early-return on empty ocio.inColorSpace when using a raw config (needed for synlinearize/syndisplay).

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
src/lib/ip/OCIONodes/OCIONodes/OCIOIPNode.h	Extends updateConfig() signature to include an initialization flag.
src/lib/ip/OCIONodes/OCIOIPNode.cpp	Changes constructor/config initialization behavior and relaxes inColorSpace gating for raw-config SYN functions.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Calling updateConfig(true) in the constructor suppresses updateFunction() (see the initializing guard below). There are no other updateConfig() call sites in the codebase, so OCIOIPNode instances created at runtime (e.g., via PipelineGroupIPNode::buildPipeline()) will never build m_state->function until a property change occurs, causing evaluate() to bypass the OCIO transform entirely. Consider calling updateConfig() without the initializing flag here, or ensure updateFunction() is invoked after construction (e.g., unconditionally in updateConfig(), or from the graph/pipeline builder once properties are initialized).

Suggested change

	updateConfig(true);
	updateConfig(false);

[Copilot]

The initializing guard prevents updateFunction() from running during updateConfig(). Since evaluate() requires m_state->function to be non-null to apply the transform, skipping updateFunction() here can leave the node in a permanently inactive state unless another code path triggers updateFunction() (propertyChanged/readCompleted). If the goal is only to avoid syndisplay/synlinearize validation during initialization, consider narrowing the suppression to those specific functions or validating that updateFunction() is called once after the node is fully constructed/inserted into the graph.

Suggested change

	if (!initializing)
	{
	updateFunction();
	}
	updateFunction();