Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WIP: Colorspace example #162

Closed
wants to merge 34 commits into from
Closed

WIP: Colorspace example #162

wants to merge 34 commits into from

Conversation

garyo
Copy link
Contributor

@garyo garyo commented May 9, 2024

No description provided.

A set of OpenColorIO-related ImageEffect clip properties which allow hosts to pass information about their OCIO configuration into a plug-in.

This allows plug-ins which display images in their own UI to match the colours used in the host, and is also useful in effects which are sensitive to the working colourspace of the input clip.

Signed-off-by: John-Paul Smith <jps@borisfx.com>
Signed-off-by: John-Paul Smith <jps@borisfx.com>
OCIO properties now offer two-way communication, allowing both plug-in and host to specify a preferred colourspace, and setting the colourspace on output clips.

Properties related to display are now set at an image effect rather than clip level, as they don’t change per clip and this makes them usable by generators.

Overall use of the OCIO properties is now controlled by kOfxImageEffectPropSupportsOCIO to avoid additional work by plug-ins or hosts when OCIO is not available.

Signed-off-by: John-Paul Smith <jps@borisfx.com>
kOfxImageClipPropOCIOPreferredColourspace is now specified by plug-ins during kOfxImageEffectActionGetClipPreferences, and by hosts on an output clip instance.

Also clarified that plug-ins should not expect the display-related properties to be set during a render event.

Signed-off-by: John-Paul Smith <jps@borisfx.com>
The OCIO API has been extended to be a broader colour management API, although still using OCIO as the foundation.

This commit adds the ACESCG and ACES colour management styles, which only use OCIO as a source of colourspace names and could be implemented using other colour management pipelines.

OCIO-specific properties are separated and form a superset of the functionality offered by the ACES styles.

Signed-off-by: John-Paul Smith <jps@borisfx.com>
Signed-off-by: John-Paul Smith <jps@borisfx.com>
The Python script scripts/genColour uses OCIO to process the config and write out a C header file containing preprocessor definitions for various names and attributes related to the colourspaces and roles in the config.

ofxColourspaceList.h is the result of running this script on the ACES Studio config, which is the proposed common language the OFX colour support as it can be implemented without actually using OCIO.

Signed-off-by: John-Paul Smith <jps@borisfx.com>
Signed-off-by: John-Paul Smith <jps@borisfx.com>
Also removed the ACESCG style and renamed ACES to Native.

Signed-off-by: John-Paul Smith <jps@borisfx.com>
Signed-off-by: John-Paul Smith <jps@borisfx.com>
The colourspace list has been updated to studio-config-v2.1.0_aces-v1.3_ocio-v2.3.

The Studio and CG configs are compared to add a new attribute “IsCore”. This is true if the colourspae is present in the CG config, and defines a smaller set of colourspaces.

Also, for most colourspaces, the first alias is a better short name than the actual colourspace name. The name is now used as the “DisplayName” attribute and the first alias is used as the base name instead.

genColour is now hard-coded to specific OCIO configs so it’s easier to do the Studio vs CG comparisons.

Signed-off-by: John-Paul Smith <jps@borisfx.com>
This is an error in the studio config, workaround it until it’s fixed upstream by manually setting the encoding. See AcademySoftwareFoundation/OpenColorIO-Config-ACES#123.

Signed-off-by: John-Paul Smith <jps@borisfx.com>
The core colourspace list now contains more items, better matching the CG config.

Signed-off-by: John-Paul Smith <jps@borisfx.com>
1. The OCIO Look property has been removed as this information is part of a View.
2. The Native mode header has been simplified, removing unnecessary aliases and the role mappings. DisplayName has been changed to Label.
3. The definition of core colourspaces has been changed to no longer depend on the OCIO cg config. genColour has a list of core colourspaces, now including HDR colourspaces as requested by @SonyDennisAdams.
4. New roles have been added for sdr_video and hdr_video. These are arbitrarily mapped but the intention is that plug-ins use them to request any sdr/hdr video colourspace.
5. The colourspace header now includes docs for roles, explaining their meaning.
6. The new genOCIOConfig script produces an OpenFX OCIO config, which includes the above changes. Hosts should ship this config so that even with running in Native mode, they can supply it to a plug-in that uses OCIO, via kOfxImageEffectPropOCIOConfig. This config is now used to produce the colourspace header.
7. A config generated by the above script is included as well - I put it in include for now but it could go elsewhere.

Signed-off-by: John-Paul Smith <jps@borisfx.com>
In ofxColourspaceList.h, colourspaces are now grouped into core and non-core, rather than display and scene.

The previous genColour hacked around the fact that display colourspaces were marked inactive in the ACES config. Apparently these colourspaces will become active upstream in future, so preempt that by making them active in our config. This simplifies the code in genColour.

Also corrected the filename name of our OCIO config and the invocation examples for genOCIOConfig and genColour.

Signed-off-by: John-Paul Smith <jps@borisfx.com>
@revisionfx
Copy link
Contributor

@john-paulsmith
No one has answered me about having a role_only mode (e.g. "scene_linear", "sdr" ) so reasking here.
@garyo says it was facultative, so can we just have a special mode for that only (no OCIO strings to set).
All I want in generic case is to query in render call is which of: linear, sdr, hdr, log, data - nothing else and I assume if I don't set in clip preferences log, then I won't get that.

john-paulsmith and others added 13 commits June 4, 2024 13:40
OfxImageClipPropColourspace and OfxImageClipPropPreferredColourspaces now accept special strings of the form “OfxColourspace_<clipname>. This allows for cross-referencing between different clips to ensure consistency across multiple inputs and from input to output.

Signed-off-by: John-Paul Smith <jps@borisfx.com>
To simplify development for plug-ins which have simple colour management requirements, this commit introduces Basic (roles only) and Core (roles + core colourspaces) colour management styles.

Native has been renamed to Full and now the term native is used to refer to all three of these styles.

Signed-off-by: John-Paul Smith <jps@borisfx.com>
Signed-off-by: John-Paul Smith <jps@borisfx.com>
Basic colour management mode no longer refers to roles and instead uses a small set of OFX-specific colourspace names which should cover most scenarios. These are defined in OCIO using roles for compatibility purposes, but in OFX, the expectation is that these might correspond to any colourspace that has the same encoding.

Signed-off-by: John-Paul Smith <jps@borisfx.com>
A new action, OfxImageEffectActionGetOutputColourspace, allows the host to specify its preferred colourspaces for the plug-in’s output clip, and for the plug-in to specify the colourspace it selected.

OfxImageEffectActionGetClipPreferences now mentions that the plug-in can specify input clip colourspace preferences in this action.

Signed-off-by: John-Paul Smith <jps@borisfx.com>
To aid with versioning, the OFX OCIO config has been renamed, now including the OpenFX version number instead of the version number of the upstream OCIO config.

Basic colourspaces have been removed from the reference OCIO config, allowing hosts and plug-ins to freely choose any colourspace with the correct attributes.

Two colourspaces were missing from the core style and have been added.

Various doc improvements to fix typos and make the intended usage clearer.

Signed-off-by: John-Paul Smith <jps@borisfx.com>
Although the API should remain stable, colourspaces will change over time, and it’s likely hosts and plug-ins will support multiple versions of the spec for backwards compatibility. To address this, new properties have been introduced to allow negotiation of the config to use for native mode. This is somewhat similar to the use of built-in configs in OCIO.

Now that the native mode config negotiation is handled separately, the OCIO config property is reserved for use only in the OCIO style.

Hosts are now responsible for selecting the colour management style and config, and must set these in image effect properties.

Anticipating support for multiple versions, ofxColourspaceList.h has been renamed to a versioned name and is referred to as “the config header”. For now, it could be used as a drop-in replacement for ofxColourspaceList.h, but as soon as a second version is added, developers will need a strategy to manage these.

Additionally, the basic colourspaces have been renamed to include whether they are scene or display referred, and a descriptive label has been added.

Signed-off-by: John-Paul Smith <jps@borisfx.com>
It makse sense to allow the use of basic colourspaces in OCIO mode, but in order to allow that, it’s necessary for negotiate the native-mode config even in OCIO mode, to allow for future changes to the set of basic colourspaces.

Also some minor doc improvements.

Signed-off-by: John-Paul Smith <jps@borisfx.com>
Signed-off-by: John-Paul Smith <jps@borisfx.com>
Clarifying the use of basic colourspaces.

Signed-off-by: John-Paul Smith <jps@borisfx.com>
Signed-off-by: Gary Oberbrunner <garyo@darkstarsystems.com>
Signed-off-by: Gary Oberbrunner <garyo@darkstarsystems.com>
Signed-off-by: Gary Oberbrunner <garyo@darkstarsystems.com>
Also remove a bunch of old unused code from the example I copied this
from.

Signed-off-by: Gary Oberbrunner <garyo@darkstarsystems.com>
- Fix negative rowbytes
- Add unspecified preferred input space
- Set input preferred space correctly

Signed-off-by: Gary Oberbrunner <garyo@darkstarsystems.com>
- Example dir name
- Example source file name

Signed-off-by: Gary Oberbrunner <garyo@darkstarsystems.com>
Signed-off-by: Gary Oberbrunner <garyo@darkstarsystems.com>
Signed-off-by: Gary Oberbrunner <garyo@darkstarsystems.com>
Signed-off-by: Gary Oberbrunner <garyo@darkstarsystems.com>
@garyo
Copy link
Contributor Author

garyo commented Jul 12, 2024

This has now been merged into PR #103. Closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants