tonemap and s-curve

[Derek Flood]

Am I correct in understanding that the spi-anim and spi-vfx OCIO configs apply both tonemapping as well as an s-shaped contrast curve to the view transform? If it is doing tonemapping, is it using Reinhard tonemapping on RGB values, or something else? Where does the tonemapping happen in the config exactly, is it in one of the LUTs?

A concern I have is that tonemapping can cause an image that should be blowing out to instead lower the values to fit inside the 0-1 range resulting in an image that looks "tonemapped" instead of looking like a photo. So I was wondering if it may be better to disable to tonemapping function and instead use the exposure controls of the physical camera in the render (in this case Vray).

Hope that all makes sense. I'm an artist rather than a tech person, so this all hurts my brain a bit.

[Troy Sobotka]

On Sun, Jul 2, 2017 at 3:58 PM Derek Flood <dere...@gmail.com> wrote:

Am I correct in understanding that the spi-anim and spi-vfx OCIO configs apply both tonemapping as well as an s-shaped contrast curve to the view transform? If it is doing tonemapping, is it using Reinhard tonemapping on RGB values, or something else? Where does the tonemapping happen in the config exactly, is it in one of the LUTs?

I will assume you are using the sRGB view transform grouping.

If you examine the actual configuration https://github.com/imageworks/OpenColorIO-Configs/blob/master/spi-vfx/config.ocio#L23-L26 you will see that there are three views listed.

If you choose the Film view transform, and analyse the stanza that defines it https://github.com/imageworks/OpenColorIO-Configs/blob/master/spi-vfx/config.ocio#L231-L243 you will see that it is a two part transform that goes from a lg10 transform to the sRGB OETF. This means that there is a compression element via the lg10 transform, then the typical tone / transfer curve defined within the sRGB OETF specification.

The lg10 transform has a peak value of 64.0 scene referred linear (https://github.com/imageworks/OpenColorIO-Configs/blob/master/spi-vfx/luts/lg10.spi1d), and assuming the sRGB OETF is the canonical one, middle grey lives at around 0.2. That means there is about 8.32192809 stops[1] above middle grey compressed into the spi-vfx Film and Log views, with the former having the 'aesthetic' sRGB OETF applied on top.

This in turn answers your second question; no it isn't Reinhard, but rather the generic sRGB OETF transfer function that defines the aesthetic portion of the curve.

A concern I have is that tonemapping can cause an image that should be blowing out to instead lower the values to fit inside the 0-1 range resulting in an image that looks "tonemapped" instead of looking like a photo. So I was wondering if it may be better to disable to tonemapping function and instead use the exposure controls of the physical camera in the render (in this case Vray).

As far as I understand things, this is an incorrect statement.

The scene referred domain places no special meaning on the value 1.0. That means that the idea of something "blowing out" is specifically bound to the display referred transform.

The SPI set is a historical set now I believe, but Sean Cooper can speak to this more accurately.

With respect,

TJS

[1] Assuming my math isn't entirely broken and one pegs the middle grey value at 0.2 scene referred linear.

[Derek Flood]

Thanks Troy, that's helpful. I took a look at the parallel stanza in spi-anim config and see that it is called vd16.

I could not find any documentation of spi-anim, but assuming that its vd16 is the same as the spi-vfx vd16, I see here that it says "The dynamic range of the vd is limited to around 2.5 stops above diffuse white... The last part of the transformation is a matrix transformation that moves the whitepoint of film to look correct when displayed with a d65 whitepoint."

I'm not sure I understand what that means exactly, but I think it may be something similar to the description for the srgb8 view transform where it says that the last step of the transform is that  "the grey balance and white scaling compensation are applied." which I understand to mean that it is remapping the values to fit into the 0-1 sRGB display rather than clipping values over white like a traditional sRGB 2.2 transform would do.

One difference I did notice is that while it says that for the srgb8 "the lut is scaled so that at least one of the color channels on maximum white uses the display max" in contrast for vd16 it says "It is undesirable to map the vd max to the linear max. Such a conversion results in linear values are almost never what an artist intended. The rule of thumb is that, at the high end, single value deltas in an 8 bit image should never create over a half stop of additional linear light. The vd conversion curve is limited to prevent this case."

So does that mean that the vd16 would scale things always below white? I can see how it could be desirable for textures to sit above 0 and below 1, but not for the display transform of a render. Am I just misunderstanding standing what this means perhaps? In a test I did, it did look like the whites were being displayed below 1 for spi-anim, so I'm trying to figure out what may be going on. I'll post an image of this once I'm back at work.

[Sean Cooper]

Hey guys, 

This reply might be a bit brief as Im writing it on transit. 

So a couple things, yes vd[16,8] is two things: a global tone mapping with a s-shaped "film" curve, and a gamma encoding for direct display to a BT.1886 output device. This curve compresses 0.0 to ~4.43 in render linear to 0-1 display drive values. So that means 1.0-4.43 will be the compressed highlights above diffuse white (1.0),and anything higher than 4.43 will clip. 

I cant really speak to spi-vfx since ive never used it in practice. 

Ill loop back when im back at work on Tuesday. 

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Troy Sobotka]

On Sun, Jul 2, 2017 at 7:41 PM Derek Flood <dere...@gmail.com> wrote:

So does that mean that the vd16 would scale things always below white? I can see how it could be desirable for textures to sit above 0 and below 1, but not for the display transform of a render. Am I just misunderstanding standing what this means perhaps? In a test I did, it did look like the whites were being displayed below 1 for spi-anim, so I'm trying to figure out what may be going on. I'll post an image of this once I'm back at work.

It sure sounds like the LUT transforms are betraying the descriptions you posted; they aren't nearly as complex as what those passages might suggest.

I've attached a simple line graph of the vd16 LUT. Note that the anim configuration doesn't have an aesthetic curve on top of the good old log-like curve.

Also, looking at the values, the vd16 transform indeed doesn't map to a value any higher than 4.4350049720132239. That would mean that picking value 1.0 from the transform would yield that value in scene referred. This would be lower than say, the peak output of the spi-vfx "Film" transform or the lm16 "Log" transform in spi-anim.

TL;DR: The "Film" viewing transform would ignore values around that 4.435 value above. The "Log" transform goes up to 16.0, which is lower than the two display referred view transforms in the spi-vfx set. I haven't done the math to see where middle grey gets mapped to in the transform.

With respect,

TJS

[Derek Flood]

Troy what is the program you are using to view the LUT with? Looks like a useful tool

[Derek Flood]

Sean, thanks for that info about the tonemapping, that's quite helpful. I need to do some more tests, but I think I'm better understanding what's going on and how best to work with this. I'll keep plugging away...

To unsubscribe from this group and stop receiving emails from it, send an email to ocio-users+...@googlegroups.com.

[Troy Sobotka]

On Mon, Jul 3, 2017, 10:50 AM Derek Flood, <dere...@gmail.com> wrote:

Troy what is the program you are using to view the LUT with? Looks like a useful tool

Google Sheets with a simple chart. Any spreadsheet will do it.

Might I ask what you are attempting to do and why you have chosen the rather dated SPI configuration?

With respect,

TJS

[Derek Flood]

On a related note, I'm seeing a really odd behavior with the ACES 1.0.1 config. 

Note in the attached images how the highlight on the blue sphere gets extra large as the exposure is raised 

(the same happens when the light intensity is raised).

Any idea what might be going on with that?

[Derek Flood]

Might I ask what you are attempting to do and why you have chosen the rather dated SPI configuration?

Just trying to use an OCIO color pipeline. The SPI configs ship standard with Nuke, along with ACES, so from a user perspective I did not see these as "dated" since this what is commercially shipped with the software we use (Nuke & Maya).  Overall, spi-anim seemed like an ideal  candidate for a CG animation pipeline (as opposed to a VFX pipeline). Is there some other config that you would recommend instead?

[Derek Flood]

Sean, is is possible to create a part of the vd16 LUT with ociobake? For example, would it be possible to use ociobake to write a LUT with just the film emulation or just the tone mapping? 

I'm thinking that the answer to this is "no" since it looks to me like ociobake uses the OCIO config to define the input and output color space.

Would there be another way to do what I am after?

On Sunday, July 2, 2017 at 8:43:24 PM UTC-7, Sean Cooper wrote:

To unsubscribe from this group and stop receiving emails from it, send an email to ocio-users+...@googlegroups.com.

[Troy Sobotka]

On Mon, Jul 3, 2017, 6:10 PM Derek Flood, <dere...@gmail.com> wrote:

Sean, is is possible to create a part of the vd16 LUT with ociobake? For example, would it be possible to use ociobake to write a LUT with just the film emulation or just the tone mapping? 

vd16 is purely that log-like transform in the diagram I attached.

Curious where you are seeing an aesthetic curve in it. Is it possible you are looking at the DCI-P3 view transform?

I'm thinking that the answer to this is "no" since it looks to me like ociobake uses the OCIO config to define the input and output color space.

Would there be another way to do what I am after?

See above. It seems to be a pretty vanilla compression transform?

With respect,

TJS

[Derek Flood]

Troy, have you tried applying the spi-anim OCIO config to an image in Nuke or some other program? 

[Sean Cooper]

Certainly there are some aspects of the spi-anim config that are a bit dated, its perhaps not as much of a "contemporary" workflow for facilities on the bleeding edge of color pipelines, though the ACES configs work towards that. But I can say apart from the utility spaces (log, delivery specs, etc.) the heart of the config still sees life on our animated feature films.

With regard to your statement Derek,

write a LUT with just the film emulation or just the tone mapping

The first answer is no, you'd have to modify the config or create an external LUT that ociobakelut could ingest. More importantly, I'm not following your logic. From your perspective, what do you think is the film emulation, and what is the tone mapping? In a general sense, "Film Emulation" is a subset of tone mapping, it "maps" the "tonality" of linear light (from shadow to blazing sun) to be shown on your monitor. This can be done in a "filmic" way that tries to emulate the behaviour of chemical film, or not.

You could be referring to the two different stages of mapping, first being the "aesthetic" tone curve that defines the filmic tone mapping, and second being the translation of this to display drive values (gamma encoding).

This is where your plot is somewhat misleading Troy, you're plotting display "drive value" (normalized 0.0 - 1.0 signal directly driving the display electronics) versus linear light. I'll match the plot here just to show I'm using the same LUT.

Plotting the same data with a logarithmic x-axis results in this, which shows the sigmoid/film/s-shaped curve that is typical of "film emulation" tone-mapping.

After all of that Derek, I'm just not certain what aspect you are unhappy with, and what you're trying to accomplish in general. From your first statement "an image that should be blowing out", implies that you're not used to working with a tone mapped viewing transform where linear values >1.0 still get mapped to unique display values. If that is the case, then I would suggest sticking with the Nuke default config as I believe that will match the behaviour you expect.

​

--

You received this message because you are subscribed to the Google Groups "OpenColorIO Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ocio-users+unsubscribe@googlegroups.com.

[Derek Flood]

Sean,

On Tuesday, July 4, 2017 at 10:57:24 AM UTC-7, Sean Cooper wrote:

You could be referring to the two different stages of mapping, first being the "aesthetic" tone curve that defines the filmic tone mapping, and second being the translation of this to display drive values (gamma encoding).

I was referring to what I understand conceptually as the two purposes of the curve

First: an aesthetic purpose which gives the pleasing "toe and shoulder" contrast of the s-shaped curve emulating a camera's film response, as opposed to the sRGB transform which does a simple gamma shift.

Second:  Remaping brighter values to allow for artists to give real world values for the lights. This is in contrast to clamping values above 1 as a traditional gamma 2.2 curve does which leads  lighting artist trying to compensate for this, thus making the lights dimmer so they fit into the 0-1 range and do not clip. That however means that the lights are set dimmer then they would be in the real world which in turn results in less GI light bounces, and overall a render that is not using real world light values which modern physically-based renderers need to work properly. When the scene is instead viewed through a better camera response as the lights are being set up (both with a film emulation curve and tone mapping), the lights can be set up in a way that mirrors real world light values.

Where I may have been mistaken is I had assumed that these two purposes (s-curve + remapping brights) were separate functions (or phases as you call it), but if I understand correctly you are saying that the s-shaped curve gives both the aesthetic toe and shoulder and at the same time remaps the brights, and thus together constitute the first phase, while a gamma encoding constitutes the second phase. Is that correct?

 

After all of that Derek, I'm just not certain what aspect you are unhappy with, and what you're trying to accomplish in general. From your first statement "an image that should be blowing out", implies that you're not used to working with a tone mapped viewing transform where linear values >1.0 still get mapped to unique display values.

I think this amounts to an PEBKAC error on my part. I was looking at the images in Vray (Maya), Nuke, and Photoshop, and Photoshop was doing something to change the values making the images have incorrect brightness values. When I instead examined things only in Maya and Nuke everything with spi-anim responded as expected. So I am not unhappy with anything about spi-anim actaully.

I also want to say that I have found both your and Troy's input extremely helpful in understanding what's going on under the hood better. As an artist working with this, this is really helpful. In the end what I "want" is simply to have a functional understanding of the technology so I can work well with it. So I really want to stress how helpful your responses are. I am learning a ton, thank you.

If there is at this point anything I am "unhappy" about it is ACES, which as I noted above appears to have problems with blue highlights that I have not been able to resolve...

[Derek Flood]

Also regarding ACES vs. spi-anim, a behavior that I am also interested in is how saturated material colors become gradually desaturated as the exposure is raised on a render, which emulates the behavior in cameras. This is discussed in this video by Alex Fry from Animal Logic (about 10 minutes in). It's interesting to me that in the video, Alex Fry says that this behavior is achieved in ACES, but not in spi-anim. I wonder if you could comment on that Sean? Is this correct?

In comparing Vray renders viewed in both ACES and spi-anim I was not able to observe this, but this may be because of the implementation in Vray which only applies a view transform at the end, rather than changing the internal spectral color space for stuff like light color temperature, sun&sky, dispersion etc. to transform it into ACEScg.