Does Filmic automatically correct gamma (like, e.g. sRGB does), or is the default value of 1 to be amended to 1.8 (on Mac) or 2.2 on Linux/Windows?
I ask because I have an indoor scene (my go to test scene) which seems rather dark unless I set Filmic Gamma to 2.2, and then it’s as expected.
Struggling to find any documentation.
I should add - trying to figure out if it’s the lighting at fault, or the gamma.
Occam’s razor mode:
Have you tried to increase the lights energy values?
Most of the light is from an HDRI (A proper one, not a jpg) which is at an intensity of 40 for illumination, and 1 for visibility through the windows. And yes, there are portals in place to direct the light.
And a single sun lamp for the sunbeams.
So yes, the energy values are ample (If I make the visible HDRI the same value it’s almost totally blown out).
Very hard to guess given the limited info. I’ve never used any gamma stuff, and I’m guessing it boils down to lighting and/or materials since I haven’t seen this mentioned by others. Not sure I would be able to help, but it would be easier with a stripped down scene (with textures) to experiment with.
Maybe the albedo values in your materials are a bit too low (I know that values like the default of reflecting 80 percent of light received is generally too high), but you usually might not want to send them into the basement either.
There’s not a direct correlation between the numbers you’re giving and your “energy values are ample”.
1, 40 or 3000 means nothing.
For example if you rotate around your HDR map you’ll have different exposures on your shot with the same energy values.
Take a look at this thread and specifically at this post for useful info about filmic and exposure tricks with false color metering.
Ace is kinda right. Use a cheat sheet to obtain albedo values/colors for your materials. However, unless you rely on caustics (most turn it off due to noise), you may want to compensate for the lost energy with a light path/isDiffuse to blend with a pure diffuse shader. It’s not going to be correct as caustics would be (especially on smooth specular), but it helps prevent energy loss.
Also, if using “real/absolute” values for sun&sky stuff, you have to use exposure control in color management. The photograph/camera (?) addon can help you dial in light values if you want to work in reverse and preset an exposure (i.e. interior lighting, bright outdoors etc) and dial in the lighting from there. You may also want to have a look at this.
Thanks, all. I hadn’t thought of faking the diffuse to avoid energy loss, and something I’ll certainly start experimenting with.
I’ll also try a different hdr. A quick test suggests that the one I’m using may have a very uneven and less illuminating ambient light (although the hdr sun is fine). The problem with this is that I have the real sun matched to the hdr, but I should be able to get close enough. I’ll see what’s lurking at HDRI Haven that will serve as a suitable replacement.
I may also try using the HDR with a color ramp to influence a flat background shader for ambient light (I know it will crush the hdr, but that shouldn’t be a big problem).
I guess the answer to the specific question is that with filmic, a gamma of one should already be optimal? Do we know whether this translates to 1.8 or 2.2?
Thanks once again. Stuff to test 
Filmic ‘looks’ like ‘Base Contrast’ or ‘Medium High Contrast’ are like gamma curves. You should not touch gamma settings. If it’s dark in the scene you should increase the amount of light or exposure(which is the same as increasing all the lights). It’s perfectly normal for the HDRI used in an interior scene to be blown out if viewed directly. That’s what happens in the real world - if you photograph an interior and then go outside with the same camera settings, pictures are completely white if it’s a sunny day. Make sure the materials are correct, use Reflective Casutics at least and increase the light. It doesn’t matter what number it is. Filmic is different than default. If it’s 200 that you need for enough light then it’s 200, if it’s 1000, then it’s 1000 - does not matter at all.
Gamma is a power function, filmic contrast looks are simple sigmoid functions (classic S-shaped curves you apply to increase contrast) “mapped” on filmic (18%gray as mid gray).
Gamma 2.2 is already and always applied as a display transform (Display tab sRGB, Rec709…), the gamma slider is in blender just if you need an extra gamma correction and should not be used.
Another thing that could make your interior render darker is clipping expecially indirect at very low values. In internet there are old tutorials about “noise reduction” that use to promote clipping as a holy grail in noise reduction but they don’t explain how much destructive clipping is and how it works.
Told this, I think we’re going blind in this thread tryin to guess where your problem is.
I keep my guess on lighting setup, but if you don’t post at least a pic we’re going nowhere.
Thank you LazyVirus. That answers my question regarding the gamma value.
There is no clipping applied. However, I’ve made progress. I replaced the HDRI (and, in fact, have turned the sun off for the moment since the HDRI sun is providing what I want). I’ve also increased diffuse bounces from 1 to 2, and after playing with exposure, have enabled the real camera with AE and an EV of 0.5, It’s starting to look something like what it should.
There was also a modelling problem that I hadn’t noticed since it was off camera, and I usually work in wireframe mode when not in camera view, but I used the Archpack plugin to build the walls and windows etc. Seems some of the booles failed, so effectively, some windows were boarded up. Changing the booles from carve to bmesh has fixed this.
I need to do a decent quality render to fully test my settings, but that will have to wait until later when I don;t actually need the PC.
Nevertheless, early tests are lookign promising, and I’ve learned a few things on the way.
Thank you to everyone that’s replied.
Am I getting this wrong? sRGB is not the same as gamma 2.2 that is only approximately similar to actual sRGB curve. The more accurate version of what I meant to say would be - all the needed transforms are applied with filmic and the looks so gamma slider there has no purpose at all with filmic. I thought sRGB/REC709 is applied together with the look transform, not gamma curve that we would get with power of 2.2.
Anyway, it seems we most definitely agree the gamma slider should be left alone.
This is anachronistic lore. macOS uses the canonized sRGB transfer functions (IE the sRGB OETF) across the board now, even on their late 2015+ DCI-P3 displays. 1.8 power functions have long since been dead. By “long since dead”, the 1.8 power function was dropped in OSX Snow Leopard 10.6, circa 2009.
To make things (hopefully) clear…
The default Blender colour management configuration is a Lovecraftian shibboleth filled with poor terminology, broken transforms, among other problems.
When one selects a “Display”, one is selecting the colorimetric response of the Display listed. In the Filmic configuration, this is very clearly listed as sRGB 2.2 power function hardware. This means that all views are designed for that particular idealized display.
Sadly there is quite a bit of confusion on the part of the developers, and the terminology in the official configuration, as well as the design understanding of OCIO, leaves a little bit to be desired. Hence the vague “sRGB” title and “Default” show up in the configuration, which leads down these confusing paths as we can see above.
The TL;DR is that under OCIO, “Display” selects the idealized display colorimetry and response of the type of display in question. For Filmic, this is an idealized sRGB display with a 2.2 power function in hardware. All Views and Looks are designed for that idealized display. If one’s particular display deviates from that (EG Apple P3 or otherwise) one would require alternate Views and Looks designed.
[Happy to answer any other questions. I am a little leery of the term “gamma” as it tends to make folks more confused than they should be, and worse, it is used in improper ways all over. For those interested, to cut through the loads of rubbish out there, the transfer function of a hardware display is a matter of encoding needs, not perception. That is, the transfer function in typical sRGB display hardware is a pure 2.2 function at the hardware level. This is a means of compression that cheats the encoded values in a mostly imperceptible manner, so that less bandwidth can be used to get something to the display. That is, the values end up nonlinearly encoded on the software side, are fed to the hardware which then decodes the encoded values back to physical linear light emission output that your display is capable of. Many people get confused and think that they are nonlinearly encoded for our perceptual system, which is a horrible misunderstanding; the nonlinear encoding is always undone back to physical linear output and the perceptual link is simply a compression / bandwidth hack / design optimization.]
So what transforms are applied using filmic? If display device is sRGB is it a simple power function of 2.2 or is it really a bit more complicated as sRGB color space has a small segment of linear values near black as described here? Is the look applied first and then sRGB?
It does not seem very useful to have a menu for display device with options for sRGB or None. I wonder if it was ever supposed to be possible to choose specific display profiles. I imagine the process of creating the looks for a specific device would not be extremely straight forward and user friendly, would it?
First the look, then the proper sRGB transfer curve.
The menu shows whatever your OCIO config contains. The default config that comes with Blender is somewhat limited, but you could use your own config.ocio to define additional display devices.
Thanks for the answer. I assume in that case the set display device would be taken into account when displaying renders, saving them(except 32 bit formats) and rendering in the 3d viewport. Would material preview mode in the 3d viewport also display color in monitors color space? Blender ignores icc profiles - what about images opened in the image editor? Would they be assumed to be in the display device’s color space instead of whatever profile they come with or would they be assumed to be sRGB like now and correctly converted to the display device’s color space?
Nothing to do with sRGB’s transfer function in Filmic. It is just some bending designed for a pure 2.2 power function display. In order:
Ideally this would probably be configurable. By default, Blender is pretty awful at handling and I believe it simply rolls it through the currently selected View / Look combination. With an OCIO approach, one would require, as @lukasstockner97 pointed out, a custom set of views or tack corrections on as a Look. OCIO V2 has a path for this.
They would be imported “as is”, which would end up assuming reference space lights.
Cycles and Blender actually have no colour management. You can select transforms and OCIO will handle them correctly via the UV Image editor, but Cycles actually completely ignores OCIO and takes all 8 bit imagery, ignores actual colour space, and applies the sRGB OETF inversion. So if you have a nonlinear Filmic log encoded image, Cycles would ignore how you tagged it and force the sRGB OETF inversion on it.
Judging from some of the idiotic code I have seen landing in Eevee, the same would apply there; new code is at least as broken as the legacy code.
No really, it is that stupid.
For linearized images in EXR, it also ignores any OCIO settings and leaves the values as is, which of course mangles up all colour if your EXRs are in an alternate set of primaries.
Blender is really broken in terms of lacking colour management entirely in this regard, and more pixel pushers need to come around to get pressure on the development process to get it fixed.
On the display out side, the default configuration only supports sRGB 2.2 power function displays, although it is pretty trivial to add more such as Apple P3. Without proper input handling however, all of that is pretty broken.
A 3 button mouse? Did you give the correct link?
Obviously not! Thanks for notifying me! 