LUT shaper for CG

vfx
workflow
Tags: #<Tag:0x00007f3c5cc5c930> #<Tag:0x00007f3c5cc5c7f0>

(Francois Lord) #1

Here’s one for the masters…

I want to create a LUT for houdini mplay to display all images with the RRT sRGB. I know all about ociobakelut and shaper luts.
Which shaper lut would you use?
In the ACES OCIO 1.0.3 config, there are a bunch of shaper luts in the utility family, mostly log2 and Dolby as well as the LMT shaper. Which one would be best suited to act as a shaper for CG material?

Thanks!


(Walter Arrighetti) #2

Hello.
I’m not entirely sure what you mean by “shaper” (this has usually several meanings), and I’m not familiar with Houdini’s color processing. If you mean to create a LUT representing an Output Transform to sRGB (with gamma 2.2*) though, then for the ODT part of the OT you should use, according to your viewing environment, either one of the two CTLs

transforms / ctl / odt / rgbMonitor / ODT.Academy.RGBmonitor_*.ctl

The RRT part in your OT must always (implicitly) be the same one:

transforms / ctl / rrt / RRT.ctl

Hope that helps.

* or, more rigorously, using a display EOTF as per IEC 61966-2-1:1999.


(Francois Lord) #3

Hmmm, I realize my question wasn’t clear at all. I found the answer by myself, but I will explain it here so that other people can find it.

Houdini uses its own 3d lut format for the display of images in “mplay”, its image viewer. The lut reads scene linear images and must do the conversion to screen display. Since the input images can range in floating point values from zero to well above 1, the lut needs a 1D shaper lut at the input to “reshape” the values between 0 and 1. Usually, we use a log shaper for that.

I made a few experiments in Nuke to test how high the sRGB ODT can read values before clipping. I used a ramp from black to float valut 50.0 in an image 5000 pixels wide. I applied the ODT to it and sampled the image using the sampler node. AT the top of the graph, when I zoomed in, I could see exactly where the ODT clips the values. I could easily calculate the highest values the ODT can display before clipping: 16.29325. Anything above that will be display as white 1.0.

So I need a shaper 1D-lut that can handle values as high as 16.3 to compress the values inside the range 0-1. The ACES OCIO config comes with multiple shapers in the Utility family. I tries several of them and did the same experiment to see how high they can go. All 48 nits shapers (LMT shaper, Log2 48 nits shaper, Dolby PQ 48 nits shaper) have the same range as the sRGB ODT (0-16.3) so any of them will do.

Here is the command to use to generate the lut
ociobakelut --inputspace ACEScg --outputspace "Output - sRGB" --shaperspace "Utility - Log2 48 nits shaper - AP1" --iconfig OpenColorIO-Configs/aces_1.0.3/config.ocio --format houdini --v ACEScg_to_ODT-sRGB_houdini.lut

And here is the lut file if anyone needs it.

F


(Francois Lord) #4

And I just realized this lut is included in the ocio config, but in my case I needed it for linear-sRGB instead of ACEScg, so I had to modify the ocio config to add a shaper in sRGB primaries.


(Nick Shaw) #5

It may not matter visually when used as a display LUT, but I notice that the 1024 entry shaper in your generated LUT goes from 0.000000 to 0.243925 in the first two entries. A quick calculation suggests that this means that all linear input values below about 0.018 are being interpolated from these two values, and input to the bottom left 16^3 of the 64^3 3D table.

An ACES value of 0.018 maps to about 0.035 when passed through the RRT and sRGB ODT. So output values in the shadow region could be subject to significant interpolation related errors. But as I said, these errors may well not be noticeable.


(Francois Lord) #6

You are right, but it has no visual impact. I tested the difference with the original ODT and it’s negligible. One could increase the resolution of the shaper in the ociobakelut command. I just used the default resolution for this format.

The lut that comes with the ACES OCIO config has a shaper with 4096 entries, which is more careful.

Cheers

F


(Nick Shaw) #7

I tend always to use at least 12 bit shapers for anything intended for linear input. In fact for ACES, 12 bit may be insufficient. If you create a 12 bit shaper to transform ACEScc to linear, and one to do the inverse, when you apply the two to a linear 0-1 ramp, the result is not the ramp you started with, but in fact a ramp with a dramatic bend at the lower end. Try it for yourself.

That is why ACES transforms are best done mathematically using something like Resolve DCTL or Truelight Colour Spaces.