ACES filmic tone mapping

[another_commander]

I was recently reading about HDR and somehow came across this page, which had an implementation of the Academy Color Encoding System (ACES) filmic tone mapper. It looked very compact and portable, so I gave it a go with Oolite, temporarily replacing the Hejl / Burgess-Dawson tone mapper we currently utilize. Here are some results and comparisons. Top is Hejl / Burgess-Dawson, bottom is ACES:










As you can see, ACES produces better detail in the dark areas and it looks just as good in the bright parts and as vivid as H/B-D. Actually, the bright parts are very slightly brighter with ACES. I'm liking it also because it takes into account the brightness of each fragment in its calculations. It is not by accident that ACES is one of the default tone mappers in the Unreal 4 engine (although its implementation there is slightly more complex than this).

I would be interested to hear what you think and the best way to form an opinion is to take a look at it on your screens. I have uploaded the ships and planets modified fragment shaders here. Just copy them over to the Resources/Shaders folder and run Oolite normally.

For reference, all above images are shot using light source radiance 3.75, exposure 1.38 in the shaders and ambient light level 0.1 in planetinfo.

[Redspear]

ACES produces better detail in the dark areas and it looks just as good in the bright parts

Sold!

It perhaps looks a little more 'full on' in the first comparison but I do think it's an improvement FWIW.

[Cody]

For reference, all above images are shot using light source radiance 3.75, exposure 1.38 in the shaders...

Those would make good defaults, Admiral.

[Old Murgh]

I would be interested to hear what you think and the best way to form an opinion is to take a look at it on your screens..

From looking at your examples above (and a brief run of the shaders on my Mac), my reaction is that while the ACES images certainly provide more information in the dark range, to my eyes, the tones in the shadows get a somewhat muddy character. The more dramatic, –slightly higher contrast, slightly less bright– Hejl/Burgess-Dawson is the one more pleasing to me, closer to how I would prefer to B/C-adjust the image. I suppose it is subjective how much of a sucker one is for tenebrism.

Testing them in the game gave the impression my distant sun OXP had given me a warmer system colour, and the textural effects of normal map details seemed to have visibly diminished, but of course I never feel I know when Macs aren't entirely invited to the party..

[phkb]

Samples look great! Subtle, but noticeable. Two thumbs, way way up!

[Cholmondely]

I'm not sure that I can tell any difference on my computer. But if it makes a difference for others, that's more than good enough, no?



On a related point, I'm now noticing that there are "patches" or seams in space around the nebulae (I didn't with v.1.88). I've not tried with every single .oxp (Zygo Cinematic Sky & Nebulas, Submersible Nebulae & DarkSoul Nebulae) to see if some are better than others. Or maybe I've just turned up the brightness on my monitor too much...

One presumes that this is a corollary of the improvements in graphics. Is there an easy fix?

Reference: Guide to Ambience OXPs: Skies (light & nebulae)

For more on this see a_c_'s post with a fixed version of ZygoUgo here

[szaumix]

I'm not sure that I can tell any difference on my computer.

I thought that too at first. Try this:
1. Download all of the pictures and put them in the same folder somewhere.
2. Open an image viewer
3. "Scroll" back and forth between the two images to be compared
It's very subtle but the contrast/lighting effect should become evident that way.

[cbr]

Subtleness ( shader 1.25 1.25 )

[Cholmondely]

Nope. Don't see any difference there either!

Must be an AppleMac thing - or maybe that both Murgh and I are devotees of the CGC and are blinded by our faith!

[Nite Owl]

Agree with the others, subtle changes yet noticeably better. Nice Find.

[another_commander]

ACES is now the new tone mapper in trunk. See here for details and Windows binary.

[tsoj]

ACES is now the new tone mapper in trunk. See here for details and Windows binary.

Somehow this doesn't compile anymore for me on Linux.

Code: Select all

/usr/bin/ld: ./obj.spk/oolite.obj/OOSkyDrawable.m.o: in function `_i_OOSkyQuadSet__initWithQuadsWithTexture_inArray_count_':
OOSkyDrawable.m:(.text+0x1b6b): undefined reference to `max'

Could it be that here it should be fmax instead of max?

[another_commander]

Replace max with MAX and it should compile.

[another_commander]

FYI, ACES may be the current standard in tone mapping, but no tone mapper is without its flaws. We have already transitioned to the actual "proper" ACES inmplementation in trunk (not just the approximation this thread started with) and this has some known issues with certain color tones despite looking wonderful overall. The most serious issue being that overexposed or bright blues often tend towards purple hues.

Thankfully there is a fix in the wild written by ACES experts. For those who might be interested, check out this link. This fix is now implemented in trunk and boy, does it improve some scenes with intense blue tones. I have exaggerated a bit the example below in order to showcase the issue and the fix. The planet shown has bright blue oceans and I've switched the sun color to blue for more ehm... blueness in the scene. Above is the ACES tone mapping without the fix, below is with the fix applied. The scene above shows intense blues taking an electric blue or even purplish tone after tone mapping, while below you can see the scene as it was meant to be. The issue is obviously apparent on the planet, but it is also visible on the Cobra. The fix takes care of other small-scale hue transitions too, but blue is (intentionally) the most obvious one. So I be;ieve this will be it with tone mapping for now - I think we've got the best possible solution at the moment and the ACES development will continue to be monitored in case further improvements that can be ported over take place.

[Cody]

This fix is now implemented in trunk...

Will this become a new nightly?