Repository: three.js
Issue: Improve explanation on how to migrate from 151 to 152 color management
Labels: Suggestion,Documentation

### Description

I feel that certain revisions to instructions provided in "[Updates to Color Management in three.js r152](https://discourse.threejs.org/t/updates-to-color-management-in-three-js-r152/50791)" would benefit the community.

### Solution

Merge the following text into the current explanation where appropriate...

<!--StartFragment--><h3><strong>1. Renderer Settings</strong></h3>
Property | Old Name | New Name | Default Behavior Change?
-- | -- | -- | --
Renderer output encoding | renderer.outputEncoding | renderer.outputColorSpace | Yes: From THREE.LinearEncoding to THREE.SRGBColorSpace (r152).
Tone mapping | renderer.toneMapping | Same | No: Default remains THREE.NoToneMapping.

<!--EndFragment-->

<!--StartFragment--><h3><strong>Texture Properties</strong></h3>
Property | Old Name | New Name | Default Behavior Change?
-- | -- | -- | --
Texture encoding | texture.encoding | texture.colorSpace | No: Default remains THREE.LinearEncoding (non-color textures).
sRGB textures | THREE.sRGBEncoding | THREE.SRGBColorSpace | No: Only the name changed.
Linear textures | THREE.LinearEncoding | THREE.LinearSRGBColorSpace | No: Only the name changed.

<!--EndFragment-->

<!--StartFragment--><h3><strong>Shader Changes</strong></h3>
Function/Include | Old Name | New Name | Default Behavior Change?
-- | -- | -- | --
GLSL fragment includes | <encodings_pars_fragment> | <color_space_pars_fragment> | No: Name changed; behavior remains the same.
GLSL linear-to-output function | linearToOutputTexel() | linearToColorSpace() | No: Name changed; behavior remains the same.
GLSL sRGB-to-linear function | sRGBToLinear() | srgbToLinear() | No: Name changed; behavior remains the same.

<!--EndFragment-->

<!--StartFragment--><h3><strong>Material Properties</strong></h3>
Property | Old Behavior | New Behavior | Default Behavior Change?
-- | -- | -- | --
Colors and textures on materials | Assumed sRGB | Assumed sRGB | Yes: Colors are now converted from sRGB to Linear by default.

<!--EndFragment-->

<!--StartFragment--><h3><strong>Global Defaults</strong></h3>
Property | Old Behavior | New Behavior | Default Behavior Change?
-- | -- | -- | --
Color management toggle | THREE.ColorManagement.enabled | Same | Yes: Default is now true (enabled).

<!--EndFragment-->

<!--StartFragment--><h3><strong>Migration Steps</strong></h3>

Previously inputs, outputs, and blending were all done in the sRGB color space (Note: "colorSpace" was formerly called "encoding"). With the improved methodology, three.js still accepts sRGB inputs, but now it converts them to linear. All blending is done in linear colorSpace. Finally, the renderer converts the finished scene back to the sRBG color space.

Here's what you need to do:
1) Set the color space of textures with color explicitly to THREE.SRGBColorSpace. Textures that use non-color data (e.g., normal maps, height maps) can be left as-is, as they default to THREE.LinearSRGBColorSpace.

2) For all fragment shaders, if the old fragment shader produced sRGB values, under the new methodology it needs to generate linear values. To adapt the shader, apply the linearToOutputTexel conversion function before assigning the pixel value to gl_FragColor. Here's an example:

```
#include <color_space_pars_fragment>

// Old (output assumed to be sRGB):
gl_FragColor = vec4(color, 1.0);

// New (convert to linear space):
gl_FragColor = vec4(linearToOutputTexel(color), 1.0);
This ensures the shader aligns with the updated linear workflow.

<!--EndFragment-->
```

You can also include ```colorspace_fragment``` after assigning gl_FragColor.
```
gl_FragColor = vec4(color, 1.0);
#include <colorspace_fragment>
```

### Alternatives

If any of the proposed new instructions are inaccurate please correct them.

Explaining what the following two lines do in more detail might help.
```
#include <tonemapping_fragment>
#include <encodings_fragment>
```

### Additional context

_No response_