That seems counterintuitive to me. In absense of a specific directive, I feel like threejs should reasonably infer/assume sRGB ? principle of least surprise / less typing / etc.
I suspect the vast majority of users don’t know or care about color space/encoding or even what it means, and 99.99% of images available on the web are sRGB. (This includes a lot of normalmaps from tutorial sites as well i think?)
That means that now, 99% of the time I have to add a load callback (texture)=>texture.encoding = ‘something’, and in the extreeemely rare case that I’m manually loading an actual linear colorspace texture acquired from some 3d modelling pipeline, I would not need a callback? That sounds backwards. (This case being even more rare since most often when I am using normalmaps, they are packed in with a model via GLB which knows what the encodings are truly are from the source modeller?)
It makes sense to me that EXRLoader assumes linear by default, but TextureLoader should assume sRGB?
… and as I peruse the sources you linked… I see that I am not alone in my confusion.
It feels like some of these details are being force-pushed into userspace, when in the past, we were still able to make decent looking stuff, now all the old threejs code is invalid with the latest versions, and have to be hand modified to make them work as they did before.
It somewhat reminds me of the switch from Geometry type to BufferGeometry, but with less immediate tangible benefit. (improved performance). I was resistant to that switch initially, and especially the deprecation of the old style Geometry, but finally grew to accept it (after a year or 2).
I feel like the new color handling could somehow be more opt-in than it is?
Appreciate anyone reading this far along and… I don’t need an answer to any of these questions… but wanted to share my internal dialog as someone who is reasonably skilled at 3d generally, but still experiences confusion about these aspects.