Added creator for product base type "plate"

[splidje]

Changelog Description

I've decided to use just plain Nuke to turnover plates from Editorial using this studio specific addon:
https://github.com/splidje/ayon-ubp-nuke-turnover

For it I need a create instance for the product type "plate".

I've also reduced some duplicated code by combining: CreateWriteRenderModel CreateWritePrerenderModel and CreateWriteImageModel into one general base class CreateWriteModel

[Copilot]

Pull request overview

Adds support for a new Nuke “plate” product base type end-to-end (server settings, creator, and publish handling) to enable plate turnovers, while also reducing duplicated server settings schema by unifying the write-creator models.

Changes:

• Added plate as a supported Nuke render/publish type in server settings and extended ImageIO required-node presets for the new creator.
• Introduced CreateWritePlate creator plugin and updated identifier/base-type mappings used by tooling and color/template helpers.
• Refactored server create plugin settings models by consolidating multiple write models into a single CreateWriteModel.

Reviewed changes

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

Show a summary per file

File	Description
server/settings/publish_plugins.py	Adds plate to the publish-type enum used by settings/UI.
server/settings/imageio.py	Registers CreateWritePlate for node presets and adds required Write node knob defaults for plate.
server/settings/create_plugins.py	Consolidates write creator settings models and adds default settings for CreateWritePlate.
client/ayon_nuke/plugins/publish/validate_write_nodes.py	Extends base-type-to-creator mapping to include plate (but see comment about plugin families).
client/ayon_nuke/plugins/publish/validate_rendered_frames.py	Includes plate in rendered-frames validation families.
client/ayon_nuke/plugins/publish/validate_exposed_knobs.py	Includes plate in exposed-knob validation families and mapping.
client/ayon_nuke/plugins/publish/increment_write_node.py	Includes plate in post-version-up write-path update families.
client/ayon_nuke/plugins/publish/extract_render_local.py	Adds plate.local support to local render extractor and family normalization.
client/ayon_nuke/plugins/publish/collect_writes.py	Collects plate write instances and assigns target families (e.g. plate.local).
client/ayon_nuke/plugins/create/create_write_plate.py	New creator plugin implementing “Plate (write)” instance creation.
client/ayon_nuke/api/plugin.py	Maps plate product base type to create_write_plate identifier for conversions.
client/ayon_nuke/api/lib.py	Extends internal identifier→plugin-name mappings for plate in template/colorspace helpers.

---

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

[Copilot]

product_base_types_mapping now includes plate, but this plugin will never run for plate instances because families is still limited to ["render"]. If plate write nodes should be validated, add "plate" (and likely "prerender"/"image" too, since the mapping already supports them) to the families list, or otherwise ensure plate instances also carry the render family.

[Copilot]

These >>>>>>> debug statements look like leftover troubleshooting and will add noisy logs every time a plate instance is created. Consider removing them or replacing them with a clearer, actionable debug message (or lowering verbosity) consistent with the rest of the creators.

Suggested change

	self.log.debug(">>>>>>> : {}".format(self.instance_attributes))
	self.log.debug(">>>>>>> : {}".format(self.get_linked_knobs()))
	self.log.debug(
	"Creating write plate instance with attributes %s and linked knobs %s",
	self.instance_attributes,
	self.get_linked_knobs(),
	)

[jakubjezek001]

Works well

[BigRoy]

For it I need a create instance for the product type "plate".

Why did you need this product base type? Please elaborate? I really don't see why we need yet another Creator that just happens to define a product type which should really just be an alias to the product base type? Why does it absolutely require to be its own product base type? Please elaborate.

Code looks absolutely fine. I'm just confused WHY we'd want to duplicate it like this.

This looks very much like duplicates to:

• #203
• #195

Which both were not merged for that same reason.

[splidje]

For it I need a create instance for the product type "plate".

Why did you need this product base type? Please elaborate? I really don't see why we need yet another Creator that just happens to define a product type which should really just be an alias to the product base type? Why does it absolutely require to be its own product base type? Please elaborate.

Code looks absolutely fine. I'm just confused WHY we'd want to duplicate it like this.

This looks very much like duplicates to:

• Create plates #203
• Added creator for plates #195

Which both were not merged for that same reason.

I followed the advice to just use product base type "render" and configure product type "plate" on top.

Quite quickly I realised a lot of the features I'd been enjoying didn't seem available any more.

e.g. this way I can set different write node configurations for render vs. plate:

• plate is ACES2065-1 colour space, render is ACEScg
• plate doesn't include reformat; it's larger than the shot's format, render does include reformat; it's meant to be the shot format
• plate includes all metadata (trying to keep everything from original MXF from which I'm generating EXRs), render has default metadata

I also noticed that in the details of my plate it was saying it was product base type render and product type plate. However, if I use the tray publisher to publish something as a plate, it's truly product type plate.

As what I'm trying to achieve here is using Nuke to publish plates, it felt like treating plate as an official product base type made sense - but I'm likely missing some of the point here, because admittedly I'm still very new to AYON and learning all the principles and structure.

The origin of all of this is my reasoning:
I need to convert sections of MXF files of raw footage from Sony Venice cameras to EXR sequences in ACES2065-1 starting at 1001 for people to use -> Nothing I currently have appears to read the codec except Nuke -> I'll use Nuke to create these EXR plates

[BigRoy]

Thanks @splidje - that's exactly the reasoning I was looking for. I imagine this PR may linger for a bit, sorry about that. We've been having some discussions about the usage of product base types and what not and I assume we'll raise this on the next internal discussion about the usages, etc. But this is exactly the part of the reasoning that has come up, that as soon as you do allow separate product types on a base type that you will get into the cases where you will want to define how they behave differently, etc. - like here.