blob: dd7e6e786c25c9a170530a506bb60311dd580dd1 [file] [log] [blame]
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 <format> and <internalformat> parameter of
TexImage2D, and TexImage3DNV. These are also accepted by <format>
parameter of TexSubImage2D and TexSubImage3DNV:
SLUMINANCE_NV 0x8C46
SLUMINANCE_ALPHA_NV 0x8C44
Accepted by the <internalformat> parameter of RenderbufferStorage,
TexStorage2DEXT, and TexStorage3DEXT:
SRGB8_NV 0x8C41
Accepted by the <internalformat> parameter of TexStorage2DEXT and
TexStorage3DEXT:
SLUMINANCE8_NV 0x8C47
SLUMINANCE8_ALPHA8_NV 0x8C45
Accepted by the <internalformat> parameters of TexImage2D,
TexImage3DNV, CompressedTexImage2D, and CompressedTexImage3DNV as
well as the <format> 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 <internalformat> 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 <internalformat> 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
<internalformat> is an S3TC format and <target> is not TEXTURE_-
2D_ARRAY_NV.
If <internalformat> 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 <internalformat> parameter of TexImage2D,
TexImage3DNV, is not supported and will produce an INVALID_VALUE
Errors
INVALID_OPERATION is generated by CompressedTexSubImage* if
<internalformat> 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:
* <width> is not a multiple of four, and <width> plus
<xoffset> is not equal to the texture width;
* <height> is not a multiple of four, and <height> plus
<yoffset> is not equal to the texture height; or
* <xoffset> or <yoffset> is not a multiple of four.
INVALID_OPERATION is generated by CompressedTexImage3DNV if
<internalformat> 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 <target> is
not TEXTURE_IMAGE_2D_ARRAY_NV.
INVALID_OPERATION is generated by CompressedTexSubImage2D,
TexSubImage2D, CompressedTexSubImage3DNV, or TexSubImage3DNV, if the
texture image <level> bound to <target> 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