While trying out these new workflows a few new questions came to my mind:
1. Is it possible to use LUTs on top when using OCIO? Maybe some custom one, so the LiveViewer/IPR better represents what I'll be getting after the PP
2. What's the difference between Response and LUT? To me it looks like they both do pretty much the same thing.
3. Let's say I am using default Octane color management. What is the best way to control roll-off of the highlights and contrast? Tried all of these default/custom Response types and LUTs, but it looks like most of them add some funky colors as well, which I don't like. I just want to adjust highlights/highlight roll-off and contrast.
ACES way to control how much the highlights gets compressed?
Forum rules
Please add your OS and Hardware Configuration in your signature, it makes it easier for us to help you analyze problems. Example: Win 7 64 | Geforce GTX680 | i7 3770 | 16GB
Please add your OS and Hardware Configuration in your signature, it makes it easier for us to help you analyze problems. Example: Win 7 64 | Geforce GTX680 | i7 3770 | 16GB
-
MantasKava
- Posts: 36
- Joined: Fri Nov 20, 2015 4:01 pm
It would break if I would bake it/export it with LUT applied, but that's not the idea. The idea is to only use that LUT for LiveViewer/IPR while look dev'ing. No? Reason why I'm asking this- I really like AgX's look/how it deals with highlights, but I feel like it kills/flattens the highlights maybe a little too much even (just like ACES). And custom LUT could help here I believe? Or what's the other options I have? to keep the AgX OCIO/workflow, but make it so it doesn't compress the highlights THAT much.This also goes against the purpose of OCIO. Doing so will break the imagery.
I found with AgX I have to increase my exposure from 1.5 to 4.0 to make my white-colored materials (srgb 220) look white (and not grey) again. And after increasing the exposure that much, all the contrast is gone, which makes the image very flat.
Also, I updated my previous comment with more questions:
While trying out these new workflows a few new questions came to my mind:
1. Is it possible to use LUTs on top when using OCIO? Maybe some custom one, so the LiveViewer/IPR better represents what I'll be getting after the PP
2. What's the difference between Response and LUT? To me it looks like they both do pretty much the same thing.
3. Let's say I am using default Octane color management. What is the best way to control roll-off of the highlights and contrast? Tried all of these default/custom Response types and LUTs, but it looks like most of them add some funky colors as well, which I don't like. I just want to adjust highlights/highlight roll-off and contrast.
-
MantasKava
- Posts: 36
- Joined: Fri Nov 20, 2015 4:01 pm
Okay, help me understand what I am doing wrong then, because I am not getting that "Punchy" look when using AgX (OCIO View set to Punchy).
From what I know, RGB values (non-linear) for the brightest whites should be at rgb ~234 max, and rgb ~30 for the darkest blacks, that is for the brightest and darkest materials in the world (with maybe some rare exceptions). Keeping that in mind, let's say that usual white painted wall albedo value should be at rgb ~220, and black painted wall at rgb ~40.
And here's HDRi (HDRI created by Jorgen Herland, he knows his stuff) lit scene that I use for look development for many years now. And there are two cubes in the scene, one with albedo at 220, and another at 40. Now for the wall (for example) to look like it's nice/bright white painted wall, it has to be somewhere in 210-220 values. But here in the screenshots bellow you can see black cube's values are alright and it looks as black as it should be, but the white one is way under exposed, ~180 rgb only. I know the values I've entered for materials/albedo are correct, but there's still a problem, white cube isn't white at all.
Now how do I brighten midtones/highlights, but keep shadows as they are? I can't increase the exposure because blacks will become grey, and same problem with increasing power of the light source of course.
And even if I increase the albedo value to 234, it only gets to rgb ~190 in the LiveViewer. Values of 230-240 should be left for the world's brightest materials only, and not a simple white painted wall I am creating here.
Red dot is where the color values was picked from
From what I know, RGB values (non-linear) for the brightest whites should be at rgb ~234 max, and rgb ~30 for the darkest blacks, that is for the brightest and darkest materials in the world (with maybe some rare exceptions). Keeping that in mind, let's say that usual white painted wall albedo value should be at rgb ~220, and black painted wall at rgb ~40.
And here's HDRi (HDRI created by Jorgen Herland, he knows his stuff) lit scene that I use for look development for many years now. And there are two cubes in the scene, one with albedo at 220, and another at 40. Now for the wall (for example) to look like it's nice/bright white painted wall, it has to be somewhere in 210-220 values. But here in the screenshots bellow you can see black cube's values are alright and it looks as black as it should be, but the white one is way under exposed, ~180 rgb only. I know the values I've entered for materials/albedo are correct, but there's still a problem, white cube isn't white at all.
Now how do I brighten midtones/highlights, but keep shadows as they are? I can't increase the exposure because blacks will become grey, and same problem with increasing power of the light source of course.
And even if I increase the albedo value to 234, it only gets to rgb ~190 in the LiveViewer. Values of 230-240 should be left for the world's brightest materials only, and not a simple white painted wall I am creating here.
Red dot is where the color values was picked from
elsksa, you have huge amount of knowledge. But this knowledge is only knowledge. I tried and lost huge amount of months to test some things. Colors, Aces, OCIO. All of the things as you said is only theory. Every scene is different and trust me - I had scenes that looks totally wrong using ACES. Of course you can repair everything - but why to repair ? Final render should looks as good as possible.
Most of the OCIO going to compress highlights by different way and also brighten or darken shadows ( for example Blender contrast filters ) - all of this can be done simple in Photoshop Camera Image using 16bit rendered image. Only good way to use these OCIO in Octane is that you have real live view of what final image will looks. Of course there are different gamma changes in RGB but all of this can be done using simple LUTs in Octane.
There is no any difference using standard Luts in Octane Camera Imager than using OCIO or ACES in final image. Maybe 5% of people can find any difference.
Most of the OCIO going to compress highlights by different way and also brighten or darken shadows ( for example Blender contrast filters ) - all of this can be done simple in Photoshop Camera Image using 16bit rendered image. Only good way to use these OCIO in Octane is that you have real live view of what final image will looks. Of course there are different gamma changes in RGB but all of this can be done using simple LUTs in Octane.
There is no any difference using standard Luts in Octane Camera Imager than using OCIO or ACES in final image. Maybe 5% of people can find any difference.
Architectural Visualizations http://www.archviz-4d.studio
I'm not only who see ACES problems :
https://www.facebook.com/groups/OctaneR ... 5034964229
ACES produce low-dark areas very dark in Octane LV. Working with ACES cause to make post processing. If you want proper view in LV you must rewrite all materials.
ACES produce low-dark areas very dark in Octane LV. Working with ACES cause to make post processing. If you want proper view in LV you must rewrite all materials.
Architectural Visualizations http://www.archviz-4d.studio
I feel something that is missing is a list of the most common workflows and their advantages and drawbacks. Including the workflows considered wrong.
For example one common workflow is to save as non-linear sRGB to 8-bit PNG and apply further color and contrast adjustments manually in Photoshop before exporting to JPG.
Although it's "wrong" and loses a lot of data it's very common and the shortcomings should be documented.
Another workflow is the same but with a Response curve or LUT applied directly in Octane. The limitations of doing this should be clearly outlined somewhere. The advantage of this approach is you can work on the scene with something that is close to the final look and limit external post processing. Assuming the result doesn't need to be composited with something else.
Another typical workflow is to save to linear sRGB as 16-bit EXR and do color grading somewhere else.
Same for OCIO-based workflows.
Not everyone has Nuke or a dedicated colorist and many scenes aren't going to be composited with anything else in which case the output of Octane is close to the end of the pipeline.
For example one common workflow is to save as non-linear sRGB to 8-bit PNG and apply further color and contrast adjustments manually in Photoshop before exporting to JPG.
Although it's "wrong" and loses a lot of data it's very common and the shortcomings should be documented.
Another workflow is the same but with a Response curve or LUT applied directly in Octane. The limitations of doing this should be clearly outlined somewhere. The advantage of this approach is you can work on the scene with something that is close to the final look and limit external post processing. Assuming the result doesn't need to be composited with something else.
Another typical workflow is to save to linear sRGB as 16-bit EXR and do color grading somewhere else.
Same for OCIO-based workflows.
Not everyone has Nuke or a dedicated colorist and many scenes aren't going to be composited with anything else in which case the output of Octane is close to the end of the pipeline.
Orginal :
ACES :
Camera Responses, Lut's, Exposure, Gamma, White Point magic all inside Octane :
ACES :
Magic in Octane :
Architectural Visualizations http://www.archviz-4d.studio
Aces simulation with Camera Response + Lut :
Left -> Camera Imager, Right -> ACES
Near 98% the same blue and green tint using Teigen28 cube but different settings :
Near 98% the same blue and green tint using Teigen28 cube but different settings :
Architectural Visualizations http://www.archviz-4d.studio
At last I found final solution to use ACES in all lighting conditions in Octane. It produce perfect equalized gamma and vivid colors as should be. Without dark, shadow clipping areas. And all of that saved using native ACEScg file.
The problem : ACES was developed for real cameras which works in real lighting conditions where outside light intensity produced by direct sunlight or scattered light in atmosphere is hard to achieve without exposure system which works only for point of view or averaging whole view.
This is why images or film stored be real cameras works fine with ACES. In computer generated images where we works with artificial light conditions especially architectural visualizations ACES produce very dark and even clipped ( RGB 0,0,0 ) areas.
I think that CGI generated skies like Hosek&Wilkie or HDRI maps are not compatible with ACES system.
Solution :
To compensate darkness there is need to crank up sky power to values near 8 but it produce problems with materials.
I found that for ACES default Hosek&Wilkie values are wrong. Strenght of Sunlight should be much lower than power of Sky. This will produce much less dark shadows and overall brightness would be better. But this is not final solution.
The best is to crank up camera exposure by 600-800% and lower overall Sun and Sky values by 70-80%. This will produce perfect equalized gamma with great highlight compensation without any badly darkness but still with the most darknened areas at RGB 0,0,0 where they should be.
For example. When I use for my most strong sunlight exteriors Sky power at 4 and Sun power at 1.25 I must crank up camera exposure to 6-8 and lower Sky power to 1 and Sun power to 0.5-75 to make ACES looks perfect. Without changing any material parameters.
The problem : ACES was developed for real cameras which works in real lighting conditions where outside light intensity produced by direct sunlight or scattered light in atmosphere is hard to achieve without exposure system which works only for point of view or averaging whole view.
This is why images or film stored be real cameras works fine with ACES. In computer generated images where we works with artificial light conditions especially architectural visualizations ACES produce very dark and even clipped ( RGB 0,0,0 ) areas.
I think that CGI generated skies like Hosek&Wilkie or HDRI maps are not compatible with ACES system.
Solution :
To compensate darkness there is need to crank up sky power to values near 8 but it produce problems with materials.
I found that for ACES default Hosek&Wilkie values are wrong. Strenght of Sunlight should be much lower than power of Sky. This will produce much less dark shadows and overall brightness would be better. But this is not final solution.
The best is to crank up camera exposure by 600-800% and lower overall Sun and Sky values by 70-80%. This will produce perfect equalized gamma with great highlight compensation without any badly darkness but still with the most darknened areas at RGB 0,0,0 where they should be.
For example. When I use for my most strong sunlight exteriors Sky power at 4 and Sun power at 1.25 I must crank up camera exposure to 6-8 and lower Sky power to 1 and Sun power to 0.5-75 to make ACES looks perfect. Without changing any material parameters.
Architectural Visualizations http://www.archviz-4d.studio
-
sethRichardson
- Posts: 95
- Joined: Thu Feb 27, 2014 2:16 am
SSmolak wrote:At last I found final solution to use ACES in all lighting conditions in Octane. It produce perfect equalized gamma and vivid colors as should be. Without dark, shadow clipping areas. And all of that saved using native ACEScg file.
The problem : ACES was developed for real cameras which works in real lighting conditions where outside light intensity produced by direct sunlight or scattered light in atmosphere is hard to achieve without exposure system which works only for point of view or averaging whole view.
This is why images or film stored be real cameras works fine with ACES. In computer generated images where we works with artificial light conditions especially architectural visualizations ACES produce very dark and even clipped ( RGB 0,0,0 ) areas.
I think that CGI generated skies like Hosek&Wilkie or HDRI maps are not compatible with ACES system.
Solution :
To compensate darkness there is need to crank up sky power to values near 8 but it produce problems with materials.
I found that for ACES default Hosek&Wilkie values are wrong. Strenght of Sunlight should be much lower than power of Sky. This will produce much less dark shadows and overall brightness would be better. But this is not final solution.
The best is to crank up camera exposure by 600-800% and lower overall Sun and Sky values by 70-80%. This will produce perfect equalized gamma with great highlight compensation without any badly darkness but still with the most darknened areas at RGB 0,0,0 where they should be.
For example. When I use for my most strong sunlight exteriors Sky power at 4 and Sun power at 1.25 I must crank up camera exposure to 6-8 and lower Sky power to 1 and Sun power to 0.5-75 to make ACES looks perfect. Without changing any material parameters.
Ya but at that point, you have moved so far away from those models and what makes them realistic that getting good repeatable results as you would with a photographic approach is out the window.
Aces is overrated and for most artists just a plain bad idea. And you illustrated a very good reason as to why it's bad. It's not just those sky models either. It's blackbody lights, gaussian spectrum lights.... those all are incorrect in aces. You get a far better more real result out of a filmic ocio plain and simple.