Timeline for How to get accurate colors with Filmic Blender
Current License: CC BY-SA 4.0
23 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 26, 2020 at 1:22 | comment | added | troy_s | Except using the inverse sRGB EOTF will also botch the shit out of every colour; it’s a display transfer function, unsuitable for rendering. Full stop. No debate. No discussion. Simply wrong. And I hate to break it to you, the Alexa and the rest do literally the exact same approach. I’m not sure where you are getting your information from. | |
| Jul 25, 2020 at 21:46 | comment | added | Copperplate | @troy_s Thanks Troy. Yes, it can be difficult to match colours in different situations as you said, but the "standard" view transform still gives the closest result (granted, after you change any "look" settings, you do lose some colour accuracy). I guess I'm looking for something similar to how modern cinema cameras use a WideDR Rec709 mode that cleverly pre-applies a LUT to preserve more dynamic range than standard Rec709 but keeps colours accurate. Since the colours I need to match are shades of white, this probably presents a special challenge since they lie at the upper end of the curve. | |
| Jul 24, 2020 at 20:08 | comment | added | troy_s | @Copperplate Matching a display referred swatch is ultimately a fool’s errand as much as would be taking a photograph of the same swatch on a display and expecting 1:1 in a print or in the photograph of the print; one is dealing with a strictly bound domain, the other is not. This is a terrific presentation from a very high end brand identity on the complexities of nailing down a brand identity colour via paint, and worth a watch: youtu.be/rYGbZXPFmpA | |
| Jul 23, 2020 at 19:50 | comment | added | Copperplate | @troy_s Thank you Troy. While your detailed answer may be scientifically correct, in a real world scenario, I find that the discrepancy between filmic and standard reveals it's impossible to color match paint in a client's architectural project, even if the scene is lit by only a single sun lamp set to pure white. It doesn't matter how weak or how strong the lamp is, "Filmic" will never be able to hit the RGB colour of the manufacturer's sample like "Standard" can. This is really unfortunate and I have not been able to find a workaround for this yet. | |
| Jun 10, 2020 at 12:57 | history | edited | CommunityBot |
Commonmark migration
|
|
| May 19, 2018 at 22:17 | history | edited | troy_s | CC BY-SA 4.0 |
added 37 characters in body
|
| Apr 7, 2018 at 17:29 | history | edited | troy_s | CC BY-SA 3.0 |
Elaborate "wrong" colours to be more clearly about colour ratios.
|
| Apr 7, 2018 at 17:20 | comment | added | troy_s | @AnsonSavage I can't really give too much insight as I don't know your context too well. I will say that the first checkpoint is albedo; many albedo values are completely wrong. It should be a separate BSE question. Align your albedos to physically plausible values, otherwise they will reflect too much light and hit desaturation far too quickly. Also remember; you can't maintain a heavily saturated colour and high emission / reflection. It is simply impossible. As a result, something must be done with those values. I can elaborate, but comments aren't the most ideal. Hope this helps. | |
| Apr 7, 2018 at 13:20 | comment | added | Anson Savage | I've been trying to better understand this concept for a while now. I've been using Filmic for all my renders recently. According to your answer, this preserves the color data accurately. However, if I am not happy with the washed out, desaturated look of the render, (and assuming my lighting and materials are correct) does that mean I should make all further adjustments using the exposure/gamma/curves and maybe the color balance node like Andrew Price shows in his tutorial? Thanks for the epic contribution you have made to the CG world. | |
| Mar 20, 2018 at 15:25 | comment | added | troy_s | No. Infinity in a scene referred model is some arbitrarily high value, not the display referred limit, which is typically 1.0. 0.18 up a stop? 0.36. Up another stop? 0.72. Another? 1.44. Another? 2.88. Etc. 1.0 in a scene referred image holds no particular magic value. | |
| Mar 19, 2018 at 16:54 | comment | added | Rick Riggs |
And Infinity in RGB space is (technically speaking): 1.000000000000... To base the proportion on? I realize that you provided a quick answer for brevity, but how do you know the margin between the top of the BLUE channel and infinity (on the Scene Referred Input side of things)? Meaning instead of a true INFINITY where do we say near INFINITY is to actually calculate out what an adjusted (Filmic Transferred) RGB value should look like?
|
|
| Mar 19, 2018 at 14:48 | comment | added | Rick Riggs | @troy_s, so in other words sRGB transfer truncates at 1.0 (if need be to express maximum regardless) & Filmic transfer scales the light within the scene proportionally amongst the RGB Channels based on what the hardware detected as light quantities within the scene (and always keeps these values valid by scaling them down to fit between 0.0 & 1.0)? Which in turn will essentially give the effect of the scene being the proportional sum of all of its parts with valid RGB that blender can use? | |
| Mar 16, 2018 at 23:56 | history | edited | troy_s | CC BY-SA 3.0 |
added 218 characters in body
|
| Mar 16, 2018 at 23:32 | comment | added | troy_s | Yes @RickRiggs, it would be in relation to some physical quantity of light, relative to a given exposure. So with that, relative to arbitrary unit X, the sky might be two, fifteen, or five hundred times the quantity of light. Hence it would be theoretically infinite, limited by quantisation of hardware of course. | |
| Mar 16, 2018 at 12:27 | comment | added | Rick Riggs |
@troy_s - Could you give an extremely basic but accurate explanation as to the definition of unit used in the Filmic Y-Axis Label just under Infinity within your image: Scene Referred versus Display Referred Chromaticities? Is this in direct correlation to intensities of light within the scene? In other words, how did the Blue channel get so high?
|
|
| Oct 18, 2017 at 23:47 | comment | added | troy_s | The problem is that you can't have intense and highly saturated ratios with the sRGB OETF; the original colour is lost as the ratios skew. The OP should be able to see an intense orange as per the picker ratio simply by increasing illumination under Filmic. | |
| Oct 18, 2017 at 22:07 | comment | added | Mareck | So, it's the reason of the false impression of desaturation of the sRGB, isn't it? OETF or EOTF ? Nice answer like always. | |
| Oct 17, 2017 at 3:30 | comment | added | troy_s | I don't know about honoured, but hopefully this information can help others. Read through the response. If you mean the top of your orange or green cubes, the answer is no. The reason is that the colour on the top is in fact incorrect, and hopefully the post begins to explain why. You could of course make the cubes those colour ratios, but the sides would be different, and more saturated. If this isn't clear, please say so and I'll do my best to explain it better in the answer. Colour is deadly important for a pixel pusher. Learn as much as you can. | |
| Oct 16, 2017 at 18:42 | comment | added | saicode | Wow! I am honored to get a reply from Troy Sobotka himself :) To be honest I didn't understand it fully yet - I have to read it a few more times - but I really appreciate for you to take time for such an extensive answer. I realized that I framed the question wrong - what I meant is the Input colors (image or RGB slot in the shader) is more saturated than the render - is there a way to get the same (or almost the same) color as the the input slot color? | |
| Oct 15, 2017 at 23:46 | history | edited | troy_s | CC BY-SA 3.0 |
Fix image
|
| Oct 15, 2017 at 23:13 | history | edited | troy_s | CC BY-SA 3.0 |
added 120 characters in body
|
| Oct 14, 2017 at 21:02 | history | edited | troy_s | CC BY-SA 3.0 |
added 6 characters in body
|
| Oct 14, 2017 at 20:54 | history | answered | troy_s | CC BY-SA 3.0 |