-
-
Notifications
You must be signed in to change notification settings - Fork 3.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Color difference between 1.4.2 and 1.5.0 #5383
Comments
That's excepted because colorManagement is true by default. If you set colorManagement:false it should be the same, right? |
That does indeed look like an (expected) difference due to colorManagement being enabled by default now. While colours should pretty much match up as they were before, the lighting calculations now take place in linear colour space, which will result in (slight) differences. Especially the brighter/specular parts will appear different. See for example the comparison screenshots in this Three.js thread: https://discourse.threejs.org/t/updates-to-color-management-in-three-js-r152/50791#motivation-3 However, there have been various changes in Three.js since, so to rule out any regressions/oversights, could you test with |
With |
a possible solution could be to update the injected lights to higher value |
Changing the intensity of the default injected lights can make the colors brighter but the colors will still differ from what it used to be. The color changes here are just related to the linear-sRGB conversion.
With these new colors, we have exactly the same render. |
There should be no need to adjust colours in your A-Frame scenes1, as the colour space conversions are correctly taken care of. In other words the colours themselves should still be identical between 1.4.2 and 1.5.0. The difference lies in the effect of the lighting calculations. An easy way to verify this is to use a single full-bright ambient light, which effectively avoids any shading, showing the entities base diffuse colour:
<a-light type="ambient" intensity="1"></a-light> As for the lights, there's no real way to adjust them with ColorManagement enabled to get identical results as before. In a way this makes sense, otherwise there wouldn't have been a need for this change. Though it should be possible to tweak them to get the desired look and feel. Like @arpu suggests, boosting the intensity of the default lights would likely bring the result for the hello-world scene closer to how it was in 1.4.2. Though it likely won't be a one-size-fits-all change. I think the key point is that most scenes will have been authored with the old approach, and as a result will inevitably look slightly 'off' due to some differences. Most noticeable will be the high-specular/bright areas (plasticky look) and the very dark areas. For new scenes this shouldn't be an issue, and when aiming for realistic PBR the new default should behave better, which for MR experiences can aid making the virtual entities appear more realistic/grounded. 1) This is only referring to using colours in HTML, or when setting colour properties through |
I agree, there is no need to do any color space conversions yourself anymore in 1.5.0, this is taken care of for you. |
While the colours were indeed treated as being in linear colour space, the (linear) output was presented on the screen as-is. These "two wrongs" effectively negated each other. The colours did in fact match up with what you'd see when using them in CSS, barring any shading/lighting. You can verify this yourself by using Enabling
Indeed, in 1.5.0 it's three.js that handles (most) of the colour management burden. Only for textures does A-Frame still need to explicitly state the colour space. One thing that might not be immediately obvious is that Three.js does this inside of the
As you can see the conversion happens immediately. Many of the setter methods now also accept a colour space argument which you can use to indicate which colour space the provided value is in. Most user shouldn't face any issues, but when inspecting colour channel values or performing arithmetic with colours, there'll likely be differences when toggling colorManagement on and off. It might be worth always being explicit about the colour space in those cases to avoid any oversights.
I'm afraid this would actually lead to incorrect colours. It's really the lights and possibly material properties you should tweak to (re)gain the desired visuals. That being said, a lot of people might actually pick colours iteratively by judging how they look in the scene (= under the lighting setup in said scene). In those cases the colours don't actually reflect the actual diffuse of the material. They might need fixing up manually as it's not possible to automatically convert these in a meaningful way. When faced with many of those, it's probably easier to disable colorManagement. tl;dr When migrating from 1.4.2, leave colours untouched. My advice: adjust lights first, followed by possibly tweaking material properties. If that isn't enough, consider manually changing the colours, though probably easier to disable |
Oh you're right sorry, my personal experience where it didn't match was with colorManagement:true, aframe 1.4.2 and THREE.Color() where I wrongly didn't call applyColorCorrection that called convertSRGBToLinear. In 1.5.0 there won't be this issue anymore, it's done automatically. Sorry folks for the noise, listen to @mrxz he knows this stuff better than me obviously. Thanks for doing again a summary on this topic, much appreciated. |
Thanks. Yeah the hello world is just the canary in the mine. Worried about surprising people. All of a sudden scenes look more muted / boring :) |
Just soft launched 1.5.0 and noticed a color difference on the hello-world with respect to 1.4.2. Screenshots below
We changed color management related stuff in #5210. It might be related
@mrxz @vincentfretin what do you think? thanks
1.4.2
1.5.0
The text was updated successfully, but these errors were encountered: