Isotropix Forums

Aces

General Discussion about Isotropix and CG related topics

Re: Aces

Unread postby vandam » Mon Jun 22, 2020 3:12 pm

I used to work in gamedev for some time, we had ACES implemented in the engine, did not use it though (too heavy for current gen consoles and the project we worked on), but I did play with it and I can tell - there was a huge visual difference when ACES was on. But I guess it depends on lots of things that I might not have the knowledge to talk about
vandam
 
Posts: 150
Joined: Wed Jun 21, 2017 9:22 pm

Re: Aces

Unread postby t_b_s » Mon Jun 22, 2020 6:29 pm

kirkr22 wrote:I wonder specifically about what many papers about ACES state as a way to reach more photoreal results doing more realistic GI, solving color oversturation etc. Including https://chrisbrejon.com/cg-cinematograp ... stem-aces/
link oddvisionary posted. Those are problems I am talking about.

These are still vague statements, "more realistic GI", "solving oversaturation", what is that supposed to mean? If you quote specific claims we can discuss if they are correct and if they are relevant for your work.

ACES is a technical process, it addresses specific problems in color management, the ones I described in my previous posts. If you don't have to deal with these, it won't do anything for you. It's not a magic switch that makes everything more realistic or better-looking. If you use sRGB source imagery, your gamut is limited to sRGB anyways, using ACEScg as working space will make no difference for you. The images will be identical in the end, except for minimal rounding errors.

The only reason why people might think that aces in itself produces better results is because it has tone-mapping factored into its display processes (RRT), which gives more pleasing results than a standard sRGB output curve without tone-mapping. But it's not that aces has invented tone-mapping ...
t_b_s
 
Posts: 32
Joined: Sat Dec 17, 2016 1:03 pm

Re: Aces

Unread postby kirkr22 » Mon Jun 22, 2020 9:24 pm

t_b_s wrote:
kirkr22 wrote:It's not a magic switch that makes everything more realistic or better-looking. If you use sRGB source imagery, your gamut is limited to sRGB anyways, using ACEScg as working space will make no difference for you. The images will be identical in the end, except for minimal rounding errors.

The only reason why people might think that aces in itself produces better results is because it has tone-mapping factored into its display processes (RRT), which gives more pleasing results than a standard sRGB output curve without tone-mapping. But it's not that aces has invented tone-mapping ...


It's basically what I think of ACES too. Thus my guess it's totally redundant in a game pipeline except ton-mapping part that doesn't necessarily have to be ACES based . As well as using wide gamut equipment in general since the difference with sRGB really is ability to display extremely , acidly vivid, mostly artificial subjects you hardly see in natural environment.

But I am not 100% sure.
kirkr22
 
Posts: 106
Joined: Sat Apr 11, 2015 3:27 am

Re: Aces

Unread postby dboude » Tue Jun 23, 2020 9:02 am

Hi,

Nothing changes except the color space

ACES
Moutain_ACES.png


sRGB
Moutain_sRGB.png


Cheers
Démian
Isotropix
Technical Artist - Clarisse Specialist
User avatar
dboude
 
Posts: 1509
Joined: Mon Jul 03, 2017 10:51 am

Re: Aces

Unread postby kirkr22 » Tue Jun 23, 2020 9:23 pm

Thanks dboude.
Aces one while having that weird reddish shift I told about and a bit more linearish look still has the sky not so overblown. I wonder is it something Aces is intended to "solve",makes better by it's nature or it's just tone mapping applied over the output that could be same way applied to sRGB render?

Like filmic look transform in Blender composer that fixes it instantly in any imported exr?

ps. What I also don't understand is why I see that reddish shift at all. Like one you would often see on a wide gamut monitors working in non color aware applications. Isn't the color management and ODT transform is supposed to transform it into perfectly sRGB colors of JPG files and both jpgs should be identical? With only those rare colors outside sRGB range i.e asid nuke vivid be somehow different?
kirkr22
 
Posts: 106
Joined: Sat Apr 11, 2015 3:27 am

Re: Aces

Unread postby dboude » Wed Jun 24, 2020 8:28 am

Hi,

Personally I use the ACES to rescale the highlights to a visible range. I'm not able to answer your other questions. Color management is like... mmm... totally hardcore to understand for me.

Cheers
Démian
Isotropix
Technical Artist - Clarisse Specialist
User avatar
dboude
 
Posts: 1509
Joined: Mon Jul 03, 2017 10:51 am

Re: Aces

Unread postby isoyann2 » Wed Jun 24, 2020 3:38 pm

f you are working with sRGB source imagery for an sRGB output device, no one would expect that you run into problems with gamut transform


It is like saying "rendering in HDR is useless if your textures are not in HDR". The textures can fit inside the small sRGB gamut, but when rendered, combined with other colors (red color bouncing on a red surface, strong colored lighting...), a wider render color space allows the "rendertime generated colors" to go way beyond the limited sRGB space, without saturation clamping, then, after another bounce, go back, with the right color, to a limited rec 709 space... so even with sRGB input / sRGB output, you get benefits.
isoyann2
 
Posts: 7
Joined: Thu May 09, 2019 3:28 pm

Re: Aces

Unread postby sam » Wed Jun 24, 2020 7:19 pm

yeah what yann said.
Sam Assadian
Isotropix
CEO/Founder
User avatar
sam
 
Posts: 1528
Joined: Fri Jan 25, 2013 11:33 pm

Re: Aces

Unread postby t_b_s » Wed Jun 24, 2020 7:29 pm

No. This comparison doesn’t hold up for a number of reasons. The majority of texture maps describe reflective or transmissive properties of an object. Since there can’t be more than 100% reflectivity or transmission, being HDR is pointless to begin with for these maps. If we were talking about texture maps for emission or the texture for IBL, we could indeed make the argument that in these cases it would be pointless to not use HDR imagery (“using LDR as HDR”) for that purpose unless we crank it up substantially in the render application. In this case I would argue, that we are still using an HDR texture, that we compressed to LDR intermediately while it was saved to disk.

Another reason it doesn’t hold up is that you give the impression that a wider gamut is generally better as a render working space than a smaller, which is not the case. You are right that there are testing scenarios in which some gamuts match better with spectral rendering than others but that still leaves questions open of how adequate the spectral rendering is to begin with and if the close match is accidentally produced by the specific scenario.

It was a bit misleading from my side leaving this part out before, but at the end of the day, the differences are so small that it is not worth depending you workflow on it. Looking through the user-content here or on the discord, my guess would be that in 19 out of 20 cases, the difference would be too small for the delivery format to handle, so the images would be, as I said, identical. An even for the one where there is a difference, it would only be noticeable in a direct comparison and no one could tell which one is the wider gamut.
t_b_s
 
Posts: 32
Joined: Sat Dec 17, 2016 1:03 pm

Re: Aces

Unread postby kirkr22 » Thu Jun 25, 2020 10:17 am

isoyann2 wrote:
f you are working with sRGB source imagery for an sRGB output device, no one would expect that you run into problems with gamut transform


It is like saying "rendering in HDR is useless if your textures are not in HDR". The textures can fit inside the small sRGB gamut, but when rendered, combined with other colors (red color bouncing on a red surface, strong colored lighting...), a wider render color space allows the "rendertime generated colors" to go way beyond the limited sRGB space, without saturation clamping, then, after another bounce, go back, with the right color, to a limited rec 709 space... so even with sRGB input / sRGB output, you get benefits.


So if the gamut would include ultraviolet we would get it bouncing too but would it be changing 99% of earthly colors that are falling in sRGB range usually? I think Aces should help with rendering correctly something super vivid colored , something nuke neon giving proper bouncing of such. But for regular earthly things how could wide gamut change anything?
A grass that is perfectly within sRGB, how could it make something bouncing of it turns ultraviolet for example? Except if light itself is 90% ultraviolet.

As of re-scaling overblown highlights into visible range. Isn't it kind of a post process that could be working with any color gamut?

Like "Filmic look transform" in Blender. It "fixes" highlights for both ACES or sRGB renders. For any exr imported actually.
And does it without any reddish shift I see in ACES renders. I bet that car in dboude renders supposed to be lemon yellow , not orange colored.
Maybe it needs one more ODT transform ?
kirkr22
 
Posts: 106
Joined: Sat Apr 11, 2015 3:27 am

PreviousNext

Return to General Discussion