Pasting a converted RAL into the color of a Principled BSDF renders way too bright with a Nishita sky (and Filmic). I know the conversion to RGB is an approximation but the result is just too far from reality to be usable.
So far I’ve basically been tweaking each material manually until the result looks right but that’s far from ideal and it becomes repetitive.
Is there a better process to convert a RAL into an albedo that Cycles can treat more realistically?
The Nishita sky defaults light str is 1000w like real daylight sun.You have to turn down the exposure setting to get a light balance similar to a camera setup.In combination of Filmic just make a sphere object and give it a diffuse color of 0.18.(like a camera greycard).then turn down exposure to get a middle grey 0.5
Additional,did you know what the color conversation tool does? I guess it is gamma corrected for display?
You could try to put in the HEX value into the basecolor of your shader.
And about color saturation.
With Filmic you have the possibility to render images with very high light str/dynamics.This means Filmic softens the last 20% of the highlight into a whitepoint to avoid colorclipping and hueshifts.
If you want pure colors, then you have to work with low light strength,means to avoid clipping,and dont use Filmic.In short to keep the light strength and renderoutput inside the black white range of the sRGB range.
As said the middleground of colors are no prob with Filmic and high light dynamics up to around 80% then the compensation into the white kicks in.
Thank you. Of course the exposure! Why did I not think of it? I feel so dumb.
And thanks for the other details.
Where is that “color conversation tool”? Also don’t you mean “conversion”?
I can use it when I need a specific RAL color.
I don’t think it’s the right way to show the color exactly. This is the closest I can do.
Light, material even monitor can change color.
I have nothing to add to the question but wanted to say thanks to @Omer_Faruk_Davarci for the info on the node group and @Korchy for the sharing the link. I planned on creating a library for the RAL colors myself.
Edit: The below information from myself is incorrect. Read the following responses, as to why.
I know this thread is old but I just wanted to point out that its only possible to roughly match RAL colors using the srgb display transform. It isn’t possible to using the Filmic setting, without processing by observation.
For Blender to display the colors as you originally saw them on the reference sheet requires using the same transform that was used to encode them. This would have been the srgb transform. It’s already been pointed out by other users that the Filmic Transform transforms the colors from scene referred to display referred differently by preserving the ratios between of the 3 primaries.
If the original RAL colors were encoded using the Filmic transform this wouldn’t be a problem. What would be really nice if somebody would color match filmic colors to the RAL srgb ones and put them in a color chart. Unfortunately that would a time consuming task.
Another issue where this is a problem is texturing. Most reference images will have used the srgb transform. BUT because the srgb transform doesn’t preserve the primary colors your not actually getting a real representation of the actual colors, as captured by the camera. So as artists we are stuck between trying to match what the camera sees OR what you see in the reference images. If you don’t match to what you see in the reference images, viewers could end up viewing your asset side by side with an image reference and thinking it doesn’t look realistic.
For this reason, I’m swayed towards grading for srgb. 99% of the images on the internet that we use for image references are srgb. Unless the majority of the images change to using the Filmic transform, this issue will remain in my opinion.
To be clear, Filmic does not maintain ratios. This is one of the massive downsides of ACES, Filmic, and many other approaches. Filmic was deliberately designed this way to save on bandwidth, a decision that traded off potential adoption over more complex design.
This is a tad of a misnomer.
sRGB is a display encoding, so when we encode for it, we are more or less saying that our “image” is ready for display and finished.
Contrast this against a render, which simply isn’t yet an image; it’s open domain light data, from zero to infinity. To get to an image, the process of image formation manipulates the light data in some way, and arrives as an “image”. That image can in turn be encoded for any display, including sRGB.
Getting from light data to an “image” is a potentially hugely nuanced and complex process, but make no mistake, sRGB doesn’t really play a role here until the image is fully formed.
Can someone manipulate the light data manually and end up at an sRGB encoding? Sure. Will it have problems and bring additional pain and headaches? Absolutely.
The important point though is to appreciate that the process of image formation is not quite as simple as saying “I use sRGB”; sRGB is simply a display, and more or less an output medium. The real work is in massaging the light values into shape.
There’s no such problem rooted in what you are citing.
Thank you for correcting me and I apologise to you and others if I’m misinforming. This is what happens when I you try to take in too much information without letting it sink in. I’m still not 100% convinced that the problem doesn’t exists because I’m not entirely sure if I’ve grasped the concepts incorrectly.
From the information I’ve read Filmic has been described as a transform that is designed to replace the existing srgb EOTF. Therefore I’m interpreting this as meaning the srgb EOTF, which from my understanding for rec/709 is a modification of the standard gamma correction. After the view transform the image is ready for sending the display device. An image transformed with the standard srgb transform looks different in color than one with the Filmic Transform and look.
When I was saying that the 99% of images are srgb I meant they have been transformed using the srgb EOTF. Therefore if you reference and one of these images for an albedo texture you would need to color correct the colors to look the same when rendered using the Filmic Transform.
I still think the problem may exist because if I’m creating an asset to be sold, I’m at the risk of customers not understanding that the albedo textures would have to be color corrected depending on the color pipeline.
I would have to put a statement - “The color/albedo textures have been graded to be rendered with the Filmic Transform whilst perceptually matching srgb EOTF encoded image references. Please color correct the textures to match whilst using different transforms”.
I’ve edited this post multiple times because I think I presented a clear example of Social Proof by automatically assuming that my point wasn’t valid because it was you that responded. I should have backed up my original claims.
Here is are two demo images of a horse asset that I intend to sell. Please bare in mind this is not the final state just shots for the purposes of my explanation. The first is rendered with the standard view transform without a look and the second with filmic, also without a look.
I originally chose my albedo colors by referencing online image photos and color matching using the standard view transform. I then decided that I wanted to render using Filmic because the highlights looked awful using the standard transform. BUT by doing so the orange color appears to have shifted to towards yellow. This shift is exaggerated in other lighting conditions. So to get it to match the reference images I need to color correct the albedo texture.
The real problem lies in judging how the asset will be used and try to avoid constant support emails asking why the colors don’t look correct. This what I meant when I say “I’m swayed towards srgb”. I meant that I’ve decided that grading my images textures to the srgb standard transform may be the best way to go.
For an commercial asset I personally think the marketing images should not be post-processed.
I’ve been reading a lot a bout color management lately and I must have gotten the information regarding color ratios mixed up. I thought it was from a post response of yours on stack exchange. Obviously not, sorry! It’s going to bug me now because I should have saved what I was reading for reference. I’ll find it again soon.
I have a quick question. It will help me have the correct information.
To me it isn’t clear from reading https://github.com/sobotka/filmic-blender and the Blender Manual whether the looks are designed to be used with, Filmic, Filmic Log or both.
From the Blender Manual:
Filmic
For photorealistic results and better handling of high dynamic range colors. The contrast can be adjusted by changing the Look option for the Filmic view transform.
Filmic Log
Converts to Filmic log color space. This can be used for export to color grading applications, or to inspect the image by flattening out very dark and light areas.
Filmic Log Encoding Base. This is the workhorse View for all of your rendering work. Setting it in the View will result in a log encoded appearance, which will look exceptionally low contrast. Use this if you want to adjust the image for grading using another tool such as Resolve, with no additional modifications. Save to a high bit depth display referred format such as 16 bit TIFF. This basic view is designed to be coupled with one of the contrast looks.