Page MenuHome

Filmic Looks "None" and "Base contrast" do the same
Closed, ArchivedPublic

Description

System Information

Blender Version
Broken: 6af7d7e

Short description of error

Basically once Filmic its selected the default Look its none, in order to see the base log colors, however None applies a look, and it seem to be the same Look as "Basic Contrast

This is the difference side to side with Troy`s Git version.

Exact steps for others to reproduce the error


1 Open the file on the lastest build
2 Switch to filmic
3 scroll trough the Filmic's "Looks"

None and Base contrast should look identical.

Details

Type
Bug

Event Timeline

Sergey Sharybin (sergey) triaged this task as Confirmed, Medium priority.

@Brecht Van Lommel (brecht), indeed both None and Base Contrast are empty in our ocio.config. Was comparing this to original configuration from Troy, and our None matches Troy's Base Contrast, and None from original config just blows all colors up so not sure it's really helpful. Maybe we can somehow default to Base Contrast for Filmic and remove None?

As I understood the config in blender includes Base Contrast into the Filmic space itself, probably as a hacky way to make it in effect default to Base Contrast and thus improve usability for new users. The 'Base Contrast' option thus becomes a no-op.

This was done intentionally to better follow OpenColorIO design. Applying no look should give a render in sRGB space, not log space like the original config.

If you want to see the colors in log space the is a view transform for that.

I could have left out Base Contrast, but I thought it would be better to keep it since the menu items felt a bit incomplete leaving it out. I think we can change the default to Base Contrast once we make Filmic the default (which we could do in 2.8 right now)?

Base log is useful for a number of reasons, not the least of which is interchange with display referred grading applications.

This was done intentionally to better follow OpenColorIO design. Applying no look should give a render in sRGB space, not log space like the original config.

This is poo. ;)

Using looks to control the output color space clearly goes against OpenColorIO design.

Saving to Filmic Log may be useful in some cases (though I strongly recommend to just save linear EXRs whenever possible), but that should be controlled in another way.

Seriously Brecht? Give your head a shake and look at the original Sony configurations.

The display mean *device*. So given an sRGB display grouping, the views should be designed to target a 2.2 power function display with REC.709 primaries. That is all.

You realize that a look is essentially an aesthetic twist on a base view, which indeed every contrast is within Filmic; an aesthetic variant.

Bear in mind that the BI's last project Agent happened to encode every frame to base log encoding and exported it to Resolve for use with a Resolve acceptable variant of the base contrast.

If you would like I can get a full quote from Sean Cooper at Sony to prove my point, but alas.

Not sure what "none" used to do in the original filmic config but "base contrast" as default makes more sense.
+1 for filmic as default in general :)

The original SPI configs contain no looks, and the docs seem pretty clear to me.

A “look” is a named color transform, intended to modify the look of an image in a “creative” manner (as opposed to a colorspace definion which tends to be technically/mathematically defined)

I'm not disputing the usefulness of saving to log color spaces in some cases, but that's not what looks are for.

gez added a subscriber: gez.Aug 9 2017, 6:49 PM

I'm not disputing the usefulness of saving to log color spaces in some cases, but that's not what looks are for.

Filmic view *is* log (not the same log as blender's though). How come that no look and log appearance is fine for Blender's log view but is wrong for Filmic?
Producing log images (and it's important to understand that there isn't a single log, there are many) is really useful for grading, and it would be even more useful if Blender's DPX export wasn't as broken as it is.

The original SPI configs contain no looks, and the docs seem pretty clear to me.

A “look” is a named color transform, intended to modify the look of an image in a “creative” manner (as opposed to a colorspace definion which tends to be technically/mathematically defined)

What part of aesthetically chosen contrast setting isn't creative exactly?

Let me be clear, the mathematically defined element is precisely the base log encoding. It is the baseline ground truth upon which all of the other elements are constructed. The contrasts are entirely creative, and are most appropriately located under Looks.

To think of this another way, if someone were to use the base log encoding and apply a power function to it via the CDL, and can it into a transform, it would indeed belong inside the Look grouping. In this way, the creative contrasts, given that there are currently seven options, are indeed nothing more than per shot looks.

Anyways, enough bickering on this front. I entirely respect your thoughts on the matter and simply disagree on the organizational front. This might be an issue with the next iteration, but we can discuss this at length when that time arrives.

im not sure about several things i read here, probably need to study more im not the shiniest ball in the jar, so im not going to ask here since this is a bug track not a forum, just want to add some info about the ways that i use or work with this, maybe its a relevant info as a user point of view.

There are three main scenarios that i usually go trough using filmic (Troy`s git):

1/A = Save the full float .exr to send them to my client then them do compositing or I do the compositing in a different blend file.
Here having a look active its useless, is not saved in the .exr so when my client gets my render it gets something different from what i show in a jpg or png or using skyp or whatever, therefore i need to send color space info o tell them to scroll trough his profiles to see if some match etc etc . . . yes its something i need to study more

2/B = Use looks as preview then do grading in the same file.
In this situation i will turn on a look to preview the render, once the render its finished ill load in the compositor the render layer, turn looks to "None" and then manually make the grading using color balance (CDL). If i have some grading like based contrast the result would be redundant.

3/C= its a meh render or quicky for fun.
In this scenario i will render using some look and even use curves in the color management tab to move things a bit, then save to png or jpg and upload to internet because, why not.

Im not sure if im totally wrong here or not, compositing its not my main discipline, but the thing is that having a "None" Look applying something that modifies what the user sees the same as a Look called "Based Contrast" has little to none sense to a user, not to mention trying to explain that to someone that its learning.

Brecht Van Lommel (brecht) closed this task as Archived.EditedAug 9 2017, 8:25 PM

Right, this is more a design discussion than a bug report at this point, closing since I don't think there is anything to be fixed there even if may want to extend/change the design in the future.

In T52311#450670, @gez wrote:

Filmic view *is* log (not the same log as blender's though). How come that no look and log appearance is fine for Blender's log view but is wrong for Filmic?

It's not because there is a log operation as part of the color transform that the resulting image is considered to be in log color space. By selecting "sRGB" as the display device color space the user chooses to output an image in sRGB color space, to be be interpreted as such by any software reading the image. Note that the view transform in Blender 2.79 is not called "Filmic Log", but "Filmic".

To think of this another way, if someone were to use the base log encoding and apply a power function to it via the CDL, and can it into a transform, it would indeed belong inside the Look grouping. In this way, the creative contrasts, given that there are currently seven options, are indeed nothing more than per shot looks.

Ok, so if I understand it what you want to do with None is let the user manually do the transform from log color space to sRGB color space, replacing a step that is normally performed by OpenColorIO? That can be useful, though I don't think it's something that was part of the OpenColorIO design. I think the intention was to either add custom looks or make modifications relative to some base transform.

If you do the transform from log to sRGB using Blender compositing nodes, that same transform can't be replicated in the OpenGL viewport, or in e.g. Maya or Unreal configured with the same configuration file. But the purpose of OpenColorIO is exactly to be able to share the same transforms across multiple applications.

I just discussed this with Sean Cooper to make sure I wasn't losing my mind. Relevant points follow...

It's not because there is a log operation as part of the color transform that the resulting image is considered to be in log color space. By selecting "sRGB" as the display device color space the user chooses to output an image in sRGB color space, to be be interpreted as such by any software reading the image.

Which a log-like transform would be. It is a log-like transform designed to be viewed on a 2.2 power function sRGB (REC.709 primaries) display.

I believe you are focusing too intently on the sRGB OETF / EOTF which I would add are not present anywhere in any of the specifically Filmic transforms pertaining to aesthetic output.

Ok, so if I understand it what you want to do with None is let the user manually do the transform from log color space to sRGB color space, replacing a step that is normally performed by OpenColorIO?

No. There is no "transform from log color space to sRGB color space". Log is not a colour space. Further, the contrasts are purely aesthetic twists that are applied to the scene referred linear data, as designed to be viewed under Filmic's log-like transform. Again, it feels as though you believe sRGB's OETF is somehow mandatory to view things under a 2.2 power function display?

That can be useful, though I don't think it's something that was part of the OpenColorIO design. I think the intention was to either add custom looks or make modifications relative to some base transform.

I just discussed this with Sean Cooper, and his thoughts echo mine. The intention of a Look is precisely as outlined in Filmic, and the base view transform is the log-like Filmic log base.

If you do the transform from log to sRGB using Blender compositing nodes, that same transform can't be replicated in the OpenGL viewport, or in e.g. Maya or Unreal configured with the same configuration file. But the purpose of OpenColorIO is exactly to be able to share the same transforms across multiple applications.

I believe you are confused here? OpenColorIO is designed as a briefcase styled "all-in-one" configuration that can be utilised by all OCIO enabled applications by setting the configuration. It is not a means of defining interoperability across transforms based on a given colour space's or transform's label. Those can and do vary wildly across configurations. Not sure what you are referencing with OpenGL or other such, as OpenGL would be hopeless without the unique configuration in question, including other unique configurations such as ACES.

A case in point here is the shambling shibboleth of Blender's configuration with no real-world practical ground truth in most of the transforms. To expect any behaviour beyond the Blender titled transforms is foolhardy.

Which a log-like transform would be. It is a log-like transform designed to be viewed on a 2.2 power function sRGB (REC.709 primaries) display.

No disagreement here.

I believe you are focusing too intently on the sRGB OETF / EOTF which I would add are not present anywhere in any of the specifically Filmic transforms pertaining to aesthetic output.

I didn't mention the EOTF anywhere. My point was exactly the that you can get output in sRGB color space even when using a log transform, without the sRGB EOTF.

Log is not a colour space.

There are color spaces that can reasonably be named "Log", although there is no single one.

Further, the contrasts are purely aesthetic twists that are applied to the scene referred linear data, as designed to be viewed under Filmic's log-like transform.

With the None look in the original Filmic config, you get a color space transform that is incomplete, it needs an additional contrast adjustment to get good looking results. You can say that adding the extra contrast adjustment to make it complete is just an aesthetic twist, in my opinion it's doing more than that and can actually be considered a transform between color spaces. But that is really just a matter of interpretation and I can see how you might disagree.

I believe you are confused here? OpenColorIO is designed as a briefcase styled "all-in-one" configuration that can be utilised by all OCIO enabled applications by setting the configuration. It is not a means of defining interoperability across transforms based on a given colour space's or transform's label. Those can and do vary wildly across configurations. Not sure what you are referencing with OpenGL or other such, as OpenGL would be hopeless without the unique configuration in question, including other unique configurations such as ACES.

I don't know what "interoperability across transforms" means, I'm talking about interoperability between realtime/offline renders and different applications. Like texture painting an asset in the 3D viewport under the same view transform as the final render, making a fire simulation in Houdini and viewing it with the same view transform as will be used to render it in Cycles, creating assets in Blender to use in Unreal, etc.

Perhaps there could be a look named e.g. "Custom Contrast" that works like "None" in the original config and lets the user add their own contrast adjustment. But using that means giving up interop between realtime/offline and different applications. That may be ok as the final color grading step. Using the "None" look for that purpose can be problematic for interop with other applications like Maya, so I think it should either be a different look like "Custom Contrast" or a separate view transform.

I didn't mention the EOTF anywhere. My point was exactly the that you can get output in sRGB color space even when using a log transform, without the sRGB EOTF.

No. You end up with a nonlinear image that has little to nothing to do with the canonized sRGB colour space. Not even industry standard displays such as the HP Dreamcolor use the sRGB OETF / EOTF in their sRGB emulation mode.

So to reiterate using clear language:

  • A display merely indicates a target destination display. In this case, a display with a _D65_ (x 0.3127 y 0.3290) achromatic colour and REC.709 based primaries, and a 2.2 power function baked into the hardware.
  • You aren't "get[ing] output in sRGB color space" in any classic sense as the sRGB OETF is implicitly missing, and instead the only concern is the native 2.2 hardware implications. Without the full three facets outlined above, it isn't sRGB. (In fact, to properly tag any Filmic image with an ICC for a perfect 1:1, it should be with a REC.709 2.2 ICC as featured in Elle Stone's set, not sRGB.)

Log is not a colour space.

There are color spaces that can reasonably be named "Log", although there is no single one.

As you know, I am a stickler for clarity of language, as most of the colour peeps I know are. There is a good reason for this in that clarity begets clarity.

As per ISO 22028-1 Standard, an RGB colourspace is defined by these mandatory 3 components:

  • Primaries
  • Whitepoint
  • Transfer Functions (OETF and EOTF)

A log-like transform merely addresses the last element, thereby failing to meet the minimum requirements of an RGB colour space according to the ISO. From a technical standpoint, Filmic log encoding base can be defined as an RGB colour space.

With the None look in the original Filmic config, you get a color space transform that is incomplete, it needs an additional contrast adjustment to get good looking results.

False.

You get a log-like transform with a _D65_ white point and REC.709 primaries. For a number of needs, that is a good looking result. ;)

You can say that adding the extra contrast adjustment to make it complete is just an aesthetic twist, in my opinion it's doing more than that and can actually be considered a transform between color spaces. But that is really just a matter of interpretation and I can see how you might disagree.

False.

The contrast is an aesthetic choice and the log-like base is the essence of the transfer function.

Filmic was designed as a creative solution, as such, there is no "canonical" contrast. Viable contrast elements include the seven entry points, a custom CDL, a custom mix of CDL with a contrast, or an entirely custom curve. All are currently present in the wild. The sole common denominator is the Filmic log encoding base.

I don't know what "interoperability across transforms" means, I'm talking about interoperability between realtime/offline renders and different applications. Like texture painting an asset in the 3D viewport under the same view transform as the final render, making a fire simulation in Houdini and viewing it with the same view transform as will be used to render it in Cycles, creating assets in Blender to use in Unreal, etc.

There is nothing out there without a fully colour managed pipeline that will do this. Nothing.

Houdini requires a colour managed pipeline. Unreal has a very specific transfer function from the scene referred domain, as well as unique primaries. As does Unity. As does, well... You get the idea. Without a tightly controlled colour managed pipeline, the idea of interoperability is a complete pipe dream.

Perhaps there could be a look named e.g. "Custom Contrast" that works like "None" in the original config and lets the user add their own contrast adjustment. But using that means giving up interop between realtime/offline and different applications.

False.

I don't necessarily disagree on this consideration. I am merely stating from an "as it exists currently" this is false. It may be a sound idea to add something like this. Haven't thought too much on it, but will.

That may be ok as the final color grading step. Using the "None" look for that purpose can be problematic for interop with other applications like Maya, so I think it should either be a different look like "Custom Contrast" or a separate view transform.

False. You aren't seeing the forest here. Your belief that interoperability exists is a naive one.

In the case of Unreal (4.13+) and Unity (5.6+), as with all modern game engines including Frostbite, they all have moved to wide gamuts and unique transfer functions due to the need to support HDR10 / Dolby Vision encodes and deeper effects / outputs. sRGB is a teeny blip on the long path to interoperability.

No. You end up with a nonlinear image that has little to nothing to do with the canonized sRGB colour space. Not even industry standard displays such as the HP Dreamcolor use the sRGB OETF / EOTF in their sRGB emulation mode.
..
A log-like transform merely addresses the last element, thereby failing to meet the minimum requirements of an RGB colour space according to the ISO.
...
You get a log-like transform with a _D65_ white point and REC.709 primaries.
...
The contrast is an aesthetic choice and the log-like base is the essence of the transfer function.
...
There is nothing out there without a fully colour managed pipeline that will do this. Nothing.
Houdini requires a colour managed pipeline. Unreal has a very specific transfer function from the scene referred domain. As does Unity. As does, well... You get the idea. Without a tightly controlled colour managed pipeline, the idea of interoperability is a complete pipe dream.

I don't disagree with any of this, but it's refuting things I never said.

Your belief that interoperability exists is a naive one.

If we're talking clarity of language, I guess you meant "interoperability does not exist to the extent you think it does". And maybe also "don't worry about interoperability, it will never be good enough"?

Because clearly it does exist to some extent, and is relied on in production, and there are efforts like OpenColorIO and ACES aimed at improving it. Even if it's indeed a mess still.