Properly designed materials hold up under all view transforms.
Assuming those are renders, you would need to attach the scene referred values beside the swatches to make it useful.
You also should remember that colour is, and always has been, a result of the ratio between the three basis lights. If you render using the sRGB OETF encoding, there is no desaturation and your values terminate at the very low value of scene referred 1.0. Without some controlled convergence to crunch the ratios together, the actual intended colour breaks.
That means that any resultant rendered pixel that has a scene referred value that exceeds 1.0 ends up set to the sRGB OETF 1.0 maximum with the view transform. This will essentially break the original intended colour ratio between the three channels, and yield the wrong intended colour. See the EXR examples for a good demonstration. You will see is extremely frequently in skies that turn cyan; the cyan is not the original intention of the colour ratios.
Other than that, be careful with terminology. Think of a pure red channel output pixel of 0.01 compared to 1.0 display referred. Contrary to what many think, both values are identical in terms of colour (proper term chromaticity and instead are only different in intensity.
Image makers aren’t and shouldn’t be considered lazy, aloof idiots. Learning and education are part of the craft.
I am sorry, I don’t mean to offend you or in any rude or emotional way, but from my perspective it seams you might be stuck in some sort of thinking that is limiting.
Imagine this: Say I have a sample of upholstery fabric and it’s color is of interest to me. I need some sort of uniform environment to think of colors so I can remember other fabrics I looked at and judge how it compares to them, so I always assume I see true color in neutral lighting without any color. Even that differs in my environment and we are not even talking about the intensity of the light. I always assume neutral to be 5500K when I photograph something using a flash, mostly 6500K photographing stuff outside in a shadow from direct sunlight in a balcony of the office I work in, 3000K on my desk in the evening and something around 4600K during the day, and 7000K when I look at my monitor! The light is also different in intensity greatly. So in reality, if we think of actual color, my eye sees 5 different colors in every case even if we don’t think of shadows and the angle I am looking at the surface of the thing. And yet I assume it’s the same color. IT DOES NOT MATTER, what color values you see there in the color picker. Color relationships, gradients between them and natural lighting effects in your renders are the things that matter. You always have a different lighting in your scene. And you are aiming to achieve a Filmic look with high dynamic range like you see in movies that are produced with expensive cameras that even differ from your regular DSLR camera. They should not match. If your daughter chooses green she will not get orange with Filmic. It’s still important to know what value ranges should go to albedo maps if you use Filmic. They should be physically based so no higher than 0.9, no lower than 0.1 in most cases. How accurate to the real world you want to make them is up to you, but you should not use Filmic and think of albedo values as colors on your monitor, simply because it was not meant to be used this way. You are meant to think of reflectance values as of a percentage of light a surface reflects, that should have nothing to do with a reference photograph or a dream of an artist. The rendered and color graded result you get should.
Well that’s the beauty of it - when you have such a question you can think - is there any surface in existence in the physical world that would reflect nothing in red light? No, there is no such material as far as I know. Even the darkest material - Vantablack paint- reflects 0.02% of light, red including (or something like that, I don’t know, it depends on where you look, it doesn’t matter, that is the most extreme material there is and most people will not even see it once in their lives). It’s is not likely you will have to show something even close in renders. 10% you would probably consider black paint. It can go a bit darker probably it’s just that it’s less likely with everyday regular objects. Or it can be darker if a surface is irregular and there are shadows of bumps on the surface on the texture. You can always decide what is black on your screen in post processing in your color grading, but with physical values, you will have more acuate color relationships.
I know how this process of learning is, I really recognize what you are going through right now. I wish you push through it as easily as possible. I think there is great amount of information of how to deal with albedo maps in those substance tutorials. I need to watch them all myself as well.
I think you now understand it well. It’s important to understand what you just realized. That’s all. The ‘workaround’ you were trying to design still might become a ‘workflow’. There is nothing wrong with wanting to get a specific color in your render in some specific lighting conditions as long as you understand how this all works and the color in question has physically acuate reflectance/albedo values behind it in the scene so it does not break the scene refereed workflow and thinking. I don’t think it’s a bad idea to have a pallette of colors in your scene to help you judge color at all.
I simplified a bit and meant that if our input primaries, working primaries and display primaries are the same, “linear” input transform in OCIO, at least to my knowledge, is (or should be to prevent confusion) a no-op. But your point is very good, that non-color makes sure OCIO CM does not kick in at all.
How I imagine a partial solution to color pickers is a possibility to apply the view transform to them. At the moment you see sRGB colors and based on them you get scene-referred RGB values (from RGB tab, not Hex). But even when your render outputs the exact same values pre-CM (using an emission shader with power 1.0 for example), the view transform is different than the transform based on which you chose your colors, so the result will not and can not be the same. But if it were possible to apply the view transform to colorpicker, you would get something more in line with what you wanted to see.
Antony implemented the view transform on some of the pickers. I can’t remember which code paths fail for them. The more subtle issue with albedo is that you are frequently dealing with a somewhat compressed range of values. Perhaps adding in a scale and offset to the picker might be a reasonable method to let someone design albedos more accurately?
You can test this when painting; the value you will see painted when set to the display referred 1.0 maximum will be the maximum scene referred value from the Filmic encode.
In an ideal world, due to the need to accomodate both colours and data, the UIs should have a selectable transform on them. Even curves for example, make sense.
Completely agree with all of your points and have been advocating for precisely such a solution. It has been extremely hard to communicate prior to Filmic however. Perhaps now a larger discussion can take place.
I meant the first variant, but the second idea of environment-adapted colorpicker is an interesting one. First solution would give us a way to unify scene referred values with viewing in a WYSIWYG logic and is a technical handle. But the second is more of an artistic approach and would be very useful for some situations, I’d love to see a prototype of this and fiddle around.
From the wikipedia article on albedo: “Albedo is a measure for reflectance or optical brightness”. In CG some people have picked up a rather annoying habit of referring to specular reflections as “reflections” and diffuse reflections as “diffuse” as though diffuse reflections somehow weren’t reflections. Albedo is just reflectance expressed as a ratio of incoming light to outgoing light
How do I calculate the albedo. Let’s say I found on the internet that the albedo for sand is 0.3. Oh, Isn’t that difficult to find out what R, G, and B values I have to use here
Albedo is wavelength dependent. If you get a number without a wavelength or spectral power distribution that it was measured under, that usually means it was measured under daytime sun (the solar radiation that reaches the ground.) When specifying it as an RGB color, you’re not using sunlight, you’re specifying albedo for each of your color space’s primary lights, hence why the measurement is color space dependent.
especially we use fresnell? Let’s say we didn’t use fresnell, should I then take the average of the R,G, B values of both shaders ? Or do I use the values I found for Albedo only for the diffuse shader?
Most CG shaders express albedo for the diffuse portion of the BRDF, so fresnel isn’t involved (it’s used as a blending weight for the specular component). Unfortunately, unless your measurement specifies, you have no way of knowing if they controlled for diffuse vs specular reflection (such as using polarizing filters) or what angle or wavelength they sampled under. So just guess. Pick some values that average to 0.3, I guess. Unless you have specific scanned data, this isn’t quite as scientific as you’d like it to be.
And is there somewhere a good source online where I can find albedo values.
Finally, in case you weren’t all having enough fun, doing all this in RGB is moot: https://en.wikipedia.org/wiki/Metamerism_(color) To give an example, say we have two spectra, we’ll call them “spectrum A” and “spectrum B”. They are not the same, but produce the same color in our colorspace. Because of this, we are forced to assume that A+A, A+B, and B+B all produce the same color in our colorspace. But they might not, we have no way have knowing once the spectrum is distilled to RGB.
Oh, and if you’re following the Allgorithmic PBR Guide, grab yourself a buildbot build and use the Principled BSDF shader instead of those node groups. It implements the sort of shader described by that guide (metallic/rough) natively and correctly. The node groups are all approximations, as it wasn’t possible to implement fresnel correctly within the node graph. (as it requires information that is not known when the graph is compiled)
For albedo, the resultant value would be a monochromatic ratio. That is, ignoring the illuminant and spectral complexities, it is the luminance weighted output of whatever your reference space’s primary lights would be.
For REC.709 / sRGB based primary lights, which Blender’s default reference and Filmic Mark I assume, the following would be the weights:
0.212673 * Red + 0.715152 * Green + 0.072175 * Blue
Albedo also can be called LRV in interior design context - Light Reflectance Value. It is sort off common for good paint manufacturers to indicate the values on their pallettes in some way. For example NCS system has ‘blackness’ value in their color codes that is inverted LRV/Albedo. Some pallettes just have a number 0-100 (5 to 97 practically). Anyway, LRV - another keyword to put into google. This is helpful for architectural visualizations. The term is also used in photometric interior lighting analysis.
Edit: It appears I made a mistake here. NCS system uses values based on human perception, not related to LRVs. It is however possible to find approximate LRV for most paint color pallettes for example here: https://www.e-paint.co.uk/Lab_values.asp.
Find of the day - Blender does not recognise any file texture color profiles at all. It allways assumes any file texture is in sRGB if the texture is set to Color data.
So if I want to input linear values from a file I need to set it to non-color data, or convert my non linear file to sRGB. It seems to be easier to adjust the values in linear space since you only need to match beginning middle and the end of the range. I see no difference visually if it’s linear non-color data or linear converted to sRGB and used as color data.
I think in this scenario camera calibration starts to matter. It might be a good idea to profile my camera… as soon as I find where I can get a IT8 calibration target in the small city I live in.
Blender, as well as most industrial 3D / CGI applications, does not use an ICC based colour management solution.
This is a dangerous habit. If it is colour data and linear, it must be set to linear, not non-colour data. If you get into the habit of doing this, your workflow will fall apart of your reference deviates from your display’s output.
EXR encoded files are best of breed for work. If you aren’t using them, it is prudent to start.
There is nothing wrong with wanting to get a specific color in your render in some specific lighting conditions as long as you understand how this all works and the color in question has physically acuate reflectance/albedo values behind it in the scene so it does not break the scene refereed workflow and thinking. I don’t think it’s a bad idea to have a pallette of colors in your scene to help you judge color at all.
