Topics

Shot luts and different monitor calibrations


Simon Björk
 


I'm trying to build a config that has a shot lut applied as a look. It all works well with:
 - !<View> {name: Grade, colorspace: Output - sRGB, looks: PreGrade_LUT | nolook}
However, I need this to support different monitors calibrations, not just sRGB. Do I need to create different views for each display?
- !<View> {name: Grade - rec.709, colorspace: Output - Rec.709, looks: PreGrade_LUT | nolook}
I thought I could use environment variables to change this dynamically, but it doesn't seem to work:
- !<View> {name: Grade, colorspace: ${DEFAULT_VIEW}, looks: PreGrade_LUT | nolook}
Any suggestions?


-------------------------------
Simon Björk
Compositor/TD

+46 (0)70-2859503


Simon Björk
 

Or is the recommended way to use Displays for this and then filter out the list based on the ACTIVE_DISPLAYS environment variable?

Related to that, why does the ACES config only have a single display called ACES?

Thanks!

/Simon



-------------------------------
Simon Björk
Compositor/TD

+46 (0)70-2859503


Den ons 25 nov. 2020 kl 13:40 skrev Simon Björk via lists.aswf.io <bjork.simon=gmail.com@...>:


I'm trying to build a config that has a shot lut applied as a look. It all works well with:
 - !<View> {name: Grade, colorspace: Output - sRGB, looks: PreGrade_LUT | nolook}
However, I need this to support different monitors calibrations, not just sRGB. Do I need to create different views for each display?
- !<View> {name: Grade - rec.709, colorspace: Output - Rec.709, looks: PreGrade_LUT | nolook}
I thought I could use environment variables to change this dynamically, but it doesn't seem to work:
- !<View> {name: Grade, colorspace: ${DEFAULT_VIEW}, looks: PreGrade_LUT | nolook}
Any suggestions?


-------------------------------
Simon Björk
Compositor/TD

+46 (0)70-2859503


Sloan, Blake
 

Hello Simon,

 

Displays don’t appear to be doing much work in the nuke-default and ACES configs. The spi-anim config has an example of how Display can be used to partition ones Views by the type of display (projector, sRGB monitor).

 

Getting back to your question about Looks, I’ve never tried to set the colorspace using an environment variable.

 

Creating Views for each display calibration using the Display key might be the best approach:

displays:

       Monitor:

- !<View> {name: Grade, colorspace: Output - sRGB, looks: PreGrade_LUT | nolook}

       Projector:

- !<View> {name: Grade, colorspace: Output - P3D65, looks: PreGrade_LUT | nolook}

 

Hope I have not steered you too far off-course.

 

-blake

 

From: <ocio-dev@...> on behalf of "Simon Björk via lists.aswf.io" <bjork.simon=gmail.com@...>
Reply-To: "ocio-dev@..." <ocio-dev@...>, "bjork.simon@..." <bjork.simon@...>
Date: Wednesday, November 25, 2020 at 6:51 AM
To: "ocio-dev@..." <ocio-dev@...>
Subject: Re: [ocio-dev] Shot luts and different monitor calibrations

 

Or is the recommended way to use Displays for this and then filter out the list based on the ACTIVE_DISPLAYS environment variable?

 

Related to that, why does the ACES config only have a single display called ACES?

 

Thanks!

 

/Simon


 

 

-------------------------------

Simon Björk

Compositor/TD

 

+46 (0)70-2859503

 

 

Den ons 25 nov. 2020 kl 13:40 skrev Simon Björk via lists.aswf.io <bjork.simon=gmail.com@...>:


I'm trying to build a config that has a shot lut applied as a look. It all works well with:

 - !<View> {name: Grade, colorspace: Output - sRGB, looks: PreGrade_LUT | nolook}

However, I need this to support different monitors calibrations, not just sRGB. Do I need to create different views for each display?

- !<View> {name: Grade - rec.709, colorspace: Output - Rec.709, looks: PreGrade_LUT | nolook}

I thought I could use environment variables to change this dynamically, but it doesn't seem to work:

- !<View> {name: Grade, colorspace: ${DEFAULT_VIEW}, looks: PreGrade_LUT | nolook}

Any suggestions?

 

 

-------------------------------

Simon Björk

Compositor/TD

 

+46 (0)70-2859503


Kevin Wheatley
 

Why the ACES and Nuke configs only have a single display, mostly for
legacy reasons. There were tools which didn't work well with the
situation of having different lists of views for different displays,
so the ACES config structured all the views under a single display,
Ideally tools would be able to handle this case better.

e.g. if you have:

Display 1 with views A, B and C
Display 2 with views A, C, D

When the user selects Display 1 with View B all good, but selecting
Display 1 from a drop down which choice should be shown for the view,
etc.

the ACES config basically combined them to say

Display ACES, with views 1A, 1B, 1C, 2A, 2C, 2D

It is more in keeping with how OCIO is intended to be used, to use
multiple displays to represent different display devices.

Kevin


Simon Björk
 

Thanks Blake and Kevin for the explanations, really appreciated.

The whole thing with having multiple displays seems really nice and seems to work well in Nuke at least.

I guess one problem might be that User A (sRGB monitor) saves his Nuke script and when it's opened by User B (Rec709 monitor) the sRGB view is missing and Nuke
will give an annoying error. I see that the old spi configs use the same name for views across displays which would help with this, but it might also be confusing for the user.
Maybe there's a way to check for color spaces via a Nuke callback before the error is thrown.

Still, wouldn't it be nice to be able to set colorspace with an environment variable? That way I wouldn't need to have register multiple views/displays for a situation like this.
- !<View> {name: Grade, colorspace: ${DEFAULT_VIEW}, looks: PreGrade_LUT | nolook}

-------------------------------
Simon Björk
Compositor/TD

+46 (0)70-2859503


Den ons 25 nov. 2020 kl 19:12 skrev Kevin Wheatley <kevin.j.wheatley@...>:

Why the ACES and Nuke configs only have a single display, mostly for
legacy reasons. There were tools which didn't work well with the
situation of having different lists of views for different displays,
so the ACES config structured all the views under a single display,
Ideally tools would be able to handle this case better.

e.g. if you have:

Display 1 with views A, B and C
Display 2 with views A, C, D

When the user selects Display 1 with View B all good, but selecting
Display 1 from a drop down which choice should be shown for the view,
etc.

the ACES config basically combined them to say

Display ACES, with views 1A, 1B, 1C, 2A, 2C, 2D

It is more in keeping with how OCIO is intended to be used, to use
multiple displays to represent different display devices.

Kevin