ColorManagement: Remove ExtendedSRGBColorSpace - #34914

📦 Bundle size

Full ESM build including core, minified and gzipped.

🌳 Bundle size after tree-shaking

Minimal build including a renderer, camera, empty scene, and dependencies.

Do we also have to update the WebGPU backend so colorSpace: 'srgb-linear' is passed to context.configure()? When I understand the spec correctly, webgpu_hdr would requires this now.

Oh, yes we should do that, thanks! So context.configure() should receive colorSpace directly from renderer.outputColorSpace. I guess the difference wasn't obvious in this example because it's achromatic. Will make the change.

Updated! Requires Chrome 156. Tested in Chrome Canary; we may want to wait until this reaches stable Chrome.

Do we also have to update the WebGPU backend so colorSpace: 'srgb-linear' is passed to context.configure()?

We'll have to limit that, and only pass colorSpace when outputType == HalfFloatType, for the time being. Back when we enabled color management, there was an important opt-out workflow:

ColorManagement.workingColorSpace = THREE.LinearSRGBColorSpace;
renderer.outputColorSpace = THREE.LinearSRGBColorSpace;

It's a "two wrongs make a right" trick: the application is likely writing sRGB color to both, but because they match, no conversions happen, and it all looks fine¹. But if we start passing colorSpace: "srgb-linear" to the WebGPU context in Chrome v156+, it will believe us and apply a conversion from "srgb-linear" to the actual display color space. That's good, but breaks the little trick above.

The "correct" way to express this workflow would really be...

ColorManagement.workingColorSpace = THREE.SRGBColorSpace;
renderer.outputColorSpace = THREE.SRGBColorSpace;

... but in practice it's been difficult to implement a sRGB working color space (e.g., how should textures be stored?) and so this doesn't work in three.js today. If we can later add support for workingColorSpace = THREE.SRGBColorSpace then I think we could remove the exception here and pass outputColorSpace to the WebGPU context unconditionally.

I have tested the PR locally with a normal Chrome (155) and webgpu_hdr breaks with a runtime error.

Uncaught (in promise) TypeError: Failed to execute 'configure' on 'GPUCanvasContext': The provided value 'srgb-linear' is not a valid enum value of the type PredefinedColorSpace.

I understand it works in Canary but we must make sure browsers without the respective support can still run the code. Maybe like so:

try {

	context.configure( configuration );

} catch ( e ) {

	warnOnce( `WebGPURenderer: Canvas color space "${ colorSpace }" is not supported. Falling back to "srgb".` );

	delete configuration.colorSpace;
	context.configure( configuration );

}

Let's hold this back until the feature is at least in stable Chrome. I'll look into your feedback in the meantime, thanks @Mugen87! Possibly we'll also want a WebGPU equivalent of the existing WebGL.isColorSpaceAvailable( colorSpace ) utility, to check if an output color space is supported.