But you can’t make it easier either.
All of this is superficial band-aid, it doesn’t change the fact that beginners need to walk through the valley of suck until they start to understand things.
Because path-tracers are build around the idea of replicating reality (or photographic media).
Think about the inverse of your example, a newcomer who absolutely wants to do photo-realistic stuff.
No matter how you twist and turn it, somebody will suffer because of it.
This is a case where you can’t make it right for everybody.
That was a general statement, it does not apply here.
I don’t even know why I am discussing this, I have no horse in this race.
I export all my renders into EXR’s and use neither filmic, nor AGX or ACES.
Maybe it could be worded differently. Because that is not a problem, that is intended functionality you are complaining about and this is a bug report. It should be a feature request maybe on Right Click Select. We should suggest color inputs to support different color spaces same way image inputs do.
That’s true. It’s a bad idea unless one uses standard sRGB transform. With AgX and Filmic that’s definitely a bad idea. In case of standard transform it’s only probably a bad idea because of other reasons.
About the colorpicker.With the OCIO managment you can set the rule for the colorpicker,means you can set the colorspace or sRGB iirc (have to look what rules you can choose)
edit ,from the CM doc
color_picking
Defines the distribution of colors in color pickers. It is expected to be approximately perceptually linear, have the same gamut as the scene_linear color space, map 0..1 values to 0..1 values in the scene linear color space for predictable editing of materials’ albedo.
From the OCIO config
The RGB and HSV are scene linear in the picker,and the HEX values you put in getting gamma corrected like sRGB images into the shader.
You can colorpick from a sRGB image or put into the HEX field the sRGB numbers and it gets automaticly gamma corrected for the linear space Blender uses internaly.
Example,if you put 808080 into the HEX field for sRGB colors,it gets internaly gamma corrected for linear rendering.
But keep in mind that you have sRGB transform for the Display Device
You can take the emissive shader and for simplicity just increase one component, like red and check what the resulting color it is. As you make it brighter, it will drift towards orange, then it moves back.
This happens with everything you start with, but it will happen at a different brightness, not all of them will drift equally.
And just to be clear, this is the thing I have been talking about the whole time!
That was very poorly worded by me. I have read that AgX tries to replicate some real high end camera stuff. I have never experienced a camera which produces such a strong hue shift when the brightness of a color is increased. And of course, I am not doing high end stuff, I don’t use the raw output or anything like that.
I have been working on projects where we had to decide whether the sRGB output was good enough for our purpose and we did some testing with varying brightness because of that and from that I know, the hues didn’t shift dramatically. Neither in real life, not in the sRGB output.
Edit: Maybe the amateur level cameras we used some transforms which corrected for that, who knows.
You keep on repeating the same thing over and over again about AgX shifting the hues – If you wanna keep the hue while increasing the intensity AgX is actually the only option that works. This was one of the goals of the whole AgX project. Standard sRGB and also Filmic (and also ACES for that matter) will not preserve the hue at all. Leanard Siebeneichers test show this very well too:
If you don’t develop using raw, you’re just letting the camera develop the raw files for you, using their (bad) presets, which will recreate the digital artifacts that AgX tries to avoid. Stuff that in edge cases like concerts results in horrors like this:
What I am saying is: the jpg a digital camera produces is not the standard one should aim for, nor a good unit of measurement for a desirable output.
However, my eyes were not able to perceive a dramatic hue shift in real life and were not able to perceive a dramatic hue shift in the final images.
But, it exists after using AgX transforms…
That is a compromise AgX has with the deAbney.Without the deAbney the blue colors have a tendensiy to purplelish appearence with higher values and gammut compression (desaturation).Iirc the same was with the red pinkish.
Maybe @Eary_Chow can explane better what exactly happens with the correction
Fixed one thing just to break another thing in the sam way? Was it even worth it? I can see a whole industry saying “I have to fix this color shift every time I use this thing and now if I want to use this other thing I also have to fix this other color shift? Where is the benefit? I’m sticking with what I’ve already built”
But you argue that newbies are gonna be confused about hue shifts using AgX while it’s very clear to see that they are gonna be confused anyway
Standard sRGB, Filmic, ACES, AgX all have their own “shifts” somewhere.
To motion graphics and NPR people “standard sRGB” might be a better default, yes, but I would argue that the quality of the artwork that we see in this very forum increased drastically after the introduction of Filmic and moving away from standard sRGB as the default. And the discussion about that were even more heated than what we see now after putting AgX in. All options have their uses and their quirks, that’s why we have them as options. But I strongly believe AgX is a good default.
I do understand your problem though, and I’m not saying it’s not valid, because it is!
It will also be a problem for Mattepainters for example who paint details in Photoshop (in sRGB) and re-project it back into the scene. Suddenly it doesn’t match anymore and that is a problem as you probably aim for a 1:1 match. One way to fix that with Filmic is like this:
Let’s say this is our sRGB texture: (note the near-white highlights)
All the beautiful highlights are dull and grey.
There is a way to fix this tough. Just set the input texture to “Filmic sRGB” and it will roughly match the original sRGB visually when going through a Filmic pipeline:
What this does is (as far as I know) it pushes your white (=1) from your sRGB texture to some high value (~13) in order to survive Filmics treatment and come out as “white” (1) again. Kind of a reverse operation to Filmic for your input.
Thanks to our amazing devs the same also works for AgX:
Here a comparison of the corrections AgX vs Filmic none look
-10 to 15 stops
can you see that AgX has less Abney effekt vs Filmic (less purplelish in the desaturated highlights?)
No it’s not, I was talking about a matte-painting/environment workflow where you either project a painted patch ontop of geo in normal 3d environment or use a painted sky as a backdrop. I would still want a realistic looking environment and not that total unusable crap that standard srgb gives me. If I want to use Blender as a replacement for After-Effects to do motion graphics, sure, then standard sRGB is the better default. But I’ve stated that above already.
