That Rec.709 red is not even close to red. More like dark orange.
AgX is an output transform, not really a color space per se. In fact, you can use it on top of the ACEScg rendering space if you want. The reason why it is used instead of the ACES output transform is because the ACES one is surprisingly bad. If you feed a sufficiently bright/saturated color into it, it will skew hues to totally different ones you never input, or just hard clip things to a solid color. AgX has some different approaches to try and avoid these errors.
That other linked thread is long, but well worth a read. You might also want to give this page a read, it goes into some detail (with examples) of the problems with the existing ACES output pipeline: https://chrisbrejon.com/articles/ocio-display-transforms-and-misconceptions/
And again, if youâd like to use the ACEScg color space for rendering or textures, you can do that within the new AgX config. (Using it as a render space will require hand-editing the OCIO config file to change the space definitions for the scene_linear and rendering roles, but it will work if you do change them)
Thank you! I have to confess color spaces, output transform and such are definitely something I still need to properly understand. I will have a look at the thread and link you provided, hopefully thatâll help me understand better
AgX on my HDR screen has the best colour range out of all the tests shown in this thread. The details are completely blown out and oversaturated with the other methods, including Filmic. In terms of realism the lightest areas should be less saturated than the shadows and in this regard AgX passes with flying colours. Itâs also easier to edit the images in softwares like Photoshop when the details are no longer lost from overblown lighting.
Looks great honestly.
This was a choice to counter the Abney effect:
If you simply mix ever more white into a color, the path towards white it will take âcurvesâ in terms of the hue.
Like, for instance, that blue portion goes kinda purplish.
In order to attempt to fix that curve, some twisting was necessary.
Yeah thatâs an important part of it: AgX will map to something that has more detail, simply because you avoid the Notorious Six problem. This also means, itâs easier to push the image further. So if you really need the more saturated look, you can always post-process it further.
Once stuff is clipped, it stays clipped. Can not be helped.
Like, if you compare these two:
Sure that magenta cube in the middle near the camera is MUCH more colorful in the Filmic version. But also note, that the top faceâs implied shape feels off. The visually apparent edge on the top left front side of the cube does not follow the same profile as basically all the other cubes. Thatâs because that location is essentially clipped (or Notorious-Sixâd) beyond repair.
In addition to just looking better in most reasonable situations, AgX will be easier to use as a starting point for compositing as well!
Note, unlike Rec.709, Rec.2020âs red is literally spectral. Itâs far more saturated. Proceed with caution.
(Though this does demonstrate, that AgX can, in fact, handle spectral colors decently as well)
Iâm glad you like it but just to be clear, AgX does not really deal with HDR yet. There is discussion about supporting HDR already. Some of the issue with truly doing that is, that there are conflicting HDR standards right now, and in order to get something that works for everybody, we kinda have to wait a bit for the dust to settle. Itâs, at least to some extent, a chicken-or-egg type problem.
There are other challenges as well as far as I know. But HDR is, at least in principle, on the radar.
I get that everything is a compromise, and the old color systems are still available, but traffic lights look like trash in agx:
When Filmic came by default I complained about missing details and dull colors. Now we have AgX by default⌠I think Iâm not going to complain anymore because Iâm afraid that the next change they choose will be to get renders only in gray scales by default.
To me Medium Contrast looks closer to Standard appearence in the darker area,higher contrast makes the shadows even darker.The Base Contrast is the same as None look.
Numerous complaints can be explained by the fact that you canât just continue using the color values you utilized in Blender Internal or in Yafray back in the day. Albedo values and lighting values now play a very important role in whether your imagery actually sees improvement or looks worse.
An example with the lighting values, it used to be that the sunlamp looked nice and bright with a value of just 3 (in Cycleâs early days), but this is wrong (because it has to be much higher than that, but I could not set it higher because my albedo values were often at 0.8 or above in line with legacy workflows).
If you want legacy lighting and shading, change the color transform in your startup .blend to standard
and forget about the other options.
Cool, no concerns with albedo or sunlight. What about the extreme differential in emissive colors?
Real traffic lights arenât that bright.
(And modern ones with LED lights might actually produce spectra that go beyond sRGB in purity, so they also would be more saturated to begin with. Not sure about that part though, and ymmv depending on where you live and how new those traffic lights are)
There was the hint dropped in the Filmic thread that AgX will really see its full potential once Cycles becomes a Spectral Engine (which should help with emissive coloring and anything involving very high saturation).
Cycles in version 4 will still be RGB-based.
How about TVs?
This is the SMPTE color bar test:
I definitely understand avoiding the ânotorious sixâ in oversaturated colors, but sometimes, I actually want to show those colors, and itâs very very difficult to get those colors to show up at all under AGX.
If you stay in the lighting range of 0-1 then Standard is still the best option before it starts to clip.
AgX can shine at very high light range as HDRI and real sunlight range scene ect.
Every lightrange above 1 is clipping with Standard,then comes AgX or Filmic into play for this desaturating highlights and compression curve.
It seems some people donât understand that standard and filmic are still there. AgX is not better. Itâs better sometimes for specific situations. For the other times, use what you have been using.
Which one is the default doesnât matter as long as the community does itâs job and teaches people how to save their startup file.
Just providing some context, to do my job as a community member, that in some situations, AGX is a terrible choice. Some of these comments make it sound like a slam dunk, one click solution, but it isnât.
I wonder if Troy knows if it would be possible through OCIO to let Cycles manage how color is transformed on a per-shader basis (so as to ensure the notorious six becomes a non-issue from now on while still allowing very bold colors in emissions).
Right now, Blender color management settings are applied globally, which as it appears stands in the way of âthe solution that rules them allâ.
I think per shader is a bad idea,because in every Renderengine i know the internal calculations as lighting are always linear.
Tonemapping as Agx are on top afterwards to form the image for your output medium.IE from HDRI footage to rec709 sRGB that you can display your HDRI content on a Standard Monitor if that makes sence.
Maybe if it would possible at some time,that you can control the Dynamic range of the Tonemapping curves for yourself.Maybe you need only the range from 0-5 and not the whole -12 to 12 (IIRC the Filmic range)
then you could adjust the curve more to your needs.
But this would something against a âStandard AgX tonemappingâ for compatibility.
From what I understand, OCIO is only done on an image basis. So, textures going into a renderer, or a final image/viewport coming out. Also, as far as Iâm aware, having any sort of lighting calculations done in a space that is not scene referred is going to break a ton of math. It is probably better to keep all renderer calculations in scene referred space, and then do the transformation at a later stage/after the final pixels are rendered.
I donât think a per-shader solution makes sense (nor think is really possible, OCIO acts on a view)⌠this is a job for the compositor! For example, one can easily add saturation to the TV in the render above, if necessary.