Name NV_sRGB_formats Name Strings GL_NV_sRGB_formats Contributors Contributors to ARB_framebuffer_sRGB and EXT_texture_sRGB Mathias Heyer, NVIDIA Jussi Rasanen, NVIDIA Greg Roth, NVIDIA Contact Greg Roth, NVIDIA (groth 'at' nvidia.com) Status Complete Version Date: 17 Jan, 2013 Revision: 5 Number OpenGL ES Extension #148 Dependencies OpenGL ES 2.0 is required. This extension is written against the OpenGL ES 2.0.25 specification. Requires EXT_sRGB. OES_compressed_ETC1_RGB8_texture affects the definition of this extension. EXT_texture_storage affects the definition of this extension. NV_texture_array affects the definition of this extension. NV_texture_compression_s3tc affects the definition of this extension. NV_texture_compression_s3tc_update affects the definition of this extension. Overview This extension adds new uncompressed and compressed color texture formats with nonlinear sRGB color components. Luminance and luminance alpha provide support for textures containing sRGB values with identical red, green, and blue components. Compressed texture formats using S3TC and ETC1 compression algorithms are also added to provide compressed sRGB texture options. Finally, sized variant of sRGB, sLuminace, and sLuminance_alpha are provided for immutable textures defined using the EXT_texture_storage extension. New Procedures and Functions None New Tokens Accepted by the and parameter of TexImage2D, and TexImage3DNV. These are also accepted by parameter of TexSubImage2D and TexSubImage3DNV: SLUMINANCE_NV 0x8C46 SLUMINANCE_ALPHA_NV 0x8C44 Accepted by the parameter of RenderbufferStorage, TexStorage2DEXT, and TexStorage3DEXT: SRGB8_NV 0x8C41 Accepted by the parameter of TexStorage2DEXT and TexStorage3DEXT: SLUMINANCE8_NV 0x8C47 SLUMINANCE8_ALPHA8_NV 0x8C45 Accepted by the parameters of TexImage2D, TexImage3DNV, CompressedTexImage2D, and CompressedTexImage3DNV as well as the parameter of TexSubImage2D, TexSubImage3DNV, CompressedTexSubImage2D, and CompressedTexSubImage3DNV: COMPRESSED_SRGB_S3TC_DXT1_NV 0x8C4C COMPRESSED_SRGB_ALPHA_S3TC_DXT1_NV 0x8C4D COMPRESSED_SRGB_ALPHA_S3TC_DXT3_NV 0x8C4E COMPRESSED_SRGB_ALPHA_S3TC_DXT5_NV 0x8C4F Accepted by the parameter of CompressedTexImage2D, and CompressedTexImage3DNV: ETC1_SRGB8_NV 0x88EE Additions to Chapter 3 of the OpenGL ES 2.0.25 Specification (Rasterization) Modify Section 3.7.1, "Texture Image Specification": Add 2 new rows to Table 3.3, "TexImage2D and ReadPixels formats": Element Meaning Format Name and Order Target Buffer ---------------- --------------- ------------- SLUMINANCE_NV Luminance Color SLUMINANCE_ALPHA_NV Luminance, A Color Add 2 new rows to Table 3.4, "Valid pixel format and type combinations": Format Type Bytes per Pixel ---------------- --------------- --------------- SLUMINANCE_NV UNSIGNED_BYTE 1 SLUMINANCE_ALPHA_NV UNSIGNED_BYTE 2 Add 2 new rows to "Valid combinations of format, type, and sized internal-format" Table: Internal Format Format Type ---------------- -------- ------ SLUMINANCE8_NV SLUMINANCE_NV UNSIGNED_BYTE SLUMINANCE8_ALPHA8_NV SLUMINANCE_ALPHA_NV UNSIGNED_BYTE Add 5 new rows to "Specific Compressed Internal Formats" Table Compressed Internal Format Base Internal Format ----------------------------------- -------------------- COMPRESSED_SRGB_S3TC_DXT1_NV RGB COMPRESSED_SRGB_ALPHA_S3TC_DXT1_NV RGBA COMPRESSED_SRGB_ALPHA_S3TC_DXT3_NV RGBA COMPRESSED_SRGB_ALPHA_S3TC_DXT5_NV RGBA ETC1_SRGB8_NV RGB Modify Section 3.7.2 "Alternate Texture Image Specification Commands" Modify the first sentence of the last paragraph (added by NV_texture_compression_s3tc_update): When the internal format of the texture object is COMPRESSED_RGB_S3TC_DXT1_EXT, COMPRESSED_RGBA_S3TC_DXT1_EXT, COMPRESSED_RGBA_S3TC_DXT3_EXT, COMPRESSED_RGBA_S3TC_DXT5_EXT, COMPRESSED_SRGB_S3TC_DXT1_NV, COMPRESSED_SRGB_ALPHA_S3TC_DXT1_NV COMPRESSED_SRGB_ALPHA_S3TC_DXT3_NV, or COMPRESSED_SRGB_ALPHA_- S3TC_DXT5_NV the update region specified in TexSubImage2D must be aligned to 4x4 pixel blocks. ... Modify Section 3.7.3 "Compressed Texture Images" Add to the description of CompressedTexImage* If is COMPRESSED_SRGB_S3TC_DXT1_NV, COMPRESSED_SRGBA_S3TC_DXT1_NV, COMPRESSED_SRGBA_S3TC_DXT3_NV, or COMPRESSED_SRGBA_S3TC_DXT5_NV, the compressed texture is stored using one of several S3TC compressed texture image formats. The S3TC texture compression algorithm supports only 2D images. CompressedTexImage3DNV produce an INVALID_OPERATION error if is an S3TC format and is not TEXTURE_- 2D_ARRAY_NV. If is ETC1_SRGB8_NV, the compressed texture is an ETC1 compressed texture. Change the penultimate paragraph describing CompressedTexSubImage* (added by NV_texture_compression_s3tc): If the internal format is one of COMPRESSED_RGB_S3TC_DXT1_NV, COMPRESSED_RGBA_S3TC_DXT1_NV, COMPRESSED_RGBA_S3TC_DXT3_NV, COMPRESSED_RGBA_S3TC_DXT5_NV, COMPRESSED_SRGBA_S3TC_DXT1_NV, COMPRESSED_SRGBA_S3TC_DXT3_NV, or COMPRESSED_SRGBA_S3TC_DXT5_NV the compressed texture is stored using one of several S3TC compressed texture image formats ... Modify Section 3.7.14, "sRGB Texture Color Conversion": Change the first sentence to: "If the currently bound texture's internal format is one of SRGB_EXT, SRGB_ALPHA_EXT, SLUMINANCE_ALPHA_NV, SLUMINANCE_NV, COMPRESSED_SRGB_S3TC_DXT1_NV, COMPRESSED_SRGB_ALPHA_S3TC_DXT1_NV, COMPRESSED_SRGB_ALPHA_S3TC_DXT3_NV, COMPRESSED_SRGB_ALPHA_S3TC_DXT5_NV, or ETC1_SRGB8_NV the red, green, and blue components are converted from an sRGB color space to a linear color space as part of filtering described in sections 3.7.7 and 3.7.8. ..." Additions to Chapter 4 of the OpenGL ES 2.0.25 Specification (Per- Fragment Operations and the Framebuffer) The following should be added to table 4.5 "Renderbuffer Image formats": SRGB8_NV color_renderable 8 8 8 - - - Additions to Chapter 6 of the OpenGL ES 2.0.25 Specification (State and State Requests) In section 6.1.3, modify the last sentence of the description of GetFramebufferAttachmentParameteriv: "... For framebuffer objects, components are sRGB-encoded if the internal format of a color attachment is SRGB_EXT, SRGB8_NV, SRGB_ALPHA_EXT, SRGB8_ALPHA8_EXT, SLUMINANCE_NV, SLUMINANCE8_NV, SLUMINANCE_ALPHA_NV, SLUMINANCE8_ALPHA8_NV, COMPRESSED_SRGB_S3TC_- DXT1_NV, COMPRESSED_SRGB_ALPHA_S3TC_DXT1_NV, COMPRESSED_SRGB_ALPHA_- S3TC_DXT3_NV, COMPRESSED_SRGB_ALPHA_S3TC_DXT5_NV, or ETC1_SRGB8_NV." Dependencies on OES_compressed_ETC1_RGB8_texture If OES_compressed_ETC1_RGB8_texture is not supported, ignore all references to ETC1_SRGB8_NV. Dependencies on EXT_texture_storage If EXT_texture_storage is not supported, ignore all references to glTexStorage2DEXT and TexStorage3DEXT functions, additions to the "Valid combinations of format, type, and sized internal-format" Table, and LUMINANCE8_NV and LUMINANCE8_ALPHA8_NV tokens. Dependencies on NV_texture_array If NV_texture_array is not supported, ignore all references to TexImage3DNV, TexSubImage3DNV, CompressedTexImage3DNV, and CompressedTexSubImage3DNV. Dependencies on NV_texture_compression_s3tc If EXT_texture_compression_s3tc is not supported, ignore the new COMPRESSED_*_S3TC_DXT* tokens, the additions to the "Compressed Internal Format" table, errors related to the COMPRESSED_*_S3TC_DXT* tokens, and related discussion. Also ignore edits to decription of CompressedTexSubImage*. Dependencies on NV_texture_compression_s3tc_update If NV_texture_compression_s3tc_update is not supported, passing COMPRESSED_SRGB_NV, COMPRESSED_SRGB_ALPHA_NV, COMPRESSED_SLUMINANCE_NV, COMPRESSED_SLUMINANCE_ALPHA_NV, COMPRESSED_SRGB_S3TC_DXT1_NV, COMPRESSED_SRGB_ALPHA_S3TC_DXT1_NV, COMPRESSED_SRGB_ALPHA_S3TC_DXT3_NV, or COMPRESSED_SRGB_ALPHA_S3TC_- DXT5_NV to the parameter of TexImage2D, TexImage3DNV, is not supported and will produce an INVALID_VALUE Errors INVALID_OPERATION is generated by CompressedTexSubImage* if is COMPRESSED_SRGB_S3TC_DXT1_NV, COMPRESSED_SRGBA_S3TC_DXT1_NV, COMPRESSED_SRGBA_S3TC_DXT3_NV, or COMPRESSED_SRGBA_S3TC_DXT5_NV and any of the following apply: * is not a multiple of four, and plus is not equal to the texture width; * is not a multiple of four, and plus is not equal to the texture height; or * or is not a multiple of four. INVALID_OPERATION is generated by CompressedTexImage3DNV if is COMPRESSED_SRGB_S3TC_DXT1_NV, COMPRESSED_SRGB_- ALPHA_S3TC_DXT1_NV, COMPRESSED_SRGB_ALPHA_S3TC_DXT3_NV, COMPRESSED_SRGB_ALPHA_S3TC_DXT5_NV, or ETC1_SRGB8_NV and is not TEXTURE_IMAGE_2D_ARRAY_NV. INVALID_OPERATION is generated by CompressedTexSubImage2D, TexSubImage2D, CompressedTexSubImage3DNV, or TexSubImage3DNV, if the texture image bound to has internal format ETC1_SRGB8_NV. New State None New Implementation Dependent State None Issues 1) Should this be one extension or two? RESOLVED: one. Desktop GL divided this functionality between texture_sRGB and framebuffer_sRGB, but the ES extension EXT_sRGB which took some features from each of those was only one. For consistency with EXT_sRGB, this is a single extension. 2) Should inherently incomplete compressed sRGB texture attachments still return sRGB for FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING_EXT queries? RESOLVED: Yes. Just because they are incomplete doesn't mean they aren't attached. Such a query might be performed to determine why an FBO is incomplete. 3) Should formats for sRGB luminance values be supported? RESOLVED: Yes. Implementations can always support luminance and luminance-alpha sRGB formats as an RGB8 or RGBA8 format with replicated R, G, and B values. For lack of a better term, "SLUMINANCE" will be used within token names to indicate sRGB values with identical red, green, and blue components. 4) Should all component sizes be supported for sRGB components or just 8-bit? RESOLVED: Just 8-bit. For sRGB values with more than 8 bit of precision, a linear representation may be easier to work with and adequately represent dim values. Storing 5-bit and 6-bit values in sRGB form is unnecessary because applications sophisticated enough to sRGB to maintain color precision will demand at least 8-bit precision for sRGB values. Because hardware tables are required sRGB conversions, it doesn't make sense to burden hardware with conversions that are unlikely when 8-bit is the norm for sRGB values. 5) Should generic compressed sRGB formats be supported? RESOLVED: Yes. Implementations are free simply to use uncompressed sRGB formats to implement the GL_COMPRESSED_SRGB_* formats. 6) Should S3TC compressed sRGB formats be supported? RESOLVED: Yes, but only if EXT_texture_compression_s3tc is also advertised. For competitive reasons, we expect OpenGL ES will need an S3TC-based block compression format for sRGB data. Rather than expose a separate "sRGB_compression" extension, it makes more sense to specify a dependency between EXT_texture_compression_s3tc and this extension such that when BOTH extensions are exposed, the GL_COMPRESSED_SRGB*_S3TC_DXT*_NV tokens are accepted. We avoid explicitly requiring S3TC formats when EXT_texture_sRGB is advertised to avoid IP encumbrances. 7) How is the texture border color handled for sRGB formats? (Only relevant if NV_texture_border_clamp is supported. RESOLVED: The texture border color is specified as four floating-point values. Given that the texture border color can be specified at such high precision, it is always treated as a linear RGBA value. Only texel components are converted from the sRGB encoding to a linear RGB value ahead of texture filtering. The border color can be used "as is" without any conversion. By keeping the texture border color specified as a linear RGB value at the API level allows developers to specify the high-precision texture border color in a single consistent color space without concern for how the sRGB conversion is implemented in relation to filtering. An implementation that does post-filtering sRGB conversion is likely to convert the texture border color to sRGB within the driver so it can be filtered with the sRGB values coming from texels and then the filtered sRGB value is converted to linear RGB. By maintaining the texture border color always in linear RGB, we avoid developers having to know if an implementation is performing the sRGB conversion (ideally) pre-filtering or (less ideally) post-filtering. 8) Should sRGB framebuffer support affect the pixel path? RESOLVED: No. sRGB conversion only applies to color reads for blending and color writes. Color reads for glReadPixels have no sRGB conversion applied. Revision History Rev. Date Author Changes ---- -------- --------- ------------------------------------- 5 17 Jan 2013 groth Add sized L and LA sRGB formats Drastically flesh out interactions. 4 11 sep 2012 groth Further clarify interactions 3 21 Aug 2012 groth Reorganzied issues. Clarified some. 2 15 Aug 2012 groth Clarified mheyer feedback. 1 13 Aug 2012 groth Initial draft based off EXT_texture_sRGB