AFAIK gl.SRGB8_ALPHA8 will only make sure the filtering of the lookup happens in linear sRGB (because filtering involves multiplications).

But values returned from the texture lookup must also be linear for any calculations afterwards to make sense.

AFAIK you'd need to set internal format to SRGB8_ALPHA8 and the format to RGBA. Then the returned color is also linear.

However, according to [1], this combination is only allowed if the result type is requested UNSIGNED_BYTE, i.e. as 8bit/channel. That would mean you will get banding on gradients because 8bit/channel is not nearly enough to represent linear color.

I.e. the type should be at least HALF_FLOAT or FLOAT but the table suggest WebGL 2.0 does not support this. I'm not a realtime graphics person, so I may be missing something. And obviously, there must be some workaround for WebGL.

Furthermore, the final linear->non linear sRGB conversion must be done, too. I.e. before displaying the result. AFAIK the sRGB framebuffer GL extension can take care of this. But again, not sure.

The whole topic of color spaces (vs color models, i.e. RGB is a color model, not a color space) and gamma is not trivial.

Almost everyone starting out with any kind of computer graphics involving display/manipulation of colors gets this wrong first time because they do not know about this/assume this is trivial.

Don't be discouraged. A good read is [2]. While it specifically addresses color pipelines in VFX/film, all in there applies equally to a simple non-linear sRGB image (a typical JPG, e.g.) being manipulated and then displayed or saved out as 8bit/channel again.

[1] https://registry.khronos.org/webgl/specs/latest/2.0/#TEXTURE...

[2] https://www.imageworks.com/sites/default/files/2023-10/Cinem...

Show HN: A pure WebGL image editor with filters, crop and perspective correction