One big gap in OCIO that is not easily solvable without external tooling and secondary processes (prone to error) is a way for config authors to specify embeddable metadata that describes a colorspace, most importantly display colorspaces, for output media destined for non-OCIO apps and workflows.
For example, when exporting a still image from a Nuke write node I can chose to use a display/view transform. The config author should be able to provide an ICC profile that describes that display characteristics, and if OCIO provided an API, Nuke could ask OCIO for the ICC profile associated with the user selected display colorspace.
While the list of possible metadata types might be long and difficult to implement in all cases, ICC, and perhaps CICP seems like a good place to start and should be relatively easy to implement. I propose something along the lines of this:
- !<ColorSpace>
name: Rec.2100-PQ - Display
aliases: [rec2100_pq_display]
family: Display
equalitygroup: ""
bitdepth: 32f
description: Convert CIE XYZ (D65 white) to Rec.2100-PQ
isdata: false
categories: [file-io]
encoding: hdr-video
allocation: uniform
embeddableColorMetadata:
icc: Rec.2100-PQ.icc
cicp:
transferFunction: 16
colorPrimaries: 9
matrixCoefficients: 14
from_display_reference: !<BuiltinTransform> {style: DISPLAY - CIE-XYZ-D65_to_REC.2100-PQ}The config author would then put the icc profiles in the search path, just like any LUT reference, and OCIO would provide APIs to extract the desired metadata type from a colorspace depending on the file type it's trying to write out.
struct CICPMetadata {
uint8 transferFunction;
uint8 colorPrimaries;
uint8 matrixCoefficients;
}
// fully resolved path to ICC for app to read/embed for ICC compatible file types.
const char* Colorspace::getColorMetadataICC();
// the standardized CICP tag data for CICP compatible file types.
CICPMetadata Colorspace::getColorMetadataCICP();With an API like this - applications can rely on config authors to provide the correct metadata for file types destined for non-OCIO applications and workflows. Without something like this, an application is forced to either:
- Not embed any metadata at all
- Provide an arbitrary list of possible metadata for the user to associate with their chosen colorspace
- Jump through hoops trying to guess the appropriate metadata
My initial thoughts are to just create data representations of various metadata types OCIO would want to support, and leave it up to the app to properly embed it in the file it's writing.
One big gap in OCIO that is not easily solvable without external tooling and secondary processes (prone to error) is a way for config authors to specify embeddable metadata that describes a colorspace, most importantly display colorspaces, for output media destined for non-OCIO apps and workflows.
For example, when exporting a still image from a Nuke write node I can chose to use a display/view transform. The config author should be able to provide an ICC profile that describes that display characteristics, and if OCIO provided an API, Nuke could ask OCIO for the ICC profile associated with the user selected display colorspace.
While the list of possible metadata types might be long and difficult to implement in all cases, ICC, and perhaps CICP seems like a good place to start and should be relatively easy to implement. I propose something along the lines of this:
The config author would then put the icc profiles in the search path, just like any LUT reference, and OCIO would provide APIs to extract the desired metadata type from a colorspace depending on the file type it's trying to write out.
With an API like this - applications can rely on config authors to provide the correct metadata for file types destined for non-OCIO applications and workflows. Without something like this, an application is forced to either:
My initial thoughts are to just create data representations of various metadata types OCIO would want to support, and leave it up to the app to properly embed it in the file it's writing.