OCIO, Nuke Defaults and clipped values

[Simon Björk]

Hi all,

I've been using the After Effects version of OCIO (beta, but works
great) for a while, and I've noticed something strange when using the
Nuke defualts config. If I convert an image from linear to sRGB,
whites are clipped at 1.1250. This does not happen if I use a regular
Colorspace node in Nuke. Is this a known bug or am I missing something?

[Jeremy Selan]

Simon,

The conversion in the nuke-default profile relies on 1D luts to do conversions, and those 1D luts are currently defined from [-0.125, 1.125] (in the output color space)

So the expected behavior would be that linear values from [-0.0096749, 1.308] would map to [-0.125, 1.125] in srgb.  The equivalent for cineon is that [-0.008942, 36.099] in linear would map to  [-0.125, 1.125] in cineon.

Is this what you're seeing?

The choice of 1.125 is sort of arbitrary.  I wanted to get a bit of extra range in there to preserve a limited amount of overshoot / undershoot (otherwise 0,1 would have sufficed).  But if you have a use case where you need a greater range I'm happy to generate larger tables.

Also, when Brendan first implemented OCIO in After Effects, he observed errant clipping, which is not yet addressed.  You may be running into this instead.  https://github.com/imageworks/OpenColorIO/issues/196

This issue accidentally slipped off my radar, I'll do my best to get to it asap. (independent of whether it's what you're seeing or not).

-- Jeremy

[Simon Björk]

Hi Jeremy,

thanks for your explanation. The problem I'm seeing is probably what
Brendan adressed in the bottom of that post. Sometimes there is an
advantage to convert an image to sRGB do specific compositing tasks
(keying for example), and then back to linear. In the current state, I
guess I'm not sure how to handle this properly and still maintain
overbright values (>1.125).

/Simon

[Jeremy Selan]

Thanks, I understand now.

It's a tiny bit dangerous to rely on srgb transform invertability for values >> 1.0, as the inversion may give unexpected results. (Basically, any color curves that have very horizontal portions of the transform, when inverted, become highly sensitive the other way. I.e., tiny fractional change in the srgb-like space may make enormous changes in the linearized value).

But if its working for you already, we should definitely continue to support it.  Any I totally understand the intent of having difficulty keying in hdr linear spaces.

I've created an issue to track this:
https://github.com/imageworks/OpenColorIO-Configs/issues/4

I hope to be able to generate an updated profile within a day or two for you to test.
(Or if you have compiled OCIO locally yourself, you can experiment yourself with nuke-default/make.py)

-- jeremy

[Simon Björk]

Thanks Jeremy, I will try to test it as soon as possible.

/Simon

[Jeremy Selan]

I've posted an updated nuke-default profile for testing:
http://github.com/imageworks/OpenColorIO-Configs/zipball/master

if you `setenv OCIO /path/to/new/nuke/default.ocio`, you'll see a new colorspace sRGBf.  This matches the conversion of sRGB, but also includes additional headroom for highlight preservation. Please let me know if this addresses your problem.

-- Jeremy

[Simon Björk]

Hi Jeremy,

I apologize for not getting back you earlier regarding this. In my
opinion, this curve works much better, and I can round-trip my images
without having to worry about clipping.

[Jeremy Selan]

Good to hear, thanks for testing.

-- Jeremy