I have been playing with cycles materials for a long time and have got fairly decent results - however recently I have been trying to get to a better level of realism and have realised that my use of colour in materials ins’t very realistic.
I tend to give highly coloured materials colour values near 1 - but this is not very realistic as it implies 100% reflection at that colour.
I have been looking up albedo values for common materials and that has lead me to conclude that I shouldn’t be making materials more than 70-80% reflective - even for very bright/reflective materials like fresh snow etc.
I’m trying to relate Cycles colour values to albedo - but have noticed that the colour values in cycles don’t appear to be linear (i.e. RGB 0.5, 0.5, 0.5 is not half as bright as 1,1,1).
Does anyone know what falloff is used for cycles colours and how this relates to albedo?
Edit: it’s ok - figured it out. Cycles colour sliders use a gamma of 2.2. Therefore in order to relate albedo to cycles colours - I need to add an RGB node - and run it through a gamma node set to 2.2. This will linearise the color and as such I can put the colour in directly as a percentage.
yes albedo is important for realistic materials,best seen at quixel megascans.we talked about the workflow Blender has, in the Blender Filmic thread.Thats important too.Lighting and Materials goes hand in hand.Blender calculate all values internal in a linear way,and displays all with the selected values ,from the colormanagment,display device ect ,with gamma 2.2 like your colorpicker example.
the best method to work with real color datas, is to know what happens in the workflow.i found the best to me is ,to treat the scene as like make a film or take a foto with a real camera.
since Filmic is there i use it always,that helps alot with highdynamic range lighting.then i make a new sphere object in the scene,and give them a liniear 0.18 value to the diffuse mat.this sphere works than as a greyball or graycard with 18 % like in fotographic workflows.
then set in the colormanagment from filmic to falsecolor and adjust the light strength ,from your hdri ,until the greyball fits with the grey from the falsecolor,then switch back to filmic.
this workflow is like fotographs works with a greycard,and you are sure your lighting is calibrated so to say.otherwise your scene is under or overexposed and all is guessworking.with the greycard method your lighting fits,and so would all albedos like megascan or other realdatas fitting into the scene.
This is an overly simplistic view of what is actually happening, in addition to being incorrect.
In some of the pickers, the values for the HSV view will be rolled through the view. This means that the values are never subject to a simple hard coded 2.2 power function. Using the “Default”, the HSV values are rolled through the sRGB OETF transform, which is what the “Default” transform is as specified in the OpenColorIO configuration. The sRGB OETF, however, is a two part function, not a pure 2.2 power function. While it might seem “close” to a 2.2 power function, it isn’t the case. If you change your view to something other than the “Default”, such as “Filmic”, the values will be rolled through the transfer function of the view, which has nothing to do with a 2.2 power function in the simplest sense.
When using the RGB tab of the pickers, the values are strictly linearised. That is, you can pick albedo values of > 100% reflectance, for example, and the ratios are strictly linearised.
i think normally cycles use the SRGB
which is RGB with gamma correction
note there is also a bug in the color management
been there for a long time
might be corrected in 2.8 I hope so
I had to make a script to correct some image colors conversion to get it to look right
but been a long time !
don’t know if this has been corrected yet !
and same rule apply for black and white don’t use 1 or 0 !
But the colour pickers arent linear. When I slide the “brightness” slider of the colour picker on the glossy node for example - I reach an RGB value of 0.5 approximately 1/4 of the way down the slider - however this colour is not a medium grey - it appears too light even in the colour picker box (which is unaffected by things like filmic etc).
I have used hex values to map photoshop 0-255 RGB values to blenders 0-1 range - and this is the graph I get. You are correct that it’s not mapped to 2.2 gamma, but by the same token, it’s far from being linear.
I guess my question is - given 1,1,1 in blender is equal to an RGB value of 255,255,255 in photoshop and given 0,0,0 is equal to an RGB value of 0,0,0 in photoshop. Why isn’t 0.5,0.5,0.5 equal to 128,128,128 as you would logically expect?
Linear RGB value of 0.5 is not medium gray. Perceptually medium gray has linear value of ~0.18 and 0.5 will appear as light gray. You are mixing up the concepts of linear light (what is there) and perceptually linear (what you see). Physically/mathematically linear gradient is not linear visually and vice versa.
As troy_s wrote, only RGB tab will show true linear values that are used in rendering, HSL and other tabs are transformed through view system and show values that are more familiar to PS users. But PS does not by default work with scenelinear values like Cycles does, instead it works with gamma corrected values that can be directly sent to display, but are not correct representations of intensity when dealing with light or compositing.
Well, 0.18 is 18% of 1.0, so it does. And it is perceptually middle between display black and white. A value of 127 in 8bit gamma corrected system will also leave the monitor as light with intensity of roughly 18% of monitor max brightness due to monitor gamma that we are correcting for in the firstplace. Actually it is more complicated, both system and value wise, but this simplified example will do here.
here a quick copy and paste from the Filmic readme file,you can see what the falsecolors are representing.
Greyscale. This Look is based off of the Filmic Log Encoding Base and will deliver a weighted greyscale version of the image. The weights used are for REC.709 RGB lights, which are the same lights specified in sRGB.
Five contrast base looks for use with the Filmic Log Encoding Base. All map middle grey 0.18 to 0.5 display referred. Each has a smooth roll off on the shoulder and toe. They include:
Very High Contrast.
High Contrast.
Medium High Contrast.
Base Contrast. Similar to the sRGB contrast range, with a smoother toe.
Medium Low Contrast.
Low Contrast.
Very Low Contrast.
False Colour. This Look is an extremely useful tool for evaluating your image in terms of the dynamic range and latitude. It is a colour coded “heat map” of your image values, according to the following codes:
Value
Colour
Scene Referred Value
Low Clip
Black
Scene Referred Linear value below 0.0001762728758.
Hi there Pixelgrip. Thank you very much for this information. I have one question, though. Where did you get this info from?
I am doing some work and need to calibrate my image, therefore I need 100% accurate and bibliography backed info. Would you please be kind enough and direct me to your information’s source?
