'Filmic Blender' is becoming quite a thing in the Blender community! After our initial coverage earlier this week, here's a new tutorial on another application.
I love the new configuration made by Troy Sobotka. It gives a good scene just that little nudge to make it perfect! While working with I ran into a problem though. I missed the old 'Film' look that I used very often. The one popularized by artists like Reynante Martinez and Gleb Alexandrov. I decided to dive into the script and see what I could change about the situation and I came up with a solution. This short tutorial video I cooked up to shows how it's done! Keep in mind that this is not backed by science, but allows for some more artistic freedom with new tools.
Okay this gives a better view of what ive read. Still i dont get why they still say its best to work in linear mode, this is the same as in the other settings, there is no difference between the linear mode in this setup as in the other setup is there?
Next time drink some water bro, you sound like a dying old man ;)
Blender always works in linear color space underhood. So when you change the view to linear, you just see the raw linear space, that's it, no matter whether you're on the original settings or the filmic ones. The thing is, monitors display color with different gamma settings, and that's the reason for color corrections. When you render, the most comfortable way of working is to view your image already gamma corrected. If that makes any sense to you.
Great video BTW, I was wodering how to bring the old film look back into blender after replacing color management files for the filmic ones.
Close but not quite: The important aspect to understand here is the difference between the linear scene and the display.
In a scene-referred image, light intensity goes from zero to virtually infinity, as there is no limit for the light intensity you may find in the real world (in CG the limit is only the maximum value that the precision of the file can storage).
That's what cycles produces.
In a display-referred image the light range goes from 0 to 1, being 1 the maximum light intensity the display can produce.
When you have a scene-referred image and you want to show it in a display device, you have to apply a transform that will take a portion of that virtually unlimited display range and fit in in the display range.
A display-referred image can be linear or non-linear. However, as devices and human perception have a non-linear response, a display-linear image isn't quite ready to be displayed.
So the view transform not only grabs a portion of the scene dynamic range, it also applies a transfer curve to take that linear data into a more "displayable" form.
It's a bit more complicated than just a gamma curve, as the transform has to take care of making the image perceptually uniform and correct it for the target display.
Hmmm, so where did I go wrong? Linear is linear (gamma = 1). Gamma corrected image is prepared for the display device (gamma = 2.2 in most cases). Linear in old color management system is the same as linear in the new (filmic) linear system (that's what the question was all about). But it's better to view your renders already gamma corrected (here's where the different looks come into play - but, differences between them are caused not only by gamma correcting them).
As to gamma corrections itself - man, don't make it too complicated. It's just preparing the image to match the display settings, so our eyes can catch the details properly. Few years ago, you should be more careful about this, as different displays had various gamma settings, nowadays, in most cases, image gamma set to 2.2 does the job. And it's done with a power function. And I've never heard that gamma correction is anything more than that. Clipping values above 1 also has nothing to do with gamma correction itself. Sure, working on a raw image give you more options in post pro, but look closely at what gamma correction math does to the image. Input pixel value of 1 to any power gives you 1. Values above one to any power give you values above 1, and will be clipped (no matter whether before or after the correction), so these values does not matter in the process, and have nothing to do with the gamma correction. Tweaking your image look, colour correction and post-pro is much more and sure, is more complicated. But gamma correction is just a part of it. I hope that makes sense :-)
The point was that it's more complicated than just gamma-correction.
It's not that you have a linear image, apply power of 2.2 and bang, it's ready to be displayed.
That linear, high dynamic range (scene-referred) image has to be tonemapped to fit in the display and then be gamma corrected.
It's not clipping valuews above 1. You're bringing some of them into the display range using a curve that is NOT gamma.
So even though modern displays could be capable of showing display-linear images directly (they don't as gamma correction was kept for legacy reasons) that doesn't mean thay you can just feed scene linear straight away to the display.
Dude, don't take it personally, but could you provide some source of what you're talking about? Maybe all I've learned about linear to non-linear color space conversion is wrong, maybe. But all I know is that it's applying gamma correction. Tone mapping HDR rendered image has nothing to do with the linear/non-linear color space. And that's what the question was all about. Linear vs non-linear. What you're talking about is not only changing space from linear to non-linear, but color managing it. You (well, the aglorithm in this case) color manage HDR image for the purpose of getting better results on a screen, sure thing. But mostly it's to do with the contrast. Do a test, render an EXR, and then gamma-correct it, don't tonemap it, don't apply any specific color-space to it. See the result. Yeah, it's ready to be displayed, even not tone-mapped. And you can tone-map your image yourself if you want. And nobody's saying that you can feed your linear scene directly to display. Well you can, but the results will be poor... Unless you gamma correct your image :-) As stated above, if you have any interesting sources about the topic, I'd be interested in them, as CM is something it's good to know at least a bit about :-)
I'm assuming you didn't read this:
You seem to be a bit confused about what colorspaces and CM are. Please read that thread and the reference, they are really helpful to understand the concepts involved better.
Tonemapping means what its name says: mapping tones (from the scene to make them fit in the display range). It's not only that process to make fugly photos from HDR images :-p In the case of Filmic-Blender it grabs the dynamic range film would capture and maps it to the display range.
How does it do it? With a cuve (without a curve the linear transfer wouldn't be efficient to accommodate the values in low bit-depth image or display)
Color management deals both with the chrominance and the transfer curve, so yes. This has everything to do with color management.
That the result is "gamma-corrected" doesn't necessarily mean that only the gamma curve was applied to the linear scene. Again, it's more complicated than that.
P.s.: I'm not taking this personally at all, we're just discussing concepts.
Indeed, I haven't read that, and thanks for the link. But nothing has changed. Please note, I never wrote that it's just making fugly photos :-). And I still claim, that what I wrote above is right. Transfer from linear to non-linear is done by gamma correction, and only that. Which is part of the color management. But the color management is a broader topic. And still, it is enough to gamma-correct image to change it's color space from linear to non-linear. And you can change image's space to linear form non-linear as well. Saying that a result is "gamma corrected" meaning "color managed" is the same (more or less) as saying the image is rendered and meaning rendered and post processed. So, to be clear, gamma corrected means gamma corrected. Where did I write that gamma corection has nothing to do with the color management? If I did, my bad, but I surely wrote it has nothing to do with tonemapping (meaning tonemapping HDR image). And that's still standing. And well, I don't even know how to answer the part about accomodating the values in a low bit depth image.
Think about it, taking literally your argumentation that:
"When you have a scene-referred image and you want to show it in a display device, you have to apply a transform that will take a portion of that virtually unlimited display range and fit in in the display range"
would mean, that before filmic, Cycles renders were not ready to display. Beceause what is done in sRGB view in Blender is gamma correction and clipping values above 1. Clipping, not fitting anything into that range. Look closely, it's even in the link you sent me. So, in your opinion, does Blender tonemap your image if set to sRGB display or not? The reason behind filmic was to tonemap scene ref img values to fit in 0-1 scale similarly to the way cameras do, and apply desaturion for higher color values. But again, it has nothing to do with changing color space from linear to non-linear.
BUT reading my first post again I see my mistake, and a huge one actually... I wrote that the reason for color corrections is displaying on device with different gamma settings. And I for obvious reason didn't mean "color corrections", but "Blender letting you see images gamma corrected even tough Blender works in linear space underhood, so you can see the final result already". My point was that it's better to work in (any) color space wiev proposed by Blender (sRGB or filmic) than in linear wiev. And that's it :-)
"And still, it is enough to gamma-correct image to change it's color space from linear to non-linear."
No, you're still wrong. You don't understand the difference between scene-linear and display-linear for starters.
You don't understand that a display transform isn't just grabbing 0 to 1 from the virtually unlimited range and running it through a 2.2 power.
Please go read the references I just gave you, try to wrap your head around them and review what you just wrote. Most of it is plain wrong, the rest is you trying to accommodate the facts around your flawed knowledge.
Oh man, and have you read what you sent me? And do you recognize the differrence between linear and non-linear color spaces? I know the difference between scene-linear and display-linear, it's really not that difficult. And maybe my knowledge is flawed, but hey, nobody's perfect. So let's take a look at few things:
- sRGB color space, (I'm not going to give you links to descriptions, there's plenty of it on the Internet) read about it, it's gamma 2.2 correction, do some render tests, compare results when applying sRGB view, and just gamma 2.2 correction. As to what I wrote in my previous post, let me quote the source material you provided:
"In Blender, and particular using a raytracing engine such as Cycles, we are generating scene referred values in the internal model, and passing those values via a display referred transform to output. The default "sRGB" display referred viewing transform is a blind and ignorant hard cut. This transform is a strict inversion of the sRGB transfer curve that was developed as part of the sRGB specification. Here is roughly what it looks like from a layperson's vantage:" - if you find this piece on the site you linked you'll find a graph below, on which it is shown what sRGB does to your image (clips values above 1). Then think about your statement, that gamma correction isn't enough to prepare your image for viewing. Every Blender users has been doing this for years now, even not knowing it, even if it's (and it's not) good solution for CG. So, let me quote you:
"You don't understand that a display transform isn't just grabbing 0 to 1 from the virtually unlimited range and running it through a 2.2 power." -Firstly, all I'm saying from the beginning is that it's enough to correct linear image's gamma to make it non-linear. Never even mentioned pure renders, which should (but doesn't have to!) be tone mapped (to imitate cameras behaviour) - and do I have to state it again, that tone mapping is not the same as gamma correction?, BUT your above quoted statement in case of sRGB (used by Blender) is simply wrong, and what proves it are... references you sent me. And I understand, and statet it before, that color management as a whole is much more than gamma correction, and I realize that it can use tone mapping similar to cameras (as filmic look), but doesn't have to (altough should in case of CG).
If you'd like to continue this converstaion, please let me know what of I wrote is plain wrong, and which facts are just a (failed I guess) try to accomodate the facts around my flawed knowledge. As I said, I don't know everything, and it's possible that I may be wrong. For that very reason, please, use some arguments this time, other than "you don't understand", or "it's more complicated". Your references are great, and thanks again for sharing them. Just read them carefully, check what is sRGB color space, then reread my post.
Reading all the comments here I see that the new filmic blender is hard to wrap your head around. I will see if I can make a video that explains as much as I could understand of it.
I believe the problem here is that the discussion here is not about the filmic look at all... :-) What it does seems pretty well explained, and the new look is much appreaciated, at least by me :-)
@mrtherich: Just make sure you have understood it completely, otherwise you risk to mislead other people trying to use it.
That's why I tried to prevent Marcin's flawed argument above. Filmic Blender is a package of view transforms with a clear technical purpose.
Not fully understanding what color management is and using terms in a sloppy way (like speaking about colour spaces when you don't know what a colourspace is, using the term "color correction" as an equivalent for colour management, etc.) or implying that tonemapping has nothing to do with colour management only creates confusion and helps nobody.
So please, before producing a video tutorial, double check the data, ask questions and make sure you're good to go.
Troy has put a lot of work into making Filmic Blender, but before that he put even more work doing research and documenting the issues Filmic tackles, so make sure you're transmitting that knowledge properly so artists can take advantage of this great new tool we have.
Yeah, and please, tell me, where did I imply that tonemapping has nothing to do with color management? I wrote that GAMMA CORRECTION has nothing to do with tonemapping. Sorry for the CAPS, but it's the second time I need to explain that to you. Or how can you tell I don't know what color space is?
True, I misused color correction term by mistake, realised that, and explained what I really meant. And you still don't understand, that I didn't use it as an equivalent for color managament, but I meant gamma correction (yeah in sRGB space) instead. If I understand what color management is, is not yours to judge, and with every post you seem to prove you don't understand it yourself. And again, no real arguments against my arguments. You don't seem to understand my posts, neither the materials you provide yourself. You tell me to read them, but I get a feeling you haven't read them careful enough.
Instead of "yeah in sRGB space" I meant setting sRGB space (in Blender)
"- sRGB color space, (I'm not going to give you links to descriptions, there's plenty of it on the Internet) read about it, it's gamma 2.2 correction, do some render tests, compare results when applying sRGB view, and just gamma 2.2 correction. "
Sorry, what colorspace does Cycles render images in?
And by that question you mean what? You'd like explanation, that pure render is a scene linear image? Trying to be clever?
Oh, I didn't see your previous post, my bad.
What I wrote about sRGB and gamma I wouldn't call wrong. It is a simplification, that's a fact, as a 2.2 value isn't exactly what represents transfer function for sRGB. Sure, ther's some difference, but not huge. And still, if you render your image, and tweak your gamma (say, set it to 2.2), your image is ready to be displayed. As far as I'm concerned, that what's that conversation was all about. We can now throw definitions at each other (and is it necessary to post a link to definitions under every word you use?), and make a fuss every time we don't explain in every aspect terms we use (even if not necessary needed) but it doesn't change the simple fact, that by tweaking gamma and clipping values above 1 from rendered image you can prepare it for display. I think you got the point from my post you mention right after reading it. Altough filmic does what probably should've been done in Blender from the beginning of Cycles (taking more of the raw image values range, and mapping them), it's not the way Blender worked so far, and still it worked. And it still stands, change gamma in your linear image, and it becomes non-linear, all tonemapping and other stuff aside. It's even written in the articles you provided in your last post (Tom Forsyth writes about it, let me quote:
"The simplest and most common form of power law suitable for encoding is gamma 2.2"
"sRGB is a slight tweaking of the simple gamma 2.2 curve"
which is called right in the article on color science page, even stating, that other sRGB specs can be let alone, at least when talking about rendering and transformations)
So the point still stands. And I believe with your last links you even prooved it right yourself.
BTW, the link to poynton doesn't work at my end of the Internet, so I couldn't check it.
God you still can't see that applying an nonlinear transfer function *is* tonemapping, right?
You also can't see that sRGB transfer correction is two part, and that you encode a part in your view/file so it cancels the display non-linearity (which is there for legacy and bitdepth reasons, as a modern display in theory could display linear).
You insist on making a simplification. For you 2.2 and slight tweaking of a simple 2.2 curve are the same and it's about the same so exchangable.
The sRGB view transform is not a colour space in that context, despite what you insist again and again, because it *ONLY* applies the sRGB's EOTF. (Wonder why Troy changed its name in his config?). Gamma correction is not that, that's just one part of it.
A saved nonlinear image from that view is in the sRGB color space, but what you see in the CM panel is just a view transform.
So my only problem with this argument is that you keep insisting on doing gross oversimplifications on a subject that it is more complex than you say.
Because of your limited understanding of the subject, you avoid the complexities and muddle terms and concepts.
That was what took us to Blender's poor default view transform in the first place.
The creation of Filmic Blender not only aims to replace that broken view. It also aims to create awareness about the importance of colour management and why artists should care and understand.
I'm moving on because there's not much more to say. You can either try to read back, read all the references I sent you (I sent you many, you gave none) and try to see what's wrong with your argument or you can keep repeating that your right and you always were and keep confusing people with your simplifications.
Here's more data if you want to make an effort:
If you read all the references I sent you and you still convinced you're right, then there's nothing I can do and this conversation is pointless apart from tedious.
Should I understand, that gamma correction is tonemapping? Ok, simply never seen any definition describing that. As for the tone mapping and gamma correction (and linear to non-linear, and what causes it):
I don't insist on making that simplification, just gave that example to show that only thing sRGB view ever did in Blender was gamma correction, or as you stated yourself applying the sRGB's EOTF. According to color-science.org:
"The sRGB electro-optical transfer function (EOTF) is a slight tweaking of the simple gamma 2.2 curve"
So if gamma correction is not that, and that's just one part of it, then what gamma correction it is exactly in your book?
About the saved sRGB image and so on, sure, that's right, but what that has to do with how you change linear to non-linear? And if it's not done just by changing gamma, then how it's done, please enlighten me? All the materials I've ever read say that you change from linear to non-linear for the display by gamma correction. And all you say is, it's not that simple, and start much more comlex conversation about the whole color management. But changing gamma and thus preparing it for display is just a part of it. As for mudy answers, you stated that:
"gamma corrected may mean, that more than gamma curve was applied". No, it means gamma corrected, and if there was something more done, it should be stated
"It's not that you have a linear image, apply power of 2.2 and bang, it's ready to be displayed [...]" - yes it is, as preparation for display is changing gamma, everything else you say about is more than that, and decide how well the image will look, but basically, changing gamma is what prepares linear image for display.
"That linear, high dynamic range (scene-referred) image has to be tonemapped to fit in the display and then be gamma corrected.
It's not clipping valuews above 1. You're bringing some of them into the display range using a curve that is NOT gamma." - well, old (and bad) Blender system proved, that HDR image doesn't have to be tonemapped, and can be clipped, and after applying gamma can be displayed. If you deny that, then I don't really know...
I admit, I might have mentioned in my first comment, that different views does more than just GC, thus the difference in how they look.
Also I'll honestly try to avoid simplifications, and not 100% clear posts, as I see that for the most part of this conversation the reason for argument was not not understanding the topic, but not clear answers. The thing is, I fell I'm not the only one mudying the subject.
"As for mudy answers, you stated that:
"gamma corrected may mean, that more than gamma curve was applied". No, it means gamma corrected, and if there was something more done, it should be stated"
Please don't put quotes around things I didn't say. Copy and paste, don't interpret.
"So if gamma correction is not that, and that's just one part of it, then what gamma correction it is exactly in your book?"
Gamma correction is the process of inverting the display curve with an inverse curve to produce linear light. There are two curves involved, not just one. Read Poynton's
2.2 is an oversimplification. sRGB is not exactly 2.2 and it's not the only power function to be used for displays. See BT.1886 and Rec.709, also in the links I gave you.
"Blender system proved, that HDR image doesn't have to be tonemapped, and can be clipped, and after applying gamma can be displayed. If you deny that, then I don't really know..."
So you insist that mapping 0.18 to perceptual middle gray is not mapping tones. Cool then.
"Also I'll honestly try to avoid simplifications, and not 100% clear posts, as I see that for the most part of this conversation the reason for argument was not not understanding the topic, but not clear answers."
No, this conversation is about you wanting to be right about something you understand partially.
And one more about mudying I found (not gonna look more, I need to get back to my stuff):
In your last post you say:
"God you still can't see that applying an nonlinear transfer function *is* tonemapping, right?"
If by non-linear transfer function you mean EOTF, which according to color-science.org:
"The sRGB electro-optical transfer function (EOTF) is a slight tweaking of the simple gamma 2.2 curve"
Then, how will you explain one of your previues statements, that tonemapping is done with a curve that is not gamma?
"That linear, high dynamic range (scene-referred) image has to be tonemapped to fit in the display and then be gamma corrected.
It's not clipping valuews above 1. You're bringing some of them into the display range using a curve that is NOT gamma."
So, to clarify my question, is applying the EOTF for sRGB (aka slightly tweaked 2.2 gamma curve) tonemapping? Cause one time you say tonemapping is different curve that gamma curve, and then basically you say applying EOTF (gamma correction) is the tonemapping itself.
"Then, how will you explain one of your previues statements, that tonemapping is done with a curve that is not gamma?"
With context. We are commenting on a post about Filmic Blender until you started parroting about gamma correction.
"So, to clarify my question, is applying the EOTF for sRGB (aka slightly tweaked 2.2 gamma curve) tonemapping?"
"Cause one time you say tonemapping is different curve that gamma curve, and then basically you say applying EOTF (gamma correction) is the tonemapping itself"
There's an unlimited number of transfer curves you can apply to tonemap your linear scene. Some are adequate for photorealistic CG, others aren't.
Also, tonemapping a view and encoding for a display are not the same thing, although at some point Blender devs thought it was.
"applying EOTF (gamma correction)"
Stop using the term "gamma correction" incorrectly. It hurts.
Oh you're right, the exact quote should be:
"That the result is "gamma-corrected" doesn't necessarily mean that only the gamma curve was applied to the linear scene"
You give me great definition. But I knew it. The question stands, why you say that EOTF is just a part of gamma correction? What is the other part(s)?
I insist to call gamma correction - gamma correction, and tone mapping - tone mapping, according to their definitions. For the sake of clarity, that's all.
"You give me great definition. But I knew it. The question stands, why you say that EOTF is just a part of gamma correction? What is the other part(s)?"
Go read Poynton's Gamma FAQs and read again the other links I sent you. This time carefully instead of just scanning for 2.2 to make a point.
Read about Rec.709 and BT.1886 and see how your "it's only 2.2" or even quoting that it's slightly tweaked 2.2 gamma and generalizing what "gamma correction" means out of context is wrong.
Until you get that it is pointless to keep revolving around this.
Man, I can't get to Poynton's page. I wish I could, and will be trying. And I think I know where your problem is. Maybe you think, that gamma correction as a term just means applyin 2.2 curve? Well, no. And I don't recall saying that. I even said that gamma is set to 2.2 in most cases. Sure, I should've said, approximately, Again, I wasn't precise enough, but already apologised for that.
sRGB, Rec. 709 and BT 1886 EOTF's are gamma corrections. Not part of it. BTW you seem to mix definitions the way that suits you at given moment. Up untill now we were discussing sRGB CS (or so I thought), thus I only mentioned sRGB gamma, or gamma set at 2.2, which is close, but no exactly the same (but we already know that right?) The fact, that for different CS your gamma curve looks different, doesn't change the point. It's gamma correction that prepares linear image for display.
For almost every of my last question I ask you, your answer is, go read, you're undereducated. But I'm starting to get the feeling, you don't fully understand what you're talking about, and start lacking arguments. And, please do me the same favour you asked me in your previus post. Quote me precisely, don't take quotes out of your hat. I never wrote "it's only 2.2".
Anyway, all good to you.
Oh, and sorry, I again didn't see your previous answers. I don't necessarily agree with them, but don't think there's any need for doing this anymore :-)
Can't get it to work...
Filmic is working fine. Adding this in the way it is stated in the video didn't get the desired result.
It might be the indentation
I'm using notepad++ for editing....
What editor is used in the tutorial?
I did get it to work, i used Bracket (adobe free soft), for copy pasting. Only the Gamma and Exposure wont work with the LUTS. I still need to check if all indents are correct. It looked fine after copy paste but who knows.
I do find these really flat, the filmic look has already a sort of retro look to it.
Thanks! I'll try that route.
Don't do this.
It breaks fundamental concepts with the Filmic set and is effectively just poor Instagram filters.
Would you care to elaborate?
It's just a basic CM concept: LUTs just blindly translate numbers, but that doesn't mean that transforms are colorspace agnostic.
If you're for instance applying a 1D LUT from linear to whatever non-linear tone curve, your input has to be linear for the results to be correct.
When you apply a 3D LUT for converting between colorspaces or just applying looks, the result will be only correct only if the input is the expected by the transform.
So, in this particular case, a film emulation look should be designed to work with Filmic in the first place.
But it doesn't even end there: what's the output? Are we emulating the response of certain film stock on our log image, or are we trying to replicate the look of an already processed footage shot on that particular film stock?
That's the difference between a proper film emulation and "just an instagram filter".
TL;DR: Running those looks that weren't designed for Filmic (and not for sRGB either, iirc) on the output of Filmic is as good as any random color grade. It's not proper film emulation and the stock name given to each look is meaningless.