Feature Request for looks

[chrisbrejon]

Hi everyone,

we had a bit of a conversation about looks in the UX group yesterday and I wanted to create a feature request so it can be discussed more broadly.

I am trying to find a simple solution for non-OCIO experts like me to load looks in a DCC software. Expert users in many VFX studios combine "Views + Looks" but I would like something simpler, if possible. ;-)

So yesterday someone (I can't remember the name, sorry!) threw the idea of [active_looks]. You could have 50 looks available in the config, but only 5 "active"... exactly like displays and views. I'd be curious to see what people thinks of this feature request. In an OCIO config, it could look like this :

active_displays: [Display - sRGB, Display - Rec.1886 / Rec.709 Video, Display - P3-D65, Display - P3-DCI]
active_views: [Output - SDR Video - ACES 1.0, ACES 1.1, Output - HDR Cinema (108 nits & P3 lim) - ACES 1.1, Raw]
active_looks: [Vision, Earthy, Complement, Bipack]

The idea would be then to have a dropdown menu in "Viewers" for the active looks, if that makes sense. Here is a mockup to give you an idea :

Blender has kinda done something similar :

I know that Nuke and Katana have come up with "OCIOLookTransform" nodes as well but I guess in the viewer it would be more convenient.

A mockup in a render engine would be like this for example :

Thanks, Chris

[chrisbrejon]

I also wanted to mention some thoughts on this particular matter by @zachlewis.

There are definitely times when a vfx pipeline TD would want to constrain artists to only certain technical looks in the viewer buffer -- i.e., for use with the sanctioned production views for a task. If a TD tells artists to toggle between "Client Grade" and "Show LUT" views for shot "poo6660", it would be important to stare at the same thing; it's the only insurance we have when everyone's working remotely.

Still, in these production cases, it could be interesting to expose artists to certain looks bound to certain encodings (via OCIOv2 View Rules, or maybe do we need Look Rules). It would be super useful to expose (or allow) discrete +/- EV or contrast variants, or a specific show "LCC" look ("low contrast curve"); maybe looks for different elements ("bg1", "fg1", "fg2") or different light sources maybe.

Commonly, vfx configs define Show-LUT-referred context-specific (eg, per-shot) "avid" (or "di" or "client grade" or "shot" or "film" or ...) looks that match what editorial is showing the client; and more often for long form than short form, there's some kind of neutral (or "balance" or "flat" or "ALG" or ...) easily invertible look intended to nudge plates towards the same world for vfx pipeline convenience.

There are also situations when one would not be working under such pipeline constraints, where he'd be interested to have easy access to a few of his favorites looks -- pipeline-independent asset dev is a great example here. Mix and match different DRT views and LMTs / FL looks / ALFs / IPP2 looks.

The OCIOLookTransform is good example for how a Viewer buffer UI element should incorporate looks, or how a "look layer" in a NLE might work.

Hope this helps, Zach and Chris

[zachlewis]

Just to clarify - my comments above are more general thoughts re: practical implications of exposing Looks options in frame buffer UIs for vfx production pipelines. And to further clarify, in production, I definitely do not want most artists to have an easy way to work under any creative look outside those we specifically sanction. Allowing artists to QC their work under different creative and technical looks is one thing; making it easy for artists to work "incorrectly" for the pipeline is quite another.

More generally, I'm not personally 100% enamored with the idea of exposing dynamic Looks-related UI elements for basic frame buffers -- I'd rather dedicate precious UI real-estate to separate Display / View menus, and Gamma / Gain / Contrast sliders. If there's room left over, I'd love it see it dedicated to Context-related feedback ("$SEQ / $SHOT / $ELEM" or some other user-provided string).

But I do think UIs should consider offering a simple "Toggle Look" element for enabling / disabling a custom Look Expression string (maybe the string itself can be hidden from the actual UI, and exposed in UI preferences; and maybe DCCs can allow a selection of custom Look Expression strings).

[chrisbrejon]

Thanks Zach ! It seems that combining Views and Looks is quite common. And I would like to offer an alternative proposal for that. Of course, you certainly do not want to give access to modifying looks easily in a VFX pipeline.

The way I picture it :

• with a VFX pipeline, the Look dropdown menu would be "grayed out"/unmodifiable (probably set to the env var loading the look for a sequence or a shot).
• with a "default" config with looks, you would have access to the menu and would load them at your convenience (among the list of looks available).

it just seems to me that the current in unsatisfying, like this example :

displays:
  TACOv2 48 nits cinema dark:
    - !<View> {name: "P3D65", colorspace: "DCI: 2.6 Gamma - P3D65"}
    - !<View> {name: "P3D65 (Generic)", colorspace: "DCI: 2.6 Gamma - P3D65", looks: Generic}
    - !<View> {name: "P3D65 (Contrast)", colorspace: "DCI: 2.6 Gamma - P3D65", looks: Contrast}
    - !<View> {name: "P3D65 (Base)", colorspace: "DCI: 2.6 Gamma - P3D65", looks: Base}
    - !<View> {name: "P3D65 (Vision)", colorspace: "DCI: 2.6 Gamma - P3D65", looks: Vision}
    - !<View> {name: "P3D65 (Light)", colorspace: "DCI: 2.6 Gamma - P3D65", looks: Light}
    - !<View> {name: "P3D65 (Vivid)", colorspace: "DCI: 2.6 Gamma - P3D65", looks: Vivid}
    - !<View> {name: "P3D65 (Teal)", colorspace: "DCI: 2.6 Gamma - P3D65", looks: Teal}
  TACOv2 100 nits office::
    - !<View> {name: "sRGB Display: 2.2 Gamma - Rec.709", colorspace: "sRGB Display: 2.2 Gamma - Rec.709"}
    - !<View> {name: "sRGB Display: 2.2 Gamma - Rec.709 (Generic)", colorspace: "sRGB Display: 2.2 Gamma - Rec.709", looks: Generic}
    - !<View> {name: "sRGB Display: 2.2 Gamma - Rec.709 (Contrast)", colorspace: "sRGB Display: 2.2 Gamma - Rec.709", looks: Contrast}
    - !<View> {name: "sRGB Display: 2.2 Gamma - Rec.709 (Base)", colorspace: "sRGB Display: 2.2 Gamma - Rec.709", looks: Base}
    - !<View> {name: "sRGB Display: 2.2 Gamma - Rec.709 (Vision)", colorspace: "sRGB Display: 2.2 Gamma - Rec.709", looks: Vision}
    - !<View> {name: "sRGB Display: 2.2 Gamma - Rec.709 (Light)", colorspace: "sRGB Display: 2.2 Gamma - Rec.709", looks: Light}
    - !<View> {name: "sRGB Display: 2.2 Gamma - Rec.709 (Vivid))", colorspace: "sRGB Display: 2.2 Gamma - Rec.709", looks: Vivid}
    - !<View> {name: "sRGB Display: 2.2 Gamma - Rec.709 (Teal)", colorspace: "sRGB Display: 2.2 Gamma - Rec.709", looks: Teal}

You end up with combining looks with many views. Not ideal, right ?

Thanks, Chris

[chrisbrejon]

Hello again, I did a couple of OCIO configs in the past month... And the more I think of it, the more I like the idea of "active looks". Especially if ACES 2.0 comes with a couple of LMT in the config.

I thought about its Nuke implementation and I did a mockup. ;-)

If I find a developer who would be willing to give this "active looks" feature a stab, would it be accepted ? Or does this feature have to be discussed prior to any development ?

I think it would make a lot of sense to be able to combine "one the fly" Displays, Views and Looks. And we would have tidier OCIO configs as well I think.

Regards, Chris

[sharktacos]

Hey Chris,

In addition to these great suggestions, I'd also add that it would be great if there was a way to generate CTL and CLF transforms in a program like Nuke interactively, rather than these being command-line tools only. Nuke currently has OCIOfileTransform which can read a file transform, but not write one. Is that on the roadmap anywhere?

Derek

[chrisbrejon]

This would be more of a question for Nuke developers I guess. @sharktacos

I have been thinking a lot about the question from @doug-walker during our last UX meeting : what are you trying to solve ? Which is a proper question. ;-) I guess the easiest answer I have found in the past weeks is : to give an easy access to looks.

I haven't seen in much use of Looks in any animation studio I have worked at and I have been wondering why for a long time. I understand that Looks are combined with Views in most VFX pipelines but I can't help to think that they are two different things.

Having a drop-down menu giving access to Looks (maybe with an "active looks" feature) would make Looks easier to use for most artists. I reckon not everyone is familiar with editing OCIO configs. So when I saw the Blender screenshot (shared in my first message of this Issue), it really made sense to me.

I have been shared yesterday this video about RenderMan 24 and I was really please to see to see the following feature implemented :

Because it reminds me of what Blender does and the mockup UI I did show in the UX meeting (which I need to improve based on Michael's comments) :

I totally acknowledge that in any pipeline, you want Views and Looks "locked" to avoid any user mistake. But I'm pretty sure there is a solution somewhere that'll make everyone happy.

Hope that make sense, Chris

[chrisbrejon]

Hello again,

following the UX meeting from yesterday , I just wanted to share a bit what had been discussed about looks and their availability in UI :

• On one hand, I would like to give an easy access to looks (like Renderman 24 and Blender) to freelance artists, students...
• On the other hand, I understand that in a pipeline you want to lock things down for safety.

My idea (actually from Mark in one of the UX meeting) was about a feature of 'active_looks'. I had imagined the following :

• There would be no change with a config where Views and Looks are combined. The drop-down menu of Looks would be empty or even locked.
• A config with 'active_looks' would "trigger" the 'Looks' drop-down menu with a list of Looks to choose from.

But yesterday, I think I have even come with something even easier, which does not require any new feature such as 'active_looks'.

Here is what I got :

• A config with 'Views + Looks' combined would work as usual. The Looks drop-down menu would be empty or locked.
• A config with 'Views' (no look added) would offer with a list of Looks to choose from the drop-down menu.

Here is a mock-up with the Filmic blender config :

• If I use this (Views + Looks combined) :

  # VRay users should uncomment the Filmic views below as VRay doesn't permit Looks
  - !<View> {name: Filmic Very High Contrast, colorspace: Filmic Log Encoding, look: +Very High Contrast}
  - !<View> {name: Filmic High Contrast, colorspace: Filmic Log Encoding, look: +High Contrast}
  - !<View> {name: Filmic Medium High Contrast, colorspace: Filmic Log Encoding, look: +Medium High Contrast}
  - !<View> {name: Filmic Very Low Contrast, colorspace: Filmic Log Encoding, look: +Very Low Contrast}
  - !<View> {name: Filmic Medium Low Contrast, colorspace: Filmic Log Encoding, look: +Medium Low Contrast}
  - !<View> {name: Filmic Low Contrast, colorspace: Filmic Log Encoding, look: +Low Contrast}
  - !<View> {name: Filmic Base Contrast, colorspace: Filmic Log Encoding, look: +Base Contrast}
  - !<View> {name: Filmic False Colour, colorspace: Filmic Log Encoding, look: +False Colour}
  - !<View> {name: Debug, colorspace: Debug}

  I would have this in the UI (Look drop-down menu is empty and locked):

• If I use this (Views with no looks) :

  BT.1886:
  - !<View> {name: BT.1886 EOTF, colorspace: BT.1886 EOTF}
  - !<View> {name: Non-Colour Data, colorspace: Non-Colour Data}
  - !<View> {name: Linear Raw, colorspace: Linear}
  - !<View> {name: Filmic Log Encoding Base, colorspace: BT.1886 Filmic Log Encoding}

  I would have this in the UI (Looks drop-down menu available) : https://user-images.githubusercontent.com/70026961/124575039-55e64580-de4b-11eb-9b0d-49b8fd259b4b.mp4 by simply reading 'Looks' in the config :

  looks:
  - !<Look>
  name: Greyscale
  process_space: Filmic Log Encoding
  transform: !<MatrixTransform> {matrix: [0.2126729, 0.7151521, 0.0721750, 0, 0.2126729, 0.7151521, 0.0721750, 0, 0.2126729, 0.7151521, 0.0721750, 0, 0, 0, 0, 1]}
  
  - !<Look>
  name: False Colour
  process_space: Filmic Log Encoding
  transform: !<GroupTransform>
      children:
        - !<MatrixTransform> {matrix: [0.2126729, 0.7151521, 0.0721750, 0, 0.2126729, 0.7151521, 0.0721750, 0, 0.2126729, 0.7151521, 0.0721750, 0, 0, 0, 0, 1]}
        - !<FileTransform> {src: Filmic_False_Colour.spi3d, interpolation: best}

  Hope that makes sense, Chris

[EaryChow]

Hello, not sure if there is any development on this. As I am making some looks for the still-developing AgX config, I came across a problem.

https://blenderartists.org/t/feedback-development-filmic-baby-step-to-a-v2/1361663/281?u=eary_chow

The looks are either completely or partially applied after view transform (done by specifying the process_space to the view-transform space). But the problem is, the config supports three displays: sRGB, Display P3, and BT.1886. Each of them has their own view-transform space. Therefore ideally we can create three different versions of the look, with BT.1886 version having process_space of AgX Base BT.1886, Display P3 version's process space being AgX Base Diplay P3, just like how you define views for different displays.

But the problem is, all these looks are shared across different views and displays, there is no way to only associate one look with one view or diplay. Even when I use BT.1886 display, Display P3 version of the look will still show up.

https://blenderartists.org/t/feedback-development-filmic-baby-step-to-a-v2/1361663/283?u=eary_chow

So in addition to the active_looks and things, I think we need a way to either associate a look with a view/display, or hide a certain look for a certain view/display, if it is not already possible.

[sharktacos]

@EaryChow I'm not familiar with Blender, so apologies if I am misunderstanding. However, I think what you are requesting may be more along the lines of DCC implementation, rather than something that needs to be changed in OCIO itself. For example, I have a config with shared_views that includes looks

shared_views:
  - !<View> {name: ACES 1.0 - SDR-video, view_transform: Output - SDR Video - ACES 1.0, display_colorspace: <USE_DISPLAY_NAME>}
   - !<View> {name: ACES 1.0 - SDR-video - RGC, view_transform: Output - SDR Video - ACES 1.0, looks: LMT_gamut, display_colorspace: <USE_DISPLAY_NAME>}

This is then used in various displays displays:

  sRGB:
    - !<Views> ["ACES 1.0 - SDR-video", "ACES 1.0 - SDR-video - RGC"]
  Gamma 2.2:
    - !<Views> ["ACES 1.0 - SDR-video", "ACES 1.0 - SDR-video - RGC"]
  Apple Display P3:
    - !<Views> ["ACES 1.0 - SDR-video", "ACES 1.0 - SDR-video - RGC"]

In Maya this gives me what I believe you are looking for. I only see the views for the display I have selected. In Nuke, however, I see all of the views for all the displays in a huge long list. So it looks like Nuke and Blender need to update their GUI to have it work like Maya's.

[EaryChow]

Hi @sharktacos Your examples are views, I know you can have different views per display, and you can also have look baked into the view. But I am trying to have several looks that only show up if I use a certain view or display. I don't think we are talking about the same thing.

[sharktacos]

@EaryChow gotcha, thanks for clarifying.