DisplayViewTransforms for output?

sharktacos commented 1 year ago

I'm noting that the configs do not appear to have any DisplayViewTransforms. Have you considered adding these? If not for all display/view combinations, then perhaps just a couple to cover the most common scenarios: ACES 1.0 SDR - Rec709 for VFX to send proxy media to offline editorial, and ACES 1.0 SDR - sRGB for CG dailies. These could then also provide an example for config authors to add more as needed.

KelSolaar commented 1 year ago

Hi @sharktacos,

Have you tried the OCIODisplay node or equivalent in whatever DCC you are using?

Cheers,

Thomas

sharktacos commented 1 year ago

Hi @sharktacos,

Have you tried the OCIODisplay node or equivalent in whatever DCC you are using?

Hi @KelSolaar This would be for the Output Transform in a Nuke Write node so it bakes the view & display into the media.

KelSolaar commented 1 year ago

Right I see, so this is a side effect of the separation between traditional colorspaces and display spaces. It is admittedly annoying not being able to select them anymore in the various nodes. @doug-walker: Any idea on how we could improve that?

carolalynn commented 1 year ago

I know it’s annoying, but you could use the view transform mode and then set the write colorspace to raw.

Otherwise for now, suggest adding a colorspace with a display view transform to your config.

Longer term… we should for sure discuss!

On Fri, Oct 21, 2022 at 23:37 Thomas Mansencal @.***> wrote:

Right I see, so this is a side effect of the separation between traditional colorspaces and display spaces. It is admittedly annoying not being able to select them anymore in the various nodes. @doug-walker https://github.com/doug-walker: Any idea on how we could improve that?

— Reply to this email directly, view it on GitHub https://github.com/AcademySoftwareFoundation/OpenColorIO-Config-ACES/issues/82#issuecomment-1287647423, or unsubscribe https://github.com/notifications/unsubscribe-auth/AMPHU2B4QJL2FBGTTYVPZT3WEODUPANCNFSM6AAAAAARLKIO34 . You are receiving this because you are subscribed to this thread.Message ID: <AcademySoftwareFoundation/OpenColorIO-Config-ACES/issues/82/1287647423@ github.com>

--

CAROL PAYNE

Imaging Technologist

Creative Technologies

T 505.553.0076

5808 W. Sunset Blvd | Los Angeles, CA 90028

sharktacos commented 1 year ago

Right, FWIW here's what I added:

- !<ColorSpace>
    name: Output - ACES 1.0 - SDR Video (Rec.1886 Rec.709)
    family: Output
    description: ACES 1.0 SDR-video for Rec.709 HD video with Rec.1886 gamma (2.4)
    isdata: false
    categories: [ file-io ]
    encoding: sdr-video
    from_reference: !<GroupTransform>
      children:
        - !<DisplayViewTransform> {src: ACES2065-1, display: "Rec.1886 Rec.709 - Display", view: "ACES 1.0 - SDR Video"}
        - !<RangeTransform> {min_in_value: 0., min_out_value: 0., max_in_value: 1., max_out_value: 1.}

  - !<ColorSpace>
    name: Output - ACES 1.0 - SDR Video (sRGB)
    family: Output
    description: ACES 1.0 SDR-video for sRGB monitor (piecewise EOTF)
    isdata: false
    categories: [ file-io ]
    encoding: sdr-video
    from_reference: !<GroupTransform>
      children:
        - !<DisplayViewTransform> {src: ACES2065-1, display: "sRGB - Display", view: "ACES 1.0 - SDR Video"}
        - !<RangeTransform> {min_in_value: 0., min_out_value: 0., max_in_value: 1., max_out_value: 1.}

which gives this in Nuke:

doug-walker commented 1 year ago

@sharktacos, with OCIO v2 we are trying to be more rigorous about what constitutes a "color space". For this reason, the new configs do not bake view transforms or looks into the display color spaces.

As we move forward, I'm anticipating several relevant trends:

There will be a continued proliferation of various views and looks that people will want to use. This is already well underway with view transforms not only from ACES (with a new version in progress) but also from the cinema camera makers and others. (The ACES configs are focusing on ACES of course, but other configs will want to include view transforms from other sources too.)
There will be an increasing desire for the ability to interchange media in workflows between tools where it will be important to be able to tag what color space a piece of media is in.

If each view transform or look has its own color space, this becomes an untenable situation. In other words, the goal is to have one color space for an sRGB display, not a dozen, each with a different view or look baked in.

As a result, we have been trying to encourage software providers to include at least these two tools: 1) ColorSpaceTransform to convert between actual color spaces 2) DisplayViewTransform which converts to a display color space, baking in a view (and possibly a look) in the process

This is not only more rigorous from a color management point of view, it also helps clarify to end-users the important role of a view transform in the process. Baking in a view transform is a fundamentally different process than just converting between color space encodings, and it should be perceived as such by users.

Adding the second tool is not that much additional work and a number of applications have either already done this or have indicated that it's in their plans. For the reasons presented above, I'm strongly opposed to turning the new v2 configs back into v1 style configs by adding a proliferation of output "pseudo color spaces" that bake in various views. So, regarding the second part of your question, I don't think we should start down the road of even adding in a few of these. But thank you for the suggestion, I hope this explains some of the reasoning behind the design.

KelSolaar commented 1 year ago

Thanks for the great answer, I was hoping for something along those lines when I asked how we can improve that:

As a result, we have been trying to encourage software providers to include at least these two tools:

ColorSpaceTransform to convert between actual color spaces

DisplayViewTransform which converts to a display color space, baking in a view (and possibly a look) in the process

While it is clear to us why we took those design decisions, it is not for users, makes me wonder if we should extract what you wrote and put it in a FAQ or something along those lines.

sharktacos commented 1 year ago

Indeed it really is a great answer. Thanks @doug-walker for the time and thought you put into that explanation. It's really valuable and grealty appreciated to have insight into and appreciate the design decisions of the committee.

Pixel-Minions commented 1 year ago

Hello everyone, let me tell you about a user case to use Output - sRGB in my studio. Playblasting PNGs from Maya and writing the images with Output sRGB allowed us to preserve high dynamic range in the images if we were loaded a plate as an image plane. We were able to linearize the PNGs later in Nuke and apply any look without breaking the image. Using utility - srgb texture tends to break the image in these cases. I am not sure how other places handle these cases. The "technical" tone mapping that the Output sRGB colorspace has was a real blessing.

From the point of view of the artists, adopting ACES was already challenging; although I am all in favour of improvements and I love the work you have done, I am not sure how easy it will be to teach and adopt the changes that come with this new version. Hopefully, the next major version is less challenging.

I still have to play with the new configuration and learn about the new features and changes. Probably I am talking from ignorance but I hope the transition is not too painful.

doug-walker commented 1 year ago

Please note that you may still do what you are talking about with the new configs. In Maya, for example, in your Color Management preferences enable "Apply Output Transform to Playblast", set Transform Type to "View Transform" and Output Transform to "ACES 1.0 SDR-video (sRGB)".

Pixel-Minions commented 1 year ago

Thank you for the note!, I will play with the new config soon.

finnschi commented 1 year ago

So this would be on Foundry to implement a DisplayViewTransform button in the write node?

Nuke 14 does not have that button, so right now out of the box one cant write dailies from nuke using the latest configs, which is... not ideal I guess.

I do understand the seperation and that makes sense, but foundry needs to fix this then.

mjtitchener-fn commented 1 year ago

Hello, yes we (Foundry) do need to implement support for this in the Nuke Write node and we plan to do so. It just sadly didn't make it into Nuke 14.0v1.

so right now out of the box one cant write dailies from nuke using the latest configs

This isn't strictly true. The Nuke Write node doesn't yet have this option but as @carolalynn22 menitoned above you can use a combination of OCIODisplay and Write (set to raw) to do this (see below) I appreciate this isn't ideal though.

OCIODisplay {
 colorspace scene_linear
 display "sRGB - Display"
 view "ACES 1.0 - SDR Video"
 name OCIODisplay1
 selected true
 xpos 338
 ypos -129
}
Write {
 raw true
 name Write1
 selected true
 xpos 338
 ypos -95
}

KelSolaar commented 1 year ago

It is also worth keeping in mind that the config has only been released a bit over a month ago. While we have had some interim earlier releases, it is still only very recent and it will take a bit of time for vendors to implement support for all the bells and whistles.

AcademySoftwareFoundation / OpenColorIO-Config-ACES

DisplayViewTransforms for output? #82