Filmic profile can use another looks #56986

New Issue

Cenek Strichel · 2018-09-30T20:17:40+02:00

Cenek Strichel commented

2018-09-30 20:17:40 +02:00

System Information
W10 64b

Blender Version
2.79b

Short description of error
You can use custom Look with filmic even it is not possible normal way.

Exact steps for others to reproduce the error

In scene properties set Render: View: to Default
Change look to some Kodak for example
Change Render: View: to Filmic
You will get empty Look:

But it looks like working :)

**System Information** W10 64b **Blender Version** 2.79b **Short description of error** You can use custom Look with filmic even it is not possible normal way. **Exact steps for others to reproduce the error** 1) In scene properties set Render: View: to Default 2) Change look to some Kodak for example 3) Change Render: View: to Filmic 4) You will get empty Look: ![image.png](https://archive.blender.org/developer/F4880474/image.png) But it looks like working :)

Cenek Strichel commented

2018-09-30 20:17:40 +02:00

Added subscriber: @Cenda

Adam Preisler commented

2018-10-12 23:43:47 +02:00

Added subscriber: @AdamPreisler

Adam Preisler commented

2018-10-12 23:43:47 +02:00

Can confirm this and it also happens in 2.8.

However never was a big problem.. Can confuse occasionaly though.

It might be a good idea to remember the Looks for each View Transform. And also Exposure and Gamma when it comes to this tbh.

Should filmic contrast be a "Look" or maybe a value field similar to Exposure and Gamma? Personally the contrast looks that are premade (Very Low Contrast, Base Contrast, High Contrast etc) work great for me.

Not sure here, but Gamma can be used in place of contrast when it comes to Filmic but maybe it only affects the midtones, @troy_s could shed some light when it comes to this I am sure

Can confirm this and it also happens in 2.8. However never was a big problem.. Can confuse occasionaly though. It might be a good idea to remember the Looks for each View Transform. And also Exposure and Gamma when it comes to this tbh. ____ Should filmic contrast be a "Look" or maybe a value field similar to Exposure and Gamma? Personally the contrast looks that are premade (Very Low Contrast, Base Contrast, High Contrast etc) work great for me. Not sure here, but Gamma can be used in place of contrast when it comes to Filmic but maybe it only affects the midtones, @troy_s could shed some light when it comes to this I am sure

Adam Preisler commented

2018-10-12 23:52:30 +02:00

Added subscriber: @troy_s

Troy Sobotka commented

2018-10-13 00:05:19 +02:00

Not sure here, but Gamma can be used in place of contrast when it comes to Filmic but maybe it only affects the midtones.

Generic power functions operate such that they nonlinearly head towards 0.0 and 1.0.

If you think about contrast as being a widening of the spaces between values nonuniformly, this of course would increase contrast on both scene referred linear and nonlinear encodings. However, there are a couple of caveats:

On a nonlinear 0.0 to 1.0 encoding, the "contrast" is being stretch "around" 1.0. This isn't ideal, as most pixel pushers want to control the point about which contrast stretches. In typical terms, this is called the "pivot" or "fulcrum" point.
On scene referred linear encodings, 1.0 doesn't mean anything, so a generic power function (aka crap term "gamma") is also sub-optimal here.
Particular camera rendering transforms (Views) will have particular needs to their mappings. That is, if you apply a generic power function to scene referred encodings, as mentioned above, the values will move in such a way that the intended output code value won't match the need. For example, the Filmic set is designed such that Filmic Base Log encodes scene referred 0.18 to 0.606060. This means that a generic power function will push that "middle grey" value around such that you don't end up with a reasonable middle grey code value at the display.
Given that Filmic is a nonlinear S shaped curve, there's no easy way to parametrically offer it up in the UI.

That about sums up the complexity around ideas of contrast. If you want to experiment with the above concepts, you can perform a fulcrum based contrast adjustment on scene referred data rather easily. In the compositor:

DIvide by the scene referred value you want as the fulcrum. For example, if you want to push contrast but hold middle grey at the input value, divide all of the RGB values by 0.18.
Perform the power function via the CDL.
Return the values back to their proper relative positions by multplying by the input fulcrum value. As per our example, this would be 0.18.

You can of course perform the same fulcrum based contrast around any value, including higher values of 5.0 to 16.0 for example.

> Not sure here, but Gamma can be used in place of contrast when it comes to Filmic but maybe it only affects the midtones. Generic power functions operate such that they nonlinearly head towards 0.0 and 1.0. If you think about contrast as being a widening of the spaces between values nonuniformly, this of course would increase contrast on both scene referred linear and nonlinear encodings. However, there are a couple of caveats: 1. On a nonlinear 0.0 to 1.0 encoding, the "contrast" is being stretch "around" 1.0. This isn't ideal, as most pixel pushers want to control the point about which contrast stretches. In typical terms, this is called the "pivot" or "fulcrum" point. 1. On scene referred linear encodings, 1.0 doesn't mean anything, so a generic power function (aka crap term "gamma") is also sub-optimal here. 1. Particular camera rendering transforms (Views) will have particular needs to their mappings. That is, if you apply a generic power function to scene referred encodings, as mentioned above, the values will move in such a way that the intended output code value won't match the need. For example, the Filmic set is designed such that Filmic Base Log encodes scene referred 0.18 to 0.606060. This means that a generic power function will push that "middle grey" value around such that you don't end up with a reasonable middle grey code value at the display. 1. Given that Filmic is a nonlinear S shaped curve, there's no easy way to parametrically offer it up in the UI. That about sums up the complexity around ideas of contrast. If you want to experiment with the above concepts, you can perform a fulcrum based contrast adjustment on scene referred data rather easily. In the compositor: 1. DIvide by the scene referred value you want as the fulcrum. For example, if you want to push contrast but hold middle grey at the input value, divide all of the RGB values by 0.18. 1. Perform the power function via the CDL. 1. Return the values back to their proper relative positions by multplying by the input fulcrum value. As per our example, this would be 0.18. You can of course perform the same fulcrum based contrast around any value, including higher values of 5.0 to 16.0 for example.

Adam Preisler commented

2018-10-13 00:31:47 +02:00

Thanks Troy! I always enjoy reading a good explanation of such topics. The 7 premade Contrasts for filmic work great it's just that I realized that Corona Renderer has a value input for Contrast so wondered if maybe it's not exposable. Some discussion about it is here: https://corona-renderer.com/forum/index.php?topic=12552.0

Anyway, would it be useful to remember Looks for each View transform? Possibly, but not very necessary to sort out right now.

Thanks Troy! I always enjoy reading a good explanation of such topics. The 7 premade Contrasts for filmic work great it's just that I realized that Corona Renderer has a value input for Contrast so wondered if maybe it's not exposable. Some discussion about it is here: https://corona-renderer.com/forum/index.php?topic=12552.0 ___ Anyway, would it be useful to remember Looks for each View transform? Possibly, but not very necessary to sort out right now.

Troy Sobotka commented

2018-10-13 00:45:47 +02:00

Added subscriber: @brecht

Troy Sobotka commented

2018-10-13 00:45:47 +02:00

I think the Looks implementation is a bit in need of an update for sure. @brecht wisely implemented some rudimentary filtering, which would be likely more ideal via OCIO's families perhaps.

The problem with the Corona stuffs is that a curve doesn't tell the whole story. Specifically, it doesn't tell us:

The input data. Is it scene referred linear? Is it a log of some sort? Is it something else? What colour space?
The output data. What is it intended for?
Why the given shape?

With Filmic, these answers are pretty clear:

Filmic's "base" starting point is a Filmic Log Encoding, which assumes REC.709 primaries and covers -10 to +6.5 stops centred around 0.18 as a middle grey value.
The chain is three parts essentially:
The conversion from scene referred linear zero to infinity values to the Filmic Base Log range, encoded in a generic normalised log2. Middle grey ends up mapped to code value 0.606060 on the normalized 0.0 to 1.0 scale.
A sweetener to gracefully desaturate to roughly hold chromaticity axis between the intended ratio colour and the white point. If you don't do this, no amount of transfer curve mapping will salvage the intended colour value.
The conversion from Filmic Base Log to a contrasted version via an S shaped curve. This handles the roll off and the angle of slope. Angle of slope is contrast in a log encoding. Finally, it also handles remapping of the log middle grey value to the display's output middle grey-ish values. Specifically, it maps 0.606060 to 0.5. 0.5 was chosen as a simplified balance between optimal display output (0.18^1/2.2) and ease of comprehension for folks unfamiliar (0.5 as a mental model).
The output assumed is either sRGB with a native 2.2 power response as per the vast majority of sRGB displays, or Apple DCI-P3 displays if you are using the development branch of Filmic.
The S curve shape is the typical log-like encoding from photographic film emulsion.

Corona's approach is some sort of homebrew parametric. Judging from the shapes, they aren't telling you what the dynamic range is of the shaper transform that woudl come before that S shaped curve. We can estimate that the range of stop values up and down from middle grey is roughly equal though, as the centre point along X is roughly the centre point along Y. Without knowing those details though, it's silly to speculate as folks are in that thread. You could also end up with wonky results if a parametric approach doesn't have some form of constraints.

I think the Looks implementation is a bit in need of an update for sure. @brecht wisely implemented some rudimentary filtering, which would be likely more ideal via OCIO's families perhaps. The problem with the Corona stuffs is that a curve doesn't tell the whole story. Specifically, it doesn't tell us: 1. The input data. Is it scene referred linear? Is it a log of some sort? Is it something else? What colour space? 1. The output data. What is it intended for? 1. Why the given shape? With Filmic, these answers are pretty clear: 1. Filmic's "base" starting point is a Filmic Log Encoding, which assumes REC.709 primaries and covers -10 to +6.5 stops centred around 0.18 as a middle grey value. 1. The chain is three parts essentially: 1. The conversion from scene referred linear zero to infinity values to the Filmic Base Log range, encoded in a generic normalised log2. Middle grey ends up mapped to code value 0.606060 on the normalized 0.0 to 1.0 scale. 1. A sweetener to gracefully desaturate to roughly hold chromaticity axis between the intended ratio colour and the white point. If you don't do this, no amount of transfer curve mapping will salvage the intended colour value. 1. The conversion from Filmic Base Log to a contrasted version via an S shaped curve. This handles the roll off and the angle of slope. Angle of slope is contrast in a log encoding. Finally, it also handles remapping of the log middle grey value to the display's output middle grey-ish values. Specifically, it maps 0.606060 to 0.5. 0.5 was chosen as a simplified balance between optimal display output (0.18^1/2.2) and ease of comprehension for folks unfamiliar (0.5 as a mental model). 1. The output assumed is either sRGB with a native 2.2 power response as per the vast majority of sRGB displays, or Apple DCI-[P3](https://archive.blender.org/developer/P3.txt) displays if you are using the development branch of Filmic. 1. The S curve shape is the typical log-like encoding from photographic film emulsion. Corona's approach is some sort of homebrew parametric. Judging from the shapes, they aren't telling you what the dynamic range is of the shaper transform that woudl come before that S shaped curve. We can estimate that the range of stop values up and down from middle grey is roughly equal though, as the centre point along X is roughly the centre point along Y. Without knowing those details though, it's silly to speculate as folks are in that thread. You could also end up with wonky results if a parametric approach doesn't have some form of constraints.

Adam Preisler commented

2018-10-13 01:07:39 +02:00

Thanks for further clarification. I see that there is a lot of underlying complexity and personally I don't need a parametric slider because the 7 presets work just great and at least no need to have random "on a whim" values like 1.5123 in the slider...

I dug around to show you how it works from a pixel pusher's perspective because maybe with your knowledge you can guess it but it's more for your curiosity. One setting that I miss in Blender which comes to mind is the "Highlight Compress" shown at 12 seconds into the video.

https://www.youtube.com/watch?time_continue=1&v=FLkltjN6Ld4

Thanks for further clarification. I see that there is a lot of underlying complexity and personally I don't need a parametric slider because the 7 presets work just great and at least no need to have random "on a whim" values like 1.5123 in the slider... I dug around to show you how it works from a pixel pusher's perspective because maybe with your knowledge you can guess it but it's more for your curiosity. One setting that I miss in Blender which comes to mind is the "Highlight Compress" shown at 12 seconds into the video. https://www.youtube.com/watch?time_continue=1&v=FLkltjN6Ld4

Troy Sobotka commented

2018-10-13 01:18:52 +02:00

Highlight compression is the distance between the peak of the linear section of the curve and the terminating value. It's probably something that loosely controls the shape of the curve or the range of values.

It's not really an issue with Filmic as the values are fixed . The range Filmic uses is something roughly akin to traditional photographic emulsion. The rate of change between the linear-ish portion of the Filmic curve and the terminating point is essentially a byproduct of the slope. Adjusting it would probably lead to some wonky looking results.

You can see from the Corona demo you linked that they are missing some critical aspects as the sky starts fully saturated cyan, which is a telltale sign that the camera rendering transform is broken.

Highlight compression is the distance between the peak of the linear section of the curve and the terminating value. It's probably something that loosely controls the shape of the curve or the range of values. It's not really an issue with Filmic as the values are fixed . The range Filmic uses is something roughly akin to traditional photographic emulsion. The rate of change between the linear-ish portion of the Filmic curve and the terminating point is essentially a byproduct of the slope. Adjusting it would probably lead to some wonky looking results. You can see from the Corona demo you linked that they are missing some critical aspects as the sky starts fully saturated cyan, which is a telltale sign that the camera rendering transform is broken.

Adam Preisler commented

2018-10-13 02:05:07 +02:00

Good to read:)

Tbh the problem here is so minor that I don't think it's necessary to fix but could be good to remember Looks depending on View Transform.

I always use Filmic for all my renders with only adjusting exposure and Contrast but when it comes to rendering out normal maps through Viewport OpenGL grabbing (using the normalmap matcap) I tend to use Default and None but it's not exactly right of course but haven't used it enough to care as my current methods are fine for my uses.. Would be immensly helpful to show true normal matcap colors escpecially though..

Good to read:) Tbh the problem here is so minor that I don't think it's necessary to fix but could be good to remember Looks depending on View Transform. I always use Filmic for all my renders with only adjusting exposure and Contrast but when it comes to rendering out normal maps through Viewport OpenGL grabbing (using the normalmap matcap) I tend to use Default and None but it's not exactly right of course but haven't used it enough to care as my current methods are fine for my uses.. Would be immensly helpful to show true normal matcap colors escpecially though..

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Filmic profile can use another looks #56986