color management with s-shaped curve tonemap

[sharktacos]

The OCIO spi-anim adds an s-shaped contrast curve to the standard sRGB gamma 2.2. An s-shaped curve emulates the toe and shoulder of film and looks nice. This can be done by using the OCIO option in the VFB (for the render), together with the VrayOCIOtex on all the diffuse textures. Works great.

So that got me to thinking: Another way to do an s-shaped contrast curve at the end of the render would simply be to use the curve CC in the VFB, adjusting the curve as desired. This could be written out from the VFB as a LUT to be used in Nuke. Cool.

However, as stated above, this contrast curve would also need to also be inversely applied to all the diffuse textures (in addition to the inverse gamma). This is where I get stuck, and my question comes in:

How could I inverse this S-shaped contrast curve made in the VFB, and apply it in Vray to the diffuse textures together with the degamma?

I suppose I could write out a .cube file LUT of the curve and read it this into a VrayOCIOtex set to fileTransform. However the inverse option does not work in this case. I believe I need to actually swap the X & Y on each curve point to invert it, but I'm not sure how to likewise change the tangent directions on those curve points to invert them.

[vlado]

I don't think you are supposed to apply the (inverse) S curve on the textures...

Best regards,
Vlado

[sharktacos]

I was basing this on this paper (by the guy who wrote OCIO).

"Thus, a common solution is to utilize an “inverse tone rendering,” to back convert display-referred imagery to a hypothetical scene-referred space. Conceptually, the texture artist is painting the tone rendered appearance of the texture, not the texture itself. There are a few challenges with this conversion from display-referred to scene-referred space. First, the tone rendering may not be invertible, particularly when filmic 3D-LUTs are used for image preview. Second, traditional “s-shaped” tone renderings have very horizontal portions of the curve, which when inverted result in very steeply sloped transfer functions. This steep contrast has the effect of amplifying small changes in input code values. For example, a steep inverse could result in the situation where a single code value change in a painted texture could correspond to a delta of a stop or more of scene-linear light. This sensitivity is very challenging for artists to work with.

A common solution to both of these issues is to be a bit more modest in our goal of perfectly inverting the display transform. Simplifying the problem, we can instead aim to create an approximate 1-D inverse, tuned to be well behaved both in terms of color performance and dynamic range. Of course, as a consequence of this simplification the texture painting is not be truly WYSIWYG. Thus, a residual “difference visualization” 3D-LUT is crafted for accurate color preview in the texture painting tool."

I took the above to mean that they were attempting to invert both the gamma (which is of course simple) and also invert the s-shaped tone curve (which presents some challenges which he addresses above). Do you understand the above to be saying something different?

[sharktacos]

I also note that when a VrayOCIOtex node is applied to the diffuse textures, set to "colorspace" mode with the "in" set to dt16 and "out" set to Inf, this is clearly not simply doing an inverse gamma operation. That is, the result is visually noticeably different from an inverse gamma. Not sure what is going on under the hood there, but I had assumed it was the application of the inverse s-curve...

[jasonhuang1115]

Hey sharktacos, just wondering if you have come to a conclusion on this part of the workflow for texture painting or still digging the proper way to implement the idea? If yes, I'd love to learn what you have found out.

[sharktacos]

It is possible to use an OCIO conversion in programs like Mari, but it's quite a pain to get working in Photoshop since it's not linear. Since I didn't really see a huge difference in the resulting textures, I am currently still just doing a simple degamma on the textures, and viewing them with an OCIO config in the render and comp.

[joconnell]

Yep, don't apply a curve to the textures. If you think of how a camera is working, it's a linear sensor shooting physical light which works in linear physics. Both film with its toe and shoulder and digital cameras with their look curve to make a nice image / emulate film are just added on to the look of the final image as a viewing thing. In work all the textures get painted in mari in rec709 these days and then we use vrayocio to go from rec709 to linear inside of max. We render linear and use the ocio lut in the frame buffer to go from flat linear to something that looks more like film / the wanted end look.

That paragraph you quoted is just using new terminology for the process of taking whatever camera raw files you get and turning them into linear. Scene referred is just the real world, display referred is something that's got a curve baked in like srgb or rec709 so if you've been given display referred footage (lets even take a jpeg from your stills camera) all you're doing is finding a curve / gamma value or lut to strip off the curve and go back to linear / scene referred.

[jasonhuang1115]

Thanks sharktacos and John. It's great to get a sense of how you guys work on the texturing end of this workflow. Yeah, I am not too bothered by Photoshop, but John's tip regarding Mari is interesting...
joconnell , I haven't paid much attention to Mari's view transform and OCIO config in it. I have used Mari for some years but have just used a typical sRGB lookup. Any pointer that I can read more on painting textures in rec709 in Mari? Why choose rec709 over sRGB? (maybe has to do with the plate being in rec709?)

[joconnell]

I'll check with the painters as to why - they both seem to be pretty similar.

[jasonhuang1115]

Great! Please keep me posted if you find out why.

[sharktacos]

My understanding is that rec709 is intended for a TV display whereas sRGB is for a computer monitor. So it doesn't really make sense to use rec709 when working on a computer monitor. The only thing I can imagine is that rec709 is used because the artist feels it "looks nice." In other words, they are trying to do something similar to a film emulation curve, but using a display transform to do it.

Conceptually I think it is best to use the correct display transform for the viewing device, and apply whatever film emulation curve that is artistically desired before that. That way you can be assured that the look you want will work on whatever the final output medium you want.

[joconnell]

Oh hey!

Yep, it's rec709 since they're using hdtv as a target but they're pretty much the same for a computer monitor. Remember back in the calibrating to gamma 2.2 days? 2.2 was kind of an average number that most monitors could achieve so it was a good coverall. Rec709 is pretty much the same thing, only a slightly different mid point so you can go with either.

[jasonhuang1115]

hmm...interesting. I'll dig around to see how to do that in Mari.Do you have a screenshot of the setting or it's a workflow that's more involved than some color management settings in Mari preference?

[joconnell]

I don't think it's anything bananas Jason, textures are rec709 from there into linear (acescg in our case but it's just linear).

[sharktacos]

Have you had good results with ACES? Last I checked there was a pretty major bug with using ACES with CG that resulted in it doing really yucky things to saturated colors.