I thought we were talking about defaults…
Filmic and AgX are mostly usefull with highdynamic range lighting,to avoid clipping that occour with standard CM.
On the left Standard view,right side AgX
6 Likes
you are building your own pipeline that might not be consistent in different apps and footage types
If you point your camera towards the sun the color channels start clipping then go to white ; you can try to do this your self with srgb but jumping to diff programs might not give you the tools to be consistent.
Filmic log was to be the so called work horse, because you don’t need the luts (which is available) to grade it (to much for beginners) in a decent program.
Blender fumbled the ball when switching to filmic by not giving us better color management tools. Now that we at least have the colorspace convert tool they plan to switch to acescg pipeline. Colormanagement tools will stll be important because ocio will allow people to choose their pipeline.
Having additional looks is for filmic would not have been a bad idea , but it might be to late for that. The creator has moved on to working on something better and filmic might stay around in blender for compatability (if even)
the previous film looks were removed because they were meant for a specific color and transfer function input to be correct , so they landed in the realm of creative looks use in blender (nothing wrong with that , but people didn’t know)
Iike I stated, they plan to change from filmic as the default, so no need to worry about for those that don’t like it. Just fight for more color management tools in blender
The main issue with using a compositor to do the fixes yourself in post (Addressing all users here).
Is that you are using a compositor to do the fixes yourself in post.
Until we will have a compositor that can handle such things in real time, We are playing a guessing game on how things will end up looking, As mentioned, Rendering takes time, And you may need to give the scene another render since you will no longer have the information you need to work on in post (An obvious example is rendering with bad lighting)
- Remember, once you render, it becomes an image and that’s what you get to work with, *Yes, even under EXR in linear space, some coloring and lighting issues can not be fixed unless you adjust your scene and re-render).
I still don’t get the issue here in this topic its all about (I could easily create a discussion called : “Standard as default is hurting users experience”). but i am happy that color management is getting attention.
I read your new comments, you really added an new approach to the topic and this is so smart, you are really good. Thank you for the practical info that is really useful. I ll give it a try to ur approach,
1 Like
What do u mean by ‘‘m current version of AGX’’? Have u made some changes to AGX (Troy Sobotka’s Github version)? What kind of changes did u do if u did? I just wonder
I made a lot of changes. Though the latest ones are inspired by Troy posting his new results.
You can try it out if you like:
Ahh I just noticed eary_chow in BA was you. Thank you I will check it out.
By thee way, Changes are just about the LOOKS side of things like adding new files to LUT folder and adding them to config LOOKS section OR changes are made for the AGX’s view transform and other things in config file?
(Edit: Yes I saw the changelogs in github, so I guess the answer is both)
And where can I find Ur AGX with v11 because AGX v11.9 in BA comparisons look so saturated, I prefer less saturated. Would u mind providing link for v11 as well? The link u sent me is v11.9 or is it a higher version than v11.9 that revert back to BT.709?
(as far as ı read BT2020 cause saturated colors, I think it removed the benefits of AGX on making the abney effect and de saturating highlights that gave detail and contrast and more differentiation to small highlights on scenes)
I plan to release a v12 soon, but for the moment just download it directly from the main repo.
I tried BT.2020 working space and because Blender currently doesn’t have backwards compatibility design for working space change, the RGB inputs are not properly converted. After some negative feedbacks I decided to move back to BT.709 working space for now. The main repo is already back to BT.709.
Ahh thank you. so the last link u sent here is some kind of v12 release
Yes I agree, 709 looks fine I think, not a bad decision
That was a long and weird discussion to read :o My two cents, probably too late ¯\_(ツ)_/¯
Noobs will do weird and wrong stuff no matter what. Considering that the current average Blender noob is probably rendering for tens of hours a plastic donut in 8k resolution and 3 samples because denoising exists (exaggeration intended, but not far-fetched). IMHO, values should be chosen for the target user of the software. Blender aiming to be a production suite, it makes sense to set it up that way. User-noobyness is quite low in the priority for changing the default values of a production software when it’s not something harmful (like unwanted data loss or crash).
Experienced users can make their own jam whatever the default values. Some might prefer Filimc, some sRGB, some install completely different color management. What’s the best default in that case? sRGB? Filmic? Another like ACES? Who knows. The BF chose Filmic, it suits some people and not others, so what? So did sRGB and so would any other one.
Arguing about whether you can make good pictures in whatever color management sounds kind of irrelevant to me.
Even with the right tool, most people will still not use them to their full potential. Even in high budget productions with experienced staff and enough time to do their craft, weird things make it into the final cut. And, for the average creator/consumer, they don’t really make the difference, sometimes not even if you point it out for them with a magnifying glass and 1:1 comparison.
Then, we didn’t wait for the existence of high bit depth images and color management to be able to make good images. You could make the same kind of weird arguments with any technology that came after another. Raytracing for example, we didn’t wait for that to be able to make realistic renders on scanline renderers and whatnot, shall we now say that Cycles as default is therefore hurting people because way longer to render and requires a master’s degree in physics?
Outside NPR and video games industry, so far I haven’t heard of many modern CGI production that worked in sRGB, I definitely know a few independent people making their own content this way, but mostly because they do it all from start to delivery in Blender, and/or don’t care much. So my guess is that, there are users for both, and it’s up to the BF to decide which public they want to aim first.
At the end of the day, the artistic freedom is in that we have plenty of tools, each with their own potential and limitations, and we can chose to work with any we want at any time.
That was my two cents. Sorry for the long bloc’o’text.
On another note, where does Agx come from? I started hearing about it around a week ago but I can’t find much information about it. Is it Troy’s new thing, or some CM from a company, or…
3 Likes
Originally came from Troy’s idea to make a Filmic v2 (AgX is the name of a chemical used in Film photography, so AgX the name is like an alias of Filmic). He mentioned that back then when he was making Filmic, the users back then were so attached to sRGB inverse EOTF that they were pushing against things that are not similar to the sRGB transfer function (ironically this thread is entirely a reincarnation of that). So he made Filmic to be similar to sRGB inverse EOTF, it was a compromise at the time, and we are now trying to make something better. Note AgX is still just considered as a “middle step”, as hopefully something even better can appear in the future.
So Troy’s version was the original AgX, I have a version of AgX that I hope one day can get merged to Blender master. We are still exploring though.
2 Likes
Thanks for the info. I have yet to spend more time trying it, but at a glance it looks intersting. Keep up the good work!
Its a reincarnation of tread somehow, but still my point on this tread was different I am not against new things but just little bit options make things flexible, for example many softwares has filmic highlight compression amount slider or such features so user can decide how much highlights are compressed by filmic etc
So while developing the AGX because u said u want to make ur version into master, can u keep that in mind to add some alternative looks or secondary transform options (u know the terms better than me, dont mind my terminology) like for example (naming can be different , its just example)
‘‘Agx - Less compressed Highlights & Enhanced Whites A’’
‘‘Agx - Less Compressed Highlights & Enhanced Whites B’’
because sometimes u want highlights to explode or look more white+clipped rather than grey, like in old imperfect cameras or old movies or bad encoded videos , flawful cameras or just artistic need etc. I would be happy if u add it as a other look or mode while making AGX (without hurting anything in agx)
I am confused what “less compressed highlights” means, and no idea what is “enhanced white”.
Maybe you can try out the high contrast looks? The higher contrast looks in my AgX does increase the “white” area’s coverage, if that’s what you mean. (Though the black parts also grow at the same time.)
What i mean by less compressed highlights probably is about increasing highlights selectively with minimal effect on shadows or midtones or like having more clipping ?
Enhanced white is increasing white coverage without affecting black parts so whites looks enhanced and its proportion with darker values changes? does it make sense?
or none of these mean something, can we add one more contrast look like extra high contrast?
In config looks, using CDLtransform doesnt allow for only pushing values of white or selective highlights up selectively, so I wonder if there is a function on OCIO to do that as put in the LOOKS ?
NOTE: I ll try to explain again when I find a better explanation to achieve that look , Nevermind the things I say because I will be back when I find a better explanation
EDIT: and I found…
I tried to explain with curves before but troy said curves in blender is broken, so I did the same thing in other software which probably doesnt have broken curves:
If we explain by curves, its like ‘‘adding contrast to highlights’’ by creating a kind of BUMP at close to white highlgiht values OR S-CURVE to make highlights-close-to-whites more white by increasing it , while reducing or keeping same the value of highlights below the area that is increased
or at worst , if I find a way to achieve that look by using OCIO by finding another alternative to CDLtransform and make a LUT I will try to share with u.
If u also know, can u let me know if there any curves-transform function similar to CDLtransform in OCIO that I can use to add it as parameter to create LOOKS on config ?
It’s interesting that vertically it stays clear, but notice the horizontal-wise clipping, you cannot tell the difference bewteen a lot of blocks, like the oranges and the yellows and greens, in real 3D scenes it means you will not be able to tell apart two sides of faces lit with different strength of lights.
Also the end transition to solid white is not smooth, in real case it will seem like a posterization.
My current version for reference:
1 Like
oh yeah, back to the drawing board.
@MC-Blender Here’s a transform node to put in the compositor which can be changed between perceived brightness mode and filmic or somewhere in between. It also can desaturate filmic based on perceived brightness too + a contrast slider. It’s pretty basic but should be quite fast. Make sure you leave the render view transform as standard, because it transform to filmic in the compositor so that you can then tweak the result afterwards without the filmic continually changing your values.
filmic without perceptual desaturation:
With desaturation:
Perceptual for a bit more brightness:
Or because the filmic is applied in the compositor, you can brighten it up manually afterwards however you like without any interference from the render panel’s view transform:
perceptual (less reduction of saturation because cycles does this automatically, but still handy for other engines)
filmic with a bit of contrast:
Here’s the blend file if it’s useful to anyone: comp transform1.blend