Filmic Looks "None" and "Base contrast" do the same #52311
Labels
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
10 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#52311
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
System Information
Blender Version
Broken:
6af7d7eShort 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
mono film.blend
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.
Changed status to: 'Open'
Added subscriber: @NahuelBelich
Added subscribers: @brecht, @Sergey
@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?
Added subscriber: @angavrilov
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)?
Added subscriber: @troy_s
Base log is useful for a number of reasons, not the least of which is interchange with display referred grading applications.
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.
Added subscriber: @irfancelik
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.
I'm not disputing the usefulness of saving to log color spaces in some cases, but that's not what looks are for.
Added subscriber: @SteffenD
Added subscriber: @GuillermoEspertino
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.
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.
Changed status from 'Open' to: 'Archived'
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.
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".
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...
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.
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?
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.
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.
Added subscriber: @JoniMercado
No disagreement here.
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.
There are color spaces that can reasonably be named "Log", although there is no single one.
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 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.
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:
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:
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.
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. ;)
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.
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.
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.
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.
I don't disagree with any of this, but it's refuting things I never said.
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.
Added subscriber: @RainerTrummer