Re: Required Roles

Troy Sobotka <troy.sobotka@...>

#1953

On Mon, May 11, 2020 at 10:24 PM Doug Walker <doug.walker@...> wrote:

OCIO::ROLE_DEFAULT, OCIO::ROLE_SCENE_LINEAR, OCIO::ROLE_DATA, OCIO::ROLE_REFERENCE, OCIO::ROLE_COMPOSITING_LOG, OCIO::ROLE_COLOR_TIMING, OCIO::ROLE_COLOR_PICKING, OCIO::ROLE_TEXTURE_PAINT, OCIO::ROLE_MATTE_PAINT

However, once the DisplayTransform refactor is completed (as discussed at the previous working group meeting), none of these will actually be required for the proper operation of the core library. So the ociocheck is basically only enforcing this for the benefit of various apps/plug-ins that may want to rely on those roles being present.

I am hoping that some bedrock aliases will remain in the event that a configuration is added and reconciliation cannot be made in a DCC.

Without aliases, the whole system would have to revert to hard coded transforms, which is of course ghastly.

Data, working space / scene linear, and a few others are vital in this regard.

With respect,

TJS

Re: Inverting a 3D LUT

Doug Walker

#1952

> How is this overridden with an environment variable?

Check out OCIO_OPTIMIZATION_FLAGS_ENVVAR in OpenColorTypes.h.

> If I do getDefaultCPUProcessor(), it's always the same as getOptimizedCPUProcessor(OPTIMIZATION_DEFAULT).

Yes, that is expected. But if that env var was set, both of those would be overridden by the env var.

Doug

Re: Required Roles

Doug Walker

#1951

That's a good suggestion Brendan, we will look into adding that.

And as Troy wrote, ociocheck does in fact throw an error if the following roles are not present:

OCIO::ROLE_DEFAULT, OCIO::ROLE_SCENE_LINEAR, OCIO::ROLE_DATA, OCIO::ROLE_REFERENCE, OCIO::ROLE_COMPOSITING_LOG, OCIO::ROLE_COLOR_TIMING, OCIO::ROLE_COLOR_PICKING, OCIO::ROLE_TEXTURE_PAINT, OCIO::ROLE_MATTE_PAINT

However, once the DisplayTransform refactor is completed (as discussed at the previous working group meeting), none of these will actually be required for the proper operation of the core library. So the ociocheck is basically only enforcing this for the benefit of various apps/plug-ins that may want to rely on those roles being present.

Doug

Re: Inverting a 3D LUT

Brendan Bolles

#1950

On Mon, May 11, 2020 at 03:02 PM, Doug Walker wrote:

But note that (as with a number of other OCIO features) it is also possible for users to override the optimization setting via an environment variable. So even if apps don't provide a UI, that may provide an alternative for power users.

How is this overridden with an environment variable? If I do getDefaultCPUProcessor(), it's always the same as getOptimizedCPUProcessor(OPTIMIZATION_DEFAULT).

Brendan

Re: Required Roles

Brendan Bolles

#1949

On Mon, May 11, 2020 at 03:36 PM, Doug Walker wrote:

A v2 config must specify a default color space, but this could either be done using the default role or a default file rule. So if the config does not use file rules, then yes, the default role is required.

Hmmm, what would you guys think about adding a getDefaultColorspace() function to match and getDefaultDisplay() and getDefaultView() functions?

Brendan

Re: Required Roles

Troy Sobotka <troy.sobotka@...>

#1948

On Mon, May 11, 2020 at 3:36 PM Doug Walker <doug.walker@...> wrote:

As Troy wrote, the scene linear role is required by ociocheck, which also verifies that any supplied roles have color spaces that exist.  However it does not require any other roles and I don't believe any others are required.
ociocheck and sanity check should abide by the following
pre-established roles I believe:
```
ociocheck --iconfig config.ocio

OpenColorIO Library Version: 1.1.1
OpenColorIO Library VersionHex: 16843008
Loading config.ocio

** General **
Search Path:
Working Dir: /foo/bar

Default Display:
Default View:

** Roles **
ERROR: NOT DEFINED (default)
ERROR: NOT DEFINED (scene_linear)
ERROR: NOT DEFINED (data)
ERROR: NOT DEFINED (reference)
ERROR: NOT DEFINED (compositing_log)
ERROR: NOT DEFINED (color_timing)
ERROR: NOT DEFINED (color_picking)
ERROR: NOT DEFINED (texture_paint)
ERROR: NOT DEFINED (matte_paint)

** ColorSpaces **
Error: scene_linear role must be defined.

** Looks **
no looks defined

** Sanity Check **
ERROR
Config failed sanitycheck. No displays are specified.

11 tests failed.
```

With respect,
TJS

Re: Required Roles

Doug Walker

#1947

> I've been using "default" (aka ROLE_DEFAULT) as my default color spaces, but then looking at the docs, I guess the

> "default" role isn't required to be in a config. Is "scene_linear" required? Any others? Somehow strictparsing is involved?

Brendan, the default role was used used by the v1 feature for extracting a color space name from an image file path. If strict parsing was not enabled and no color space name was found, then the default color space is returned. The default role was also used by some other API calls, such as getIndexForColorSpace (although that is not the case for OCIO v2).

Not sure if your question was for OCIO v1 or v2 (that is, master branch). The documentation you linked to is for v1. Note that the v2 documentation remains to be written (and we are looking for volunteers to help us with that!).

The new File Rules feature in v2 expanded the ability for users to assign color spaces based on file paths. If you're interested in that topic, please check out PR #904.

A v2 config must specify a default color space, but this could either be done using the default role or a default file rule. So if the config does not use file rules, then yes, the default role is required.

As Troy wrote, the scene linear role is required by ociocheck, which also verifies that any supplied roles have color spaces that exist. However it does not require any other roles and I don't believe any others are required.

Doug

Re: Inverting a 3D LUT

Doug Walker

#1946

>I guess there have been some changes in this area. So I take it OPTIMIZATION_LUT_INV_FAST has now taken

> taken the place of not using FINALIZATION_EXACT. And the exact mode is used if you don't include the flag?

Yes, the finalization options were merged into the optimization options since there was so much overlap.

And yes, the exact mode is used if that bit of the optimization settings is zero.

But just to be clear for others, the default settting (OPTIMIZATION_DEFAULT) does include OPTIMIZATION_LUT_INV_FAST, so the exact mode is actually not the default. (This was the preference of the group when it was discussed at one of the v2 working group meetings.)

> What sort of UI for this quality stuff are we expecting to present to the user?

> ... should OCIO apps now give a general Draft/Best option for all OCIO operations?

It's a good question Brendan. For now, there is no guidance and it is up to the apps to decide if the feature is useful for their users or not. In my opinion, OPTIMIZATION_DEFAULT will cover the vast majority of use-cases. So my view is that the UI for "average users" should not present this as an option as it will likely cause needless worry and confusion.

But note that (as with a number of other OCIO features) it is also possible for users to override the optimization setting via an environment variable. So even if apps don't provide a UI, that may provide an alternative for power users.

It might be useful to work on some user interface guidelines that could cover topics like this. If anyone is interested in helping draft something like that, please reach out to me or another TSC member.

Doug

Re: Required Roles

Troy Sobotka <troy.sobotka@...>

#1945

On Mon, May 11, 2020 at 12:12 PM Brendan Bolles <brendan@...> wrote:

I've been using "default" (aka ROLE_DEFAULT) as my default color spaces, but then looking at the docs, I guess the "default" role isn't required to be in a config. Is "scene_linear" required? Any others? Somehow strictparsing is involved?

The ociocheck tool and the sanity check API should flag missing default roles.

With respect,

TJS

Required Roles

Brendan Bolles

#1944

I've been using "default" (aka ROLE_DEFAULT) as my default color spaces, but then looking at the docs, I guess the "default" role isn't required to be in a config. Is "scene_linear" required? Any others? Somehow strictparsing is involved?

Brendan

Re: Inverting a 3D LUT

Brendan Bolles

#1943

I guess there have been some changes in this area. So I take it OPTIMIZATION_LUT_INV_FAST has now taken taken the place of not using FINALIZATION_EXACT. And the exact mode is used if you don't include the flag?

What sort of UI for this quality stuff are we expecting to present to the user? I see that OPTIMIZATION_DEFAULT = OPTIMIZATION_VERY_GOOD, which includes OPTIMIZATION_LUT_INV_FAST. And there's OPTIMIZATION_LOSSLESS, which does not and has other flags as well.

I currently provide a back door to doing the exact LUT invert, but should OCIO apps now give a general Draft/Best option for all OCIO operations?

Brendan

Upcoming Events #cal-summary

ocio-dev@lists.aswf.io Calendar <ocio-dev@...>

#1942

OpenColorIO Dev Discussion Upcoming Events

OpenColorIO TSC meeting (weekly)

When:
Monday, 11 May 2020, 9:30am to 10:00am
(GMT-07:00) America/Los Angeles

Where:
https://zoom.us/j/924729729

Organizer: Michael Dolan michdolan@...

Details:
Weekly meeting of the OpenColorIO TSC.

Add topics to the meeting agenda.

Meeting notes listed by YYYY-MM-DD.md format at:
https://github.com/imageworks/OpenColorIO/tree/master/docs/tsc/meetings

Join Zoom Meeting
https://zoom.us/j/924729729

One tap mobile
+16699006833,,924729729# US (San Jose)
+16465588656,,924729729# US (New York)

Dial by your location
        +1 669 900 6833 US (San Jose)
        +1 646 558 8656 US (New York)
        +1 877 369 0926 US Toll-free
        +1 855 880 1246 US Toll-free
Meeting ID: 924 729 729
Find your local number: https://zoom.us/u/abo9cwSMxj