ACES
It seems to flatten the image out, similar to when HDR photos look when they are auto-converted to LDR by normalising lows and highs to mids, every color then becomes a tone of gray, some character and depth is lost.
AGX in Blender does not look much like aces, but i’m not sure, it doesn’t seem to gray out that much? Something that looks like a normal, well lit photo is imo what Three could really need, with some blacks and some whites in it, and some saturation.
Can you give the dev version a try? It has been noticed that the initial implementation in r160 misses a bit that has been added in r161, see:
If you have an EXR or HDR image you can share, it would be possible to compare directly with Blender’s AgX implementation. I use this script to apply Blender’s AgX to an EXR image:
That said, it’s very much expected that AgX is less saturated than ACES Filmic, out of the box. A note from AgX’s author on the topic:
What Blender offers that three.js currently does not is “Looks” for modifying AgX. Probably the “Punchy” look would be much closer to the saturation you see in ACES Filmic. For my taste, that’s higher contrast than I might prefer out of the box, but entirely my opinion. Proposal:
Enormously complex to express this goal in a workable way. For example — a goal of always having saturated colors in the output image, given saturated colors in the lighting or material base colors, conflicts very quickly with goals for dynamic range and realistic highlights.
In any case, I do think an option to modify the saturation and contrast would help, and “AgX Punchy” is probably about what you’re looking for.
from the images i’ve seen so far agx punchy looks quite contrasted. aces filmic is pretty realistic, maybe gets a little lost in the saturated parts, though the way it retains lows and highs was good. i was hoping for agx to fix this, also aces can loose saturation too much. i was asking because for a nextjs-for-threejs template we were considering agx as the default. but it seems to me aces is still a good and flexible default.
This doesn’t really match up with my experience for either, can you share something we can look at here? In my view AgX is a significant improvement on ACES Filmic, with the caveat that, yes, you may want to bump the contrast. Blender has 8–10 different AgX looks… have you tried some of these for the scenes in question?
Other goals for a default tone mapper you may want to consider:
I believe AgX Filmic is better for both (1) and (2)… (3) is a debatable goal (I have mixed feelings about this) but the “Commerce” tone mapper recently added to modelviewer is an interesting solution focused on that goal.
I think part of what you’re looking for might be summarized as — “produce images with similar contrast and saturation, for existing scenes with lighting originally designed under ACES Filmic, without changing the lighting.”
That’s a reasonable goal, with an eye toward backward compatibility. But it’s a little against the grain of how tone mappers work, and you’re effectively also asking for a tone mapper with no more dynamic range than ACES Filmic. Hopefully that offers a little context for why contrast changes are involved in balancing those goals.
i come from a photography background, we would shoot in *.raw to retain high dynamic range, but the output must clip when converted to ldr format, printout or monitors. or it would look artificial, bright skies are not gray to the eye. but there was a trend at the time where people wanted to make hdrs by capturing multiple shots with varying exposure, but ended up just normalising highs mids and lows, which resulted in these flattened gray images.
left bad hdr, right good hdr
this is what it reminds me of a little currently, not so bad as with the left image of course 
. if agx punchy can fix that it’s very welcome! i have only seen web content, i have not tried presets in blender directly. maybe this would help clip it a little bit and get the natural colors back.
Note, I don’t intend to convince you that all or most production apps should ship AgX at base contrast to production. I don’t believe that, and that isn’t why it is used in Blender, Filament, or (soon) Godot.
When shooting RAW on a digital camera, you probably have a display transform or “picture control” setting on the camera itself. On my Nikon DSLR these have names like “Standard” or “Neutral”. This has no effect on the contents of the RAW file, but selects how the RAW data appears on the camera’s display, and is meant for preview — to ensure you have the shot properly exposed, and that no important details have been clipped. AgX is like that, and as such a good choice of viewport default for Blender and other DCC tools.
The whole point of shooting RAW, though, is that this isn’t the final output — you can and probably should do color grading, e.g. bump the contrast. AgX Base is a foundation for color grading, not one-size-fits-all color grading preset.
While our implementation is not 100% identical to Blender’s, I believe it’s more than close enough for the purposes of this conversation. What is much harder, though, is creating identical lighting conditions in Blender and three.js. This is where EXR images are very helpful for comparison, and we’ve done some of these three.js/blender comparisons already, based on EXR photos (comparable to RAW) as input.
I probably should write a blog post or something, but tl;dr —
It is also, of course, entirely possible that there’s a problem. 
I don’t see it in the comparisons here, nothing is nearly so desaturated as your example above. But I would like to get ‘Punchy’ added to three.js and then do some further comparisons.
made a quick sandbox for the initial example
it’s now 0.16.1 so it should have the agx fix
btw the comparisons look good, it’s subtle but they are slightly less saturated and flatter on the threejs side, in the mids/lows it grays out a little. perhaps this is the difference already and the scene above just happens to sit in the affected histogram.
agx
three-agx
PR opened for AgX Punchy —
Thank you Don 
Btw I was thinking about the comparison you posted. These seem to be ldr images with tone mapping ran over it? would that be comparable with a hdr scene with a wide range that’s being processed by tone mapping? The problem used to be compressing high dynamic range for low dynamic range mediums (screens), if that’s done by compressing the colorspace it creates this flatness/grayness.
These seem to be ldr images with tone mapping ran over it? would that be comparable with a hdr scene with a wide range that’s being processed by tone mapping?
We haven’t been running tone mapping on LDR images, that’d be problematic as you know. These are linear-sRGB inputs in OpenEXR format – comparable to RAW photos, or direct output from the three.js renderer, so we’re still mapping from [0,∞] to [0,1] using the tone mapper.
