Ideas of Basic Colourspace

[revisionfx]

Open Effects Proposal for Standard Change

Please read the contribution guidelines first.

Standard Change Workflow

• [ ] Create proposal as issue (you're doing this now!)
• [X ] Tag this issue with standard change tag
• [ ] Identify subcommittee: at least one plug-in vendor, and at least one host
• [x] Discuss the idea in this issue
• [ ] Write new or updated code and doc
• [ ] Publish updates as a pull request (ideally on a feature/PROPOSAL-NAME branch)
  • [ ] Make sure that PR references this issue number to keep them in sync
  • [ ] Discuss and review code in the PR
  • [ ] Meet all requirements below for accepting PR
• [ ] When subcommittee signs off and other members don't have any further review comments, maintainer merges PR to master which closes PR and issue

Requirements for accepting a standard change:

• [ ] Header files updated
• [ ] Documentation updated
• [ ] Release notes added
• [ ] Compatibility review completed
• [ ] Working code demonstrated with at least one host and one plugin
• [ ] At least two members sign off
• [ ] No further changes requested from membership

Summary

Making Basic Colourspace more useful

Motivation

Implementing it I made some observations

Problem

Thinking about how to make Basic Colourspace more useful. Also so there is "implementability" for a Basic only host.

1. Log: this defines nothing, is like roles Might as well make it ACEScc tone curve so it's something like linear is - without it being AP1 chromacity At least also defines 0 and 1 as 0 and 1 Alternatively ACEScct if more common - which is more like Cineon/DPX without the parameterization I guess. Will ask a small host who has only 2 tone support (DPX and linear) what he thinks.

2. Second, aside linear (and by extention for integer bitdepth -- gamma 1.8,2.2 which are defined and are sort of gammafied linear to fit better, historical example Maya was saving 8 bit sequence by just doing gamma 0.454). These are special cases without piecewise curves.

3. Third, for the rest, we basically have tone curves that are typically piecewise (two parts, e,g, if over X do this else do that) - where a part is linear, power or log -- with fancy ones adding some offsets and scalers to these (so out of Basic reach intelligibility). The distinction between what is currently named as "hdr-video" and "sdr-video" should maybe just be for "hdr-video": has a part that is log. That is many effect can live with an approximate gamma conversion to be close enough to convert to linear internally etc and undo that at the end within the context of what is described as "sdr" now... but it does not make much sense when a part of the gamma curve is log. Net basic could have an approximate gamma function for "linear" as redefined above AND "sdr" as currently named. And except perhaps for output "raw data" would not be a thing to switch output colorspace in Basic.

Of course there is rec709 chromacities or not - rec709 includes sRGB... or wider gamuts... one has to use core strings... for that.

Impact

would generate a version update

Stakeholders

Iterative implementation

Discussion

[garyo]

@revisionfx it's not clear exactly what you are asking for here. Do you have a concrete proposal you could share?

[revisionfx]

Yes replace naming and doc of basic typse as it's not usable right now for an host unless maybe it's linear only. This part we made up orthogonal to OCIO.

/** @brief ofx_display_hdr Any display-referred HDR video such as Rec. 2100 HLG or PQ. / /* @brief ofx_scene_log Any scene-referred colourspace with a log transfer function. */ is not useful - In practice there is no difference between s-log3 and HLG at that level... it's all has log. Would remove display from name and merge these two so there is no confusion with rec 2020 which has same tone curve as bt1886 (that something has Wide Color Gamut or not not as relevant here)... Would prefer like in AE Adobe color managed suite that there be not linear and sdr, just a support function GetApproximateGamma - would return 1 if linear and something else if not. Then an host that does not support OCIO can at least provide something useful as basic. Anything with hasLog would need to scale to core and over.

what is useful is to know if there is an approximate gamma or a part of the curve has log. I understand many format have a part linear and another part a power func.
we already moved on as not useful, creating an internal table of strings with approximate "power" representation vs those that have at least a piece of the curve log. Internally the filter is Log, Power, None. And we have an internal getApproximateGamma that passes the string - and we just enumerate all strings that have no log in their tone curve, then relying on host to convert to what they want in list.

[scritturamista]

I am in complete agreement that OpenFX needs to allow plugins to be color managed without having to rely on user intervention (i.e. users telling the plugin what color space each input clip is and/or what colorspace the output should be produced in.)

That said, is "Basic Colourspace" a request for a new API, an alternative to OCIO?

[barretpj]

I am in complete agreement that OpenFX needs to allow plugins to be color managed without having to rely on user intervention (i.e. users telling the plugin what color space each input clip is and/or what colorspace the output should be produced in.)

This is already in place with ofxColour.h.

[scritturamista]

@barretpj Indeed! But as a a newcomer to OFX I was just trying to understand his comments better and see what’s there to learn from the proposal.

[garyo]

Per the OpenFX TSC meeting, this is working as designed.