Open mosra opened 8 years ago
Some (scary!) information about colorspaces in DDS files: http://stackoverflow.com/questions/13491131/what-are-the-exact-color-spaces-of-dxgi-formats
sRGB support in Color[34]
classes done in 2b97e5336022841e1ff4d122d5acea4b10dc276f.
Just discovered that WebGL has WEBGL_compressed_texture_s3tc_srgb.
Added http://www.ericbrasseur.org/gamma.html to the list, great set of test images. Chrome on my HiDPI screen is apparently not doing the right thing, it seems.
Ha! Chome on Windows 10 without HiDPI fails the test also 😆
Nah, actually it seems to be doing the correct thing: http://www.ericbrasseur.org/gamma_dalai_lama.html
PixelFormat
values and one and two-component sRGB texture formats added in https://github.com/mosra/magnum/commit/40b8815b9da1841b885bb2e7ac20aa8f0c3417c1
sRGB/S3TC
After reading The sRGB learning curve (great article, by the way) I was investigating sRGB support in OpenGL and found out that the old EXT_texture_sRGB extension (part of GL 2.1) had an interaction with EXT_texture_compression_s3tc and provided additional sRGB/DXT compression formats. It might be a good idea to provide these in the
TextureFormat
andCompressedPixelFormat
enums:OpenGL ES is a bit different. The EXT_sRGB ES extension says the following and the S3TC/SRGB support is then added by NV_sRGB_formats (ES2+).
No such thing in WebGL, sadly.WebGL: WEBGL_compressed_texture_s3tc_srgbS3TC/SRGB support in DDS importer
sRGB-related features
PixelFormat
values -- 40b8815b9da1841b885bb2e7ac20aa8f0c3417c1Srgb
pixel formats :sweat_smile:MeshData::colorsAsArray()
taking that into account to always return linearDebug
andConfiguration
(at the moment it's being cast toColor[34]ub
which wrong on many levels)sRGB-related extensions
sRGB conversion utilities
The idea with sRGB is that it only makes sense to do all operations (filtering, interpolating, ...) in linear and use sRGB only as a "compression format" and never do anything with it except for converting from and back to it. Thus it seems to me like it would make sense to have some conversion functions on
Math::Color
: assuming everything stored in that class is linear and provide sRGB conversion functions that take or return "untyped"Math::Vector3
. And, similarly as OpenGL does it, treat alpha channel always as linear (thus copying it without conversion).Color3 Color3::fromSrgb(const Vector3&)
,Vector3 Color3::toSrgb()
Color4 Color4::fromSrgbAlpha(const Vector4&)
,Vector4 Color4::toSrgbAlpha()
_srgb
,_srgba
,srgbf
,_srgbaf
color literalsColor[34]::fromSrgb(const char*)
for conversion from hexadecimal string representation (provide a linear one as well?)Math::packInto()
/unpackInto()
, basically)Correct sRGB usage (in examples and elsewhere)
Questionable
_rgb
,_rgba
,_rgbf
,_rgbaf
literals and theColor3ub
/Color4ub
types because they are not sRGB? OTOH it should be possible to save a packed 8bit linear color somehow. It's also better to leave them in for cases where the workflow is not sRGB-correct and yet it's still needed to properly load colors etc.