Asset color de-saturated look?

[vanlicht]

Description

We started noticing some assets when rendered in the Model Viewer they tend to look more de-saturated/ washed out...which is not the same as the default exposure value being too hot, since we already calibrated it, and the de-saturated look remains in both defaultLight as well as neutral ligthing environment.

Lighting Environment:
Default Light: exposure value 0.6
Neutral Light: exposure value 1.0

Asset
Only with albedo map
metalness: 0.0
roughness: 1.0

To replicate the result:

1. I screen-grabbed only the front-view in the default lighting setup
2. Overlay the screen grabs on the Albeodo maps to see compare the differences.
3. GLB example here:
   satuartion_checker.zip

Live Demo

https://glitch.com/edit/#!/model-viewer

Version

• model-viewer: v1.7.1, also v1.6.0

Browser and OS

• Chrome, version: Version 84.0.4147.135
• Windows 10 64-bit

[elalish]

I don't quite understand what looks desaturated. What do you expect the render to look like?

[elalish]

Oh, maybe I do see. The shading varies based on the precise angles of the lighting (you can see how the saturation changes around the sphere). If you are comparing to the front face of the cube, that is just one arbitrary direction, and with slight changes to the camera you will find the colors all change accordingly. The albedo jpeg is a baseColor, so it represents the % of light reflected (material color), which is not the same as the rendered output color, since that is mostly driven by the details of the lighting and roughness.

[vanlicht]

Use this picture color block RGB values as an example.
The desire is to have the color rendered as close as possible to original albedo.
Rendered Asset RGB 226,211,181
Asset Albedo RGB 238,201,148

The front view is the easiest way to explain it, we do see the desaturated look consistent from various of angles when reviewing production assets. To help simplify the variables in discussion, I put the metal to 0.0 and rough to 1.0.
The desire is to have the render output with similar color value as the Albedo in a controlled setting.

[elalish]

As I've discussed with the 3D Commerce Certification TSG, this desire for baseColor to match output color is fundamentally at odds with tone mapping, which we apply in order to avoid clipping artifacts and blown-out renders around bright reflections. This is a standard rendering practice since the results are so poor and unrealistic without it. However, to accomplish this, the gamut must be compressed. This is to help match the nonlinear behavior of the human eye. Please take samples from across your sphere to get an idea of the range of values to expect from a single base color under this neutral lighting. I think you'll find they vary quite a bit, but if they didn't the result would be worse. If you want base Color to be faithfully reproduced in the render (for instance with photogrammetry scans) you should export those using the unlit extension. However, we do currently have a bug where tone mapping is applied when it shouldn't be to unlit objects.

[vanlicht]

Does Model Viewer use ACES tone mapper? What the derivation of this coloration issue may result from the workflow?
If the Model Viewer uses ACES tone mapper, then maybe the content creation phase (e.g. using Adobe tools) need to also apply ACES LUTs?

[elalish]

Yes, we use ACES (technically it's the modified version, since our users are not in a darkened theater) and yes, I think applying that in the authoring tools is exactly the right step.