Sometimes I want to make a browser-based art tool, but then I remember that browsers don't have any built-in gamma correct alpha blending. I could implement my own, but I'd have to implement everything else too, like masking and vector graphics paths. Which is exactly the sort of reinventing-the-wheel that I enjoy doing, but I don't have enough free time to justify adding all that to my side projects so instead I just get sad.
Wait what if I just convert all my colors to linear RGB values anyway, use those in standard browser graphics APIs and pretend that I'm doing all blending in linear RGB space, then perform a single transformation on the final image to convert it to real sRGB for display? I'd probably lose a lot of color depth in the darker colors unfortunately, maybe too much to be worthwhile, but maybe not depending on the use-case?
@johnnesky Maybe if it's a paletted or low-bits-per-channel (pixel art?) editor where the minimum distance between two colors is greater than or equal to the distance between the darkest colors in linear 8bpc RGB. If that makes any sense; I'm not a colors expert.
@johnnesky Weird idea, but what if you store in sRGB, convert to 10bpc linear RGB, and call browser APIs using 8bpc linear RGB with four pixels to an on-screen pixel? Basically the classic downscaling-to-antialias thing but used just to limit the banding effect of converting 8bpc linear RGB to 8bpc sRGB.
@golemwire Huh, maybe if the initial conversion to linear is properly dithered... Interesting idea!
@golemwire That could definitely make sense if the underlying pixel data is high bit depth but it gets converted to palletized pixels for display using this technique: https://2dwillneverdie.com/tutorial/instant-pixel-art-backgrounds-with-the-dan-fessler-method/