ACEScg vs sRGB comparison

[piotrus3333]

I thought this might be useful for those "on the fence".
I have to say I was sceptical for quite a while. tone mapping part is nothing special, just a nice curve but wide gamut part is magic.

sRGB (E) with AMPAS
ACEScg (F) ocio aces 1.2 and exposure +1.0

[^Lele^]

There's some blue cast on the ACES image (see the ref white diffuse sphere's shadows) and the tones are quite a bit less saturated for ACES, but i can tell the range is higher (banans, apples and the toy seem to have more shape, by virtue of less crushed tones.).
How much of that is ACES, and how much is the shaper built into the sRGB display transform, is impossible to to tell, afaik (in the literal sense. there is no info on how that shaper curve is built.).

I'd love to see the original 32bpc EXR, so to check it with a higher dynamic range under HDR (say, a rec2020, or DCI-P3).

Also, it'd be nice to see what the original materials/textures looked like in RL: the apples and bananas definitely look more realistic with ACES, but without a reference it's truly hard to be objective.

Nice job, btw.

[^Lele^]

Once again, to substantiate what i said above, some image math (albeit on the jpg images.).
The first image is the result of the minus operation (sRGB - Aces, clamped to 0.0 for viewing, so we're not seeing the negative values)
The second, is aces-sRGB (i.e. the opposite of the first.).
The third is the difference (abs (sRGB-Aces)), which will show the negative parts too (by virtue of the modulo, or Abs function, i.e. removing the negative sign.).

In the first, the redder cast of sRGB is apparent (it's missing in the ACES), in the second, the blue cast of ACES is apparent (as it's not there in the sRGB).
The third image proves that there is indeed a lot of difference between the two color spaces, across the image plane.

[piotrus3333]

what was I thinking?..
"comparison" in the title and jpegs attached. shame on me.
proper output below. these are rendered without the lens and a tad warmer as I'm experiencing a bug with ocio and sRGB transform is not available. sRGB(D60) works ok. output E is corrected with white balance layer before AMPAS tonemapper so the correction does not affect render elements.
sRGB (E) is saved with Display correction: None and Lookup Table layer on top with Work in sRGB on instead.

https://we.tl/t-vbAay2qYoo

[^Lele^]

Ahah, what are you doing up at this time of night?
Thanks for the EXRs!

[piotrus3333]

London. so not that late yet.
and it's this and gin or loading dishwasher..

[piotrus3333]

assets from quixel (with albedos corrected a bit):

[^Lele^]

The leftmost has to be ACEScg, as the blue cast is very present (see the indirect in the white test sphere).
The central, by virtue of its saturation (nearly over-saturation) has to be sRGB.
The third looks like a graded ACEScg, with some CCs.
Did i get them right?

[piotrus3333]

correct. although last one is sRGB with CCs. thrown in just to muddy the waters slightly.

if there is someone testing it and willing to share I would love to see some more images or impressions. I chose fruit and veg as these are quite relatable colour wise but anything would do. maybe just not Lego The Movie style full of saturated LED lights as we've seen a lot of that already.

also the AMPAS curve seems to be hitting the spot quite right. I'm hearing more and more it's becoming the new favourite.

[^Lele^]

Could you render a version of each with the dome at 1.0 white, and no textures in it?
That would essentially return the shaders and textures' qualities, any colored cast an unwanted side effect of gamut remapping.

[piotrus3333]

Could you render a version of each with the dome at 1.0 white, and no textures in it?
That would essentially return the shaders and textures' qualities, any colored cast an unwanted side effect of gamut remapping.

white dome (info in the Stamp):



exrs: https://we.tl/t-JByOg45sdp

[piotrus3333]

VRaySun. for this one I did adjust ACEScg's WB via White Balance layer (8000K) to match sRGB. info in the Stamps:

[^Lele^]

Thanks for the renders!
Linked, a 1:1 contact sheet with the difference, and the minus operations, all with measured min, max and avg value.
This is why i was mentioning that for color-accurate work on sRGB displays (i.e. most of them), one needs to stick to sRGB.
The blue cast in the secondary bounces of ACEScg will upset color perception (and actual values) beyond feasible correction.
Notice it adds blue and removes red, leaving greens (also used for luma perception by humans) essentially untouched (minus operations, avg. values, notice the green apple in the difference.).
That to me is problematic, as of yet.
It does look pretty, no doubt.

[piotrus3333]

true. what I called "magic" after first test seems to be happening mostly in red channel. limited hues of the first scene threw me off.

[piotrus3333]

edit: hue and sat -