1Name 2 3 EXT_texture_sRGB 4 5Name Strings 6 7 GL_EXT_texture_sRGB 8 9Contributors 10 11 Alain Bouchard, Matrox 12 Brian Paul, Tungsten Graphics 13 Daniel Vogel, Epic Games 14 Eric Werness, NVIDIA 15 Kiril Vidimce, Pixar 16 Mark J. Kilgard, NVIDIA 17 Pat Brown, NVIDIA 18 Yanjun Zhang, S3 Graphics 19 Jeremy Sandmel, Apple 20 Herb Kuta, Quantum3D 21 22Contact 23 24 Mark J. Kilgard, NVIDIA Corporation (mjk 'at' nvidia.com) 25 26Status 27 28 Implemented by NVIDIA's Release 80 driver series for GeForce FX 29 (NV3x), GeForce 6 and 7 Series (NV4x and G7x), and Quadro FX (NV3xGL, 30 NV4xGL, G7xGL). 31 32Version 33 34 Date: January 24, 2007 35 Revision: 0.8 36 37Number 38 39 315 40 41Dependencies 42 43 OpenGL 1.1 required 44 45 EXT_texture_compression_s3tc interacts with this extension. 46 47 NV_texture_compression_vtc interacts with this extension. 48 49 This extension is written against the OpenGL 2.0 (September 7, 50 2004) specification. 51 52Overview 53 54 Conventional texture formats assume a linear color space. So for 55 a conventional internal texture format such as GL_RGB8, the 256 56 discrete values for each 8-bit color component map linearly and 57 uniformly to the [0,1] range. 58 59 The sRGB color space is based on typical (non-linear) monitor 60 characteristics expected in a dimly lit office. It has been 61 standardized by the International Electrotechnical Commission (IEC) 62 as IEC 61966-2-1. The sRGB color space roughly corresponds to 2.2 63 gamma correction. 64 65 This extension adds a few new uncompressed and compressed color 66 texture formats with sRGB color components. 67 68Issues 69 70 1) What should this extension be called? 71 72 RESOLVED: EXT_texture_sRGB. 73 74 The "EXT_texture" part indicates the extension is in the texture 75 domain and "sRGB" indicates the extension is adding a set of 76 sRGB formats. ARB_texture_float is similarly named where "_float" 77 indicates float texture formats are added by the extension. 78 79 The mixed-case spelling of sRGB is the established usage so 80 "_sRGB" is preferred to "_srgb". The "s" stands for standard 81 (color space). 82 83 For token names, we use "SRGB" since token names are uniformly 84 capitalized. 85 86 2) Should this extension mandate that sRGB conversion be performed 87 pre-filtering? 88 89 RESOLVED: Post-filtering sRGB color conversion is allowed though 90 pre-filtering conversion is the preferred approach. 91 92 Ideally, sRGB conversion moves from the non-linear sRGB to the 93 linear RGB color space. However, implementations should be 94 provided leeway as to whether sRGB conversion occurs before or 95 after texture filtering of RGB components. 96 97 3) Should the alpha component of sRGB texture formats be 98 gamma-corrected? 99 100 RESOLVED: No. Alpha is correctly understood to be a weighting 101 factor that is best stored in a linear representation. The alpha 102 component should always be stored as a linear value. 103 104 "SRGB_ALPHA" is used to indicate sRGB formats with an alpha 105 component. This naming (as opposed to something like "SRGBA") 106 helps highlight the fact that the alpha component is separate 107 and stored with a linear distribution of precision. 108 109 4) Should formats for sRGB luminance values be supported? 110 111 RESOLVED: Yes. Implementations can always support luminance 112 and luminance-alpha sRGB formats as an RGB8 or RGBA8 format with 113 replicated R, G, and B values. 114 115 For lack of a better term, "SLUMINANCE" will be used within 116 token names to indicate sRGB values with identical red, green, 117 and blue components. 118 119 5) Should formats for sRGB intensity values be supported? 120 121 RESOLVED: No. Intensity uses the same value for both luminance 122 and alpha. Treating a single value as an sRGB luminance value 123 and a linear alpha value is undesirable. 124 125 Hardware design is simplified if alpha never involves sRGB 126 conversions. 127 128 6) Should all component sizes be supported for sRGB components or 129 just 8-bit? 130 131 RESOLVED: Just 8-bit. For sRGB values with more than 8 bit of 132 precision, a linear representation may be easier to work with 133 and adequately represent dim values. Storing 5-bit and 6-bit 134 values in sRGB form is unnecessary because applications 135 sophisticated enough to sRGB to maintain color precision will 136 demand at least 8-bit precision for sRGB values. 137 138 Because hardware tables are required sRGB conversions, it doesn't 139 make sense to burden hardware with conversions that are unlikely 140 when 8-bit is the norm for sRGB values. 141 142 7) Should color tables, convolution kernels, histogram table, 143 and minmax table entries support sRGB formats? 144 145 RESOLVED: No. 146 147 The internalformat for histogram table entries determines the bit 148 precision of the histogram bin counters so indicating the sRGB 149 color space is meaningless in this context. The internalformat 150 for minmax table entries simply indicates the components 151 for minmax bounding so indicating the sRGB color space is 152 meaningless. 153 154 Convolution filter values are weighting factors rather than 155 color values needing a color space. 156 157 Color table entries may be colors but the component values are 158 typically stored with more than 8 bits already. For example, 159 software implementations of the OpenGL color table functionality 160 typically store colors in floating-point. 161 162 8) Should generic compressed sRGB formats be supported? 163 164 RESOLVED: Yes. Implementations are free simply to use 165 uncompressed sRGB formats to implement the GL_COMPRESSED_SRGB_* 166 formats. 167 168 9) Should S3TC compressed sRGB formats be supported? 169 170 RESOLVED: Yes, but only if EXT_texture_compression_s3tc is also 171 advertised. For competitive reasons, we expect OpenGL will need 172 an S3TC-based block compression format for sRGB data. 173 174 Rather than expose a separate "sRGB_compression" extension, 175 it makes more sense to specify a dependency between 176 EXT_texture_compression_s3tc and this extension such that when 177 BOTH extensions are exposed, the GL_COMPRESSED_SRGB*_S3TC_DXT*_EXT 178 tokens are accepted. 179 180 We avoid explicitly requiring S3TC formats when EXT_texture_sRGB 181 is advertised to avoid IP encumbrances. 182 183 10) Should the S3TC decompression algorithm be affected by support 184 for sRGB component values? 185 186 RESOLVED: No. 187 188 S3TC involves the linear weighting of two per-block R5G6B5 colors. 189 The sRGB to linear RGB color conversion should occur AFTER the 190 linear weighting of the two per-block colors performed during 191 texel decompression. 192 193 Also be aware that an sRGB value with 8-bit red, green, and blue 194 components must be quantized to a 5, 6, and 5 bits respectively 195 to form the two per-block R5G6B5 colors. 196 197 S3TC compressors may wish to account for the sRGB color space 198 as part of the compression algorithm. 199 200 11) Should VTC compressed sRGB formats be supported? 201 202 RESOLVED. Yes, for the same reasons as S3TC. 203 204 12) Should pixel data entering or exiting the OpenGL pixel path be 205 labeled as sRGB or conventional linear RGB? This would allow 206 pixels labeled as sRGB to be converted to a linear RGB color space 207 prior to processing by the pixel path which includes operations 208 such as convolution, scale, and bias that presume a linear 209 color space. If the destination (say a texture with an sRGB 210 internal format) was sRGB, then linear RGB components would be 211 converted to sRGB prior to being packed into the texture image. 212 This would assume new format parameters to glDrawPixels and 213 glReadPixels indicating the source or destination format was 214 sRGB if a GL_SRGB_EXT or GL_SRGB_ALPHA_EXT format is specified. 215 Likewise, a format parameter to glTexImage2D such as GL_SRGB_EXT 216 would indicate the pixel data was already in an sRGB color space 217 where GL_RGB would indicate a linear color space. New state 218 would indicate if the framebuffer held sRGB or linear RGB pixels. 219 220 RESOLVED: No. 221 222 The pixel path should be left blind to color spaces and provide 223 no implicit conversions. 224 225 Core pixel maps and ARB_imaging provides sufficient color 226 tables so that applications interested in managing color space 227 conversions within the pixel path can do so themselves. 228 229 A 256 entry table outputting floating-point values is sufficient 230 to convert sRGB to linear RGB. 231 232 However when converting from linear RGB to sRGB, one must 233 be careful to make sure the source linear RGB values are 234 specified with more than 8 bits of precision and the color 235 table to implement the conversion must likewise have more than 236 256 entries. A power-of-two table sufficient to map values 237 to each of the 256 sRGB encodings for an 8-bit sRGB component 238 requires at least 4096 entries (a fairly large color table). 239 240 Because vertex and fragment programs and shaders operate in 241 floating-point and have sufficient programmability to implement 242 the sRGB to linear RGB and vice versa without resorting to large 243 tables. 244 245 13) Does this extension imply filtered results from sRGB texture 246 have more than 8 bits of precision? 247 248 RESOLVED: Effectively, yes. 249 250 8-bit components of sRGB texels are converted to linear RGB values 251 which requires more than 8 bits to avoid lose of precision. 252 This implies the filtering involve more than 8 bits of color 253 precision per component. Moreover, fragment color (whether by 254 a fragment program, vertex program, or glTexEnv modes) should 255 operate at precision beyond 8 bits per color component. 256 257 The exact precision maintained (and its distribution) is left to 258 implementations to define but returning at least 12 but more 259 likely 16 linear bits per component, post-filtering, is a 260 reasonable expectation for developers. 261 262 This extension assumes fragment coloring is performed 263 264 14) What must be specified as far as how do you convert to and from 265 sRGB and linear RGB color spaces? 266 267 RESOLVED: The specification language needs to only supply the 268 sRGB to linear RGB conversion (see section 3.8.x below). 269 270 For completeness, the accepted linear RGB to sRGB conversion 271 (the inverse of the function specified in section 3.8.x) is as 272 follows: 273 274 Given a linear RGB component, cl, convert it to an sRGB component, 275 cs, in the range [0,1], with this pseudo-code: 276 277 if (isnan(cl)) { 278 /* Map IEEE-754 Not-a-number to zero. */ 279 cs = 0.0; 280 } else if (cl > 1.0) { 281 cs = 1.0; 282 } else if (cl < 0.0) { 283 cs = 0.0; 284 } else if (cl < 0.0031308) { 285 cs = 12.92 * cl; 286 } else { 287 cs = 1.055 * pow(cl, 0.41666) - 0.055; 288 } 289 290 sRGB components are typically stored as unsigned 8-bit 291 fixed-point values. If cs is computed with the above 292 pseudo-code, cs can be converted to a [0,255] integer with this 293 formula: 294 295 csi = floor(255.0 * cs + 0.5) 296 297 15) Does this extension provide any sort of sRGB framebuffer formats 298 or guarantee images rendered with sRGB textures will "look good" 299 when output to a device supporting an sRGB color space? 300 301 RESOLVED: No. 302 303 Whether the displayed framebuffer is displayed to a monitor that 304 faithfully reproduces the sRGB color space is beyond the scope 305 of this extension. This involves the gamma correction and color 306 calibration of the physical display device. 307 308 With this extension, artists can author content in an sRGB color 309 space and provide that sRGB content for use as texture imagery 310 that can be properly converted to linear RGB and filtered as part 311 of texturing in a way that preserves the sRGB distribution of 312 precision, but that does NOT mean sRGB pixels are output 313 to the framebuffer. Indeed, this extension provides texture 314 formats that convert sRGB to linear RGB as part of filtering. 315 316 With programmable shading, an application could perform a 317 linear RGB to sRGB conversion just prior to emitting color 318 values from the shader. Even so, OpenGL blending (other than 319 simple modulation) will perform linear math operations on values 320 stored in a non-linear space which is technically incorrect for 321 sRGB-encoded colors. 322 323 One way to think about these sRGB texture formats is that they 324 simply provide color components with a distribution of values 325 distributed to favor precision towards 0 rather than evenly 326 distributing the precision with conventional non-sRGB formats 327 such as GL_RGB8. 328 329 16) How does this extension interact with EXT_framebuffer_object? 330 331 RESOLVED: No specific interaction language is necessary but 332 there is no provision that pixels written into a framebuffer 333 object with a texture with an sRGB internal format for its color 334 buffer will in anyway convert the output color values into an sRGB 335 color space. A fragment program or shader could be written to 336 convert linear RGB values to sRGB values prior to shader output, 337 but NO automatic conversion is performed. 338 339 So you can create a texture with an sRGB internal format (such 340 as GL_SRGB8_ALPHA8_EXT), bind that texture to a framebuffer 341 object with glFramebufferTexture2DEXT, and then render into 342 that framebuffer. If you then texture with the sRGB texture, 343 the texels within the texture are treated as sRGB values for 344 filtering. 345 346 17) Should sRGB be supported with a texture parameter rather than 347 new texture formats? 348 349 RESOLVED: Adding new texture formats is the right approach. 350 351 Hardware is expected to implements sRGB conversions via hardwired 352 look-up tables. Such tables are expensive (when sRGB isn't 353 being used, they are basically "wasted gates") and so we want to 354 minimize the number of unique tables that hardware must support. 355 However OpenGL supports various component sizes for RGB and RGBA 356 textures. 357 358 Various RGB texture formats have different bit sizes for R, G, 359 and B that map to [0,1]. Think about RGB5. It encodes values 360 0/15, 1/15, 2/15, ... 14/15, and 15/15. Excepting 0/15==0.0 361 and 15/15==1.0, those values are different than the values 362 for RGB8 which would be 0/255, 1/255, ... 254/255, 255/255. 363 Technically, you'd need a different sRGB table to toggle between 364 RGB4 and sRGB4 than you'd need to toggle between RGB8 and sRGB8. 365 There are also RGB12 and RGB16 textures where it is simply not 366 tractable to implement 4096 and 65,536 entry tables, nor is the 367 "real" sRGB conversion math cheap enough to evaluate directly 368 at those precisions. 369 370 What this extension shouldn't require is sRGB conversion for 371 any component sizes beyond 8-bit. Indeed, it appears the only 372 component sizes sRGB users really care about are 8-bit components. 373 This is because if you have more than 8 bits per component, 374 you typically have enough precision to avoid the complexity 375 created by a non-linear RGB component encoding. Additionally, 376 sRGB users are picky about color reproduction so fewer than 8 377 bits is generally not acceptable to them. 378 379 The problem with making a "toggle" (say controlled by 380 glTexParameter) is that hardware would very likely (indeed 381 it's pretty much certain) not implement toggling between RGB12 382 and sRGB12 formats. Recall that OpenGL doesn't mandate internal 383 formats so you can request GL_RGB8 and have the implementation 384 actually given you RGB12 or RGB10 or R5G6B5. 385 386 It is inappropriate to put in a texture parameter mode where 387 we say "this mode works just with GL_RGB8 and GL_RGBA8 and yet 388 only when the underlying internal format is actually RGB8 or 389 RGBA8". We'd also surely preclude floating-point RGB formats, 390 signed RGB formats, new HDR formats, and certain compressed RGB 391 formats from being included because such formats don't really 392 even make sense for sRGB. 393 394 By adding new formats specifically for the sRGB color space, 395 we avoid all these problems. 396 397 We also avoid an awkward precedent where other more varied 398 color spaces (CYMK, XYZ, and YUV being obvious examples) have 399 to "toggle" between RGB and RGBA formats. Indeed, already 400 extensions for such other color spaces (YUV and CMYK at least) 401 set the precedent of introducing new texture formats. 402 403 18) How is the texture border color handled for sRGB formats? 404 405 RESOLVED: The texture border color is specified as four 406 floating-point values. Given that the texture border color can 407 be specified at such high precision, it is always treated as a 408 linear RGBA value. 409 410 Only texel components are converted from the sRGB encoding to a 411 linear RGB value ahead of texture filtering. The border color 412 can be used "as is" without any conversion. 413 414 The implication of this is, for example, that two textures with 415 GL_RGBA8 and GL_SRGB8_ALPHA8_EXT internal formats respectively and 416 a border color of (0.4, 0.2, 0.9, 0.1) and the GL_CLAMP_TO_BORDER 417 wrap mode will both return (0.4, 0.2, 0.9, 0.1) if 100% of the 418 border color is sampled. 419 420 By keeping the texture border color specified as a linear 421 RGB value at the API level allows developers to specify the 422 high-precision texture border color in a single consistent color 423 space without concern for how the sRGB conversion is implemented 424 in relation to filtering. 425 426 An implementation that does post-filtering sRGB conversion is 427 likely to store convert the texture border color to sRGB within 428 the driver so it can be filtered with the sRGB values coming 429 from texels and then the filtered sRGB value is converted to 430 linear RGB. 431 432 By maintaining the texture border color always in linear RGB, 433 we avoid developers having to know if an implementation is 434 performing the sRGB conversion (ideally) pre-filtering or (less 435 ideally) post-filtering. 436 437 19) How does this extension interact with NV_texture_expand_normal? 438 439 RESOLVED: sRGB components are not affected by the "expand normal" 440 mode even though they are unsigned components because they have 441 non-linear precision (similar to floating-point). 442 443 The alpha component of GL_SRGB8_ALPHA8_EXT and other sRGB formats 444 with an alpha component is affected by the "expand normal" mode. 445 446 The sRGB formats have unsigned components with [0,1] range which 447 is the requirement for the NV_texture_expand_normal extension's 448 operation. 449 450 Be warned because sRGB formats distribute their precision more 451 towards zero, enabling the GL_EXPAND_NORMAL_NV mode with sRGB 452 textures will mean there are more representable negative values 453 than positive values. For example, the 8-bit value 128 maps 454 roughly to zero when encoded with a GL_RGB8 internal format and 455 then remapped with the GL_EXPAND_NORMAL_NV mode. In contrast, 456 the sRGB encoded 8-bit value 188 maps roughly to zero when encoded 457 with a GL_SRGB8_ALPHA8 internal format and then remapped with 458 GL_EXPAND_NORMAL_NV. Still 0 will map to -1 and 255 will map 459 to +1 in either case. 460 461 20) What values should glGetTexImage return? Are the sRGB values 462 returned "as-is" or are they converted to linear RGB first? 463 464 RESOLVED: sRGB values are returned "as-is" without an 465 sRGB-to-linear conversion. Unlike other commands that transfer 466 pixel data, "No pixel transform operations are performed" on 467 the queried texture image. 468 469 21) How does glCopyTex[Sub]Image work with sRGB? Suppose we're 470 rendering to a floating point pbuffer or framebuffer object and 471 do CopyTexImage. Are the linear framebuffer values converted 472 to sRGB during the copy? 473 474 RESOLVED: No, linear framebuffer values will NOT be automatically 475 converted to the sRGB encoding during the copy. If such a 476 conversion is desired, as explained in issue 12, the red, green, 477 and blue pixel map functionality can be used to implement a 478 linear-to-sRGB encoding translation. 479 480 22) Should the new COMPRESSED_SRGB_* formats be listed in an 481 implementation's GL_COMPRESSED_TEXTURE_FORMATS list? 482 483 RESOLVED: No. Section 3.8.1 says formats listed by 484 GL_COMPRESSED_TEXTURE_FORMATS are "suitable for general-purpose 485 usage." The non-linear distribution of red, green, and 486 blue for these sRGB compressed formats makes them not really 487 general-purpose. 488 489 23) Could this extension be implemented by hardware with no special 490 hardware support for sRGB but does support native GL_RGB12 or 491 GL_RGB16 textures? If so, how? 492 493 RESOLVED. Yes. 494 495 The conversion from the sRGB encoding to linear encoding described 496 in section 3.8.x could be performed at texture specification 497 time (after the image has been transformed by the pixel path) 498 rather than texture fetch time. 499 500 When glTexImage2D, glTexSubImage2D, glCopyTexImage2D, etc. occur, 501 the pixels would be transformed by the pixel path as normal and 502 then when pixels are converted to the internal texture format, 503 the section 3.8.x conversion is applied to the red, green, and 504 blue components (not alpha). The result of this conversion 505 can be quantized and stored into the respective red, green, 506 or blue 12-bit or 16-bit component of the stored texel. 507 508 This means when a texture fetch occurs, no fetch-time conversion 509 is required. 510 511 The advantages of this approach is that sRGB conversion is 512 pre-filtering (the ideal) and the hardware is not required to have 513 texture fetch hardware to perform the special sRGB conversion. 514 515 The disadvantage of this technique is that sRGB textures may 516 require more space than required if 8-bit component sRGB components 517 are stored in texture memory. 518 519 The ability to implement this extension in this manner provides 520 one more justification to avoid a "toggle" texture parameter 521 for sRGB conversion or not. 522 523 One caveat to this approach is that glGetTexImage should 524 return the texel values with the sRGB conversion from section 525 3.8.x "reverse converted". (The section 3.8.x function is 526 reversible.) As specified, the conversion is performed at fetch 527 time so the understanding is that data returned by glGetTexImage 528 should be the texels prior to the conversion. If the components 529 are stored converted, that means they must be reverse-converted 530 when returned by glGetTexImage. 531 532 24) How should mipmap generation work for sRGB textures? 533 534 RESOLVED: The best way to perform mipmap generation for sRGB 535 textures is by downsampling the sRGB image in a linear color 536 space. 537 538 This involves converting the RGB components of sRGB texels 539 in a given texture image level to linear RGB space, filtering 540 appropriately in that linear RGB space, and then converting the 541 linear RGB values to sRGB for storage in the downsampled texture 542 level image. 543 544 (Remember alpha, when present, is linear even in sRGB texture 545 formats.) 546 547 The OpenGL specification says "No particular filter algorithm 548 is required, though a box filter is recommended as the default 549 filter" meaning there is no requirement for how even non-sRGB 550 mipmaps should be generated. So while the resolution to this 551 issue is technically a recommendation, it is however a strongly 552 advised recommendation. 553 554 The rationale for why sRGB textures should be converted to 555 linear space prior to filtering and converted back to sRGB after 556 filtering is clear. If an implementation naively simply performed 557 linear filtering on (non-linear) sRGB components as if they were 558 in a linear space, the result tends to be a subtle darkening of 559 the texture images as mipmap generation continues recursively. 560 This darkening is an inappropriate basis that the resolved 561 "best way" above would avoid. 562 563New Procedures and Functions 564 565 None 566 567New Tokens 568 569 Accepted by the <internalformat> parameter of TexImage1D, TexImage2D, 570 TexImage3D, CopyTexImage1D, CopyTexImage2D: 571 572 SRGB_EXT 0x8C40 573 SRGB8_EXT 0x8C41 574 SRGB_ALPHA_EXT 0x8C42 575 SRGB8_ALPHA8_EXT 0x8C43 576 SLUMINANCE_ALPHA_EXT 0x8C44 577 SLUMINANCE8_ALPHA8_EXT 0x8C45 578 SLUMINANCE_EXT 0x8C46 579 SLUMINANCE8_EXT 0x8C47 580 COMPRESSED_SRGB_EXT 0x8C48 581 COMPRESSED_SRGB_ALPHA_EXT 0x8C49 582 COMPRESSED_SLUMINANCE_EXT 0x8C4A 583 COMPRESSED_SLUMINANCE_ALPHA_EXT 0x8C4B 584 585 Accepted by the <internalformat> parameter of TexImage2D, 586 CopyTexImage2D, and CompressedTexImage2DARB and the <format> parameter 587 of CompressedTexSubImage2DARB: 588 589 COMPRESSED_SRGB_S3TC_DXT1_EXT 0x8C4C 590 COMPRESSED_SRGB_ALPHA_S3TC_DXT1_EXT 0x8C4D 591 COMPRESSED_SRGB_ALPHA_S3TC_DXT3_EXT 0x8C4E 592 COMPRESSED_SRGB_ALPHA_S3TC_DXT5_EXT 0x8C4F 593 594Additions to Chapter 2 of the 1.2 Specification (OpenGL Operation) 595 596 None 597 598Additions to Chapter 3 of the 1.2 Specification (Rasterization) 599 600 -- Section 3.8.1, Texture Image Specification: 601 602 Add 4 new rows to Table 3.16 (page 154). 603 604 Sized Base R G B A L I D 605 Internal Format Internal Format bits bits bits bits bits bits bits 606 --------------------- --------------- ---- ---- ---- ---- ---- ---- ---- 607 SRGB8_EXT RGB 8 8 8 608 SRGB8_ALPHA8_EXT RGBA 8 8 8 8 609 SLUMINANCE_EXT LUMINANCE 8 610 SLUMINANCE_ALPHA8_EXT LUMINANCE_ALPHA 8 8 611 612 Add 4 new rows to Table 3.17 (page 155). 613 614 Compressed Internal Format Base Internal Format 615 ----------------------------------- -------------------- 616 COMPRESSED_SRGB_S3TC_DXT1_EXT RGB 617 COMPRESSED_SRGB_ALPHA_S3TC_DXT1_EXT RGBA 618 COMPRESSED_SRGB_ALPHA_S3TC_DXT3_EXT RGBA 619 COMPRESSED_SRGB_ALPHA_S3TC_DXT5_EXT RGBA 620 621 Add 4 new rows to Table 3.18 (page 155). 622 623 Generic Compressed Internal Format Base Internal Format 624 ---------------------------------- -------------------- 625 COMPRESSED_SRGB_EXT RGB 626 COMPRESSED_SRGB_ALPHA_EXT RGBA 627 COMPRESSED_SLUMINANCE_EXT LUMINANCE 628 COMPRESSED_SLUMINANCE_ALPHA_EXT LUMINANCE_ALPHA 629 630 -- Section 3.8.x, sRGB Texture Color Conversion 631 632 Insert this section AFTER section 3.8.14 Texture Comparison Modes 633 and BEFORE section 3.8.15 Texture Application. 634 635 "If the currently bound texture's internal format is one 636 of SRGB_EXT, SRGB8_EXT, SRGB_ALPHA_EXT, SRGB8_ALPHA8_EXT, 637 SLUMINANCE_ALPHA_EXT, SLUMINANCE8_ALPHA8_EXT, SLUMINANCE_EXT, 638 SLUMINANCE8_EXT, COMPRESSED_SRGB_EXT, COMPRESSED_SRGB_ALPHA_EXT, 639 COMPRESSED_SLUMINANCE_EXT COMPRESSED_SLUMINANCE_ALPHA_EXT, 640 COMPRESSED_SRGB_S3TC_DXT1_EXT, COMPRESSED_SRGB_ALPHA_S3TC_DXT1_EXT, 641 COMPRESSED_SRGB_ALPHA_S3TC_DXT3_EXT, or 642 COMPRESSED_SRGB_ALPHA_S3TC_DXT5_EXT, the red, green, and blue 643 components are converted from an sRGB color space to a linear color 644 space as part of filtering described in sections 3.8.8 and 3.8.9. 645 Any alpha component is left unchanged. Ideally, implementations 646 should perform this color conversion on each sample prior to filtering 647 but implementations are allowed to perform this conversion after 648 filtering (though this post-filtering approach is inferior to 649 converting from sRGB prior to filtering). 650 651 The conversion from an sRGB encoded component, cs, to a linear 652 component, cl, is as follows. 653 654 { cs / 12.92, cs <= 0.04045 655 cl = { 656 { ((cs + 0.055)/1.055)^2.4, cs > 0.04045 657 658 Assume cs is the sRGB component in the range [0,1]." 659 660Additions to Chapter 4 of the 1.2 Specification (Per-Fragment Operations 661and the Frame Buffer) 662 663 None 664 665Additions to Chapter 5 of the 1.2 Specification (Special Functions) 666 667 None 668 669Additions to Chapter 6 of the 1.2 Specification (State and State Requests) 670 671 None 672 673Additions to the OpenGL Shading Language specification 674 675 None 676 677Additions to the GLX Specification 678 679 None 680 681Dependencies on ARB_texture_compression and OpenGL 1.3 or later 682 683 If ARB_texture_compression or OpenGL 1.3 or later is NOT supported, 684 ignore the new COMPRESSED_* tokens, the additions to tables 3.17 685 and 3.18, and the errors associated with the Compressed* commands. 686 687Dependencies on EXT_texture_compression_s3tc 688 689 If EXT_texture_compression_s3tc is NOT supported, ignore the new 690 COMPRESSED_*_S3TC_DXT* tokens, the additions to table 3.17, errors 691 related to the COMPRESSED_*_S3TC_DXT* tokens, and related discussion. 692 693 Add COMPRESSED_SRGB_S3TC_DXT1_EXT, 694 COMPRESSED_SRGB_ALPHA_S3TC_DXT1_EXT, 695 COMPRESSED_SRGB_ALPHA_S3TC_DXT3_EXT, and 696 COMPRESSED_SRGB_ALPHA_S3TC_DXT5_EXT to token lists in the section 697 3.8.2 specification language added by EXT_texture_compression_s3tc 698 when the internal formats COMPRESSED_RGB_S3TC_DXT1_EXT, 699 COMPRESSED_RGBA_S3TC_DXT1_EXT, COMPRESSED_RGBA_S3TC_DXT3_EXT, and 700 COMPRESSED_RGBA_S3TC_DXT5_EXT are listed. 701 702Dependencies on NV_texture_compression_vtc 703 704 If NV_texture_compression_vtc IS supported, allow the following 705 tokens to be accepted by the <internalformat> parameter 706 of CompressedTexImage3DARB and the <format> parameter of 707 CompressedTexSubImage3DARB: 708 709 COMPRESSED_SRGB_S3TC_DXT1_EXT 710 COMPRESSED_SRGB_ALPHA_S3TC_DXT1_EXT 711 COMPRESSED_SRGB_ALPHA_S3TC_DXT3_EXT 712 COMPRESSED_SRGB_ALPHA_S3TC_DXT5_EXT 713 714GLX Protocol 715 716 None. 717 718Errors 719 720 Relaxation of INVALID_ENUM errors 721 --------------------------------- 722 723 TexImage1D, TexImage2D, TexImage3D, CopyTexImage1D, CopyTexImage2D, 724 CompressedTexImage2DARB, CompressedTexSubImage2DARB now accept the 725 new tokens as listed in the "New Tokens" section. 726 727 New errors 728 ---------- 729 730 INVALID_OPERATION is generated by CompressedTexImage2DARB if 731 if <internalformat> is COMPRESSED_SRGB_S3TC_DXT1_EXT, 732 COMPRESSED_SRGB_ALPHA_S3TC_DXT1_EXT, 733 COMPRESSED_SRGB_ALPHA_S3TC_DXT3_EXT, or 734 COMPRESSED_SRGB_ALPHA_S3TC_DXT5_EXT and <border> is not equal to 735 zero. 736 737 INVALID_OPERATION is generated by TexSubImage2D 738 CopyTexSubImage2D, or CompressedTexSubImage2D if INTERNAL_FORMAT is 739 COMPRESSED_SRGB_S3TC_DXT1_EXT, COMPRESSED_SRGB_ALPHA_S3TC_DXT1_EXT, 740 COMPRESSED_SRGB_ALPHA_S3TC_DXT3_EXT, or 741 COMPRESSED_SRGB_ALPHA_S3TC_DXT5_EXT and any of the following apply: 742 <width> is not a multiple of four or equal to TEXTURE_WIDTH; <height> 743 is not a multiple of four or equal to TEXTURE_HEIGHT; <xoffset> 744 or <yoffset> is not a multiple of four. 745 746 INVALID_ENUM is generated by CompressedTexImage1DARB if 747 <internalformat> is COMPRESSED_SRGB_S3TC_DXT1_EXT, 748 COMPRESSED_SRGB_ALPHA_S3TC_DXT1_EXT, 749 COMPRESSED_SRGB_ALPHA_S3TC_DXT3_EXT, or 750 COMPRESSED_SRGB_ALPHA_S3TC_DXT5_EXT. 751 752 INVALID_ENUM is generated by CompressedTexSubImage1DARB if <format> is 753 COMPRESSED_SRGB_S3TC_DXT1_EXT, COMPRESSED_SRGB_ALPHA_S3TC_DXT1_EXT, 754 COMPRESSED_SRGB_ALPHA_S3TC_DXT3_EXT, or 755 COMPRESSED_SRGB_ALPHA_S3TC_DXT5_EXT. 756 757 Errors if NV_texture_compression_vtc is NOT supported 758 ----------------------------------------------------- 759 760 INVALID_ENUM is generated by CompressedTexImage3DARB if 761 <internalformat> is COMPRESSED_SRGB_S3TC_DXT1_EXT, 762 COMPRESSED_SRGB_ALPHA_S3TC_DXT1_EXT, 763 COMPRESSED_SRGB_ALPHA_S3TC_DXT3_EXT, or 764 COMPRESSED_SRGB_ALPHA_S3TC_DXT5_EXT. 765 766 INVALID_ENUM is generated by CompressedTexSubImage3DARB if <format> is 767 COMPRESSED_SRGB_S3TC_DXT1_EXT, COMPRESSED_SRGB_ALPHA_S3TC_DXT1_EXT, 768 COMPRESSED_SRGB_ALPHA_S3TC_DXT3_EXT, or 769 COMPRESSED_SRGB_ALPHA_S3TC_DXT5_EXT. 770 771 Errors if NV_texture_compression_vtc IS supported 772 ----------------------------------------------------- 773 774 INVALID_OPERATION is generated by CompressedTexImage3DARB 775 if <internalformat> is COMPRESSED_SRGB_S3TC_DXT1_EXT, 776 COMPRESSED_SRGB_ALPHA_S3TC_DXT1_EXT, 777 COMPRESSED_SRGB_ALPHA_S3TC_DXT3_EXT, or 778 COMPRESSED_SRGB_ALPHA_S3TC_DXT5_EXT and <border> is not equal to 779 zero. 780 781 INVALID_OPERATION is generated by TexSubImage3D or CopyTexSubImage3D 782 if INTERNAL_FORMAT is COMPRESSED_SRGB_S3TC_DXT1_EXT, 783 COMPRESSED_SRGB_ALPHA_S3TC_DXT1_EXT, 784 COMPRESSED_SRGB_ALPHA_S3TC_DXT3_EXT, or 785 COMPRESSED_SRGB_ALPHA_S3TC_DXT5_EXT and any of the following apply: 786 <width> is not a multiple of four or equal to TEXTURE_WIDTH; <height> 787 is not a multiple of four or equal to TEXTURE_HEIGHT; <xoffset> 788 or <yoffset> is not a multiple of four. 789 790 INVALID_OPERATION is generated by CompressedTexSubImage3D 791 if INTERNAL_FORMAT is COMPRESSED_SRGB_S3TC_DXT1_EXT, 792 COMPRESSED_SRGB_ALPHA_S3TC_DXT1_EXT, 793 COMPRESSED_SRGB_ALPHA_S3TC_DXT3_EXT, or 794 COMPRESSED_SRGB_ALPHA_S3TC_DXT5_EXT and any of the following apply: 795 <width> is not a multiple of four or equal to TEXTURE_WIDTH; <height> 796 is not a multiple of four or equal to TEXTURE_HEIGHT; <depth> is not 797 a multiple of four or equal to TEXTURE_DEPTH; <xoffset> <yoffset>, 798 or <zoffset> is not a multiple of four. 799 800New State 801 802 In table 6.17, Textures (page 278), increment the 42 in "n x Z42*" 803 by 16 (or 12 if EXT_texture_compression_s3tc is not supported). 804 805 [NOTE: The OpenGL 2.0 specification actually should read "n x Z48*" 806 because of the 6 generic compressed internal formats in table 3.18.] 807 808New Implementation Dependent State 809 810 None 811 812NVIDIA Implementation Details 813 814 GeForce FX, Quadro FX, and GeForce 6 and 7 Series GPUs store 815 sRGB texels at 8 bits per component. sRGB conversion occurs 816 post-filtering. 817 818Revision History 819 820 0.8: Add issue 24 with recommendation for sRGB mipmap generation. 821 822 0.7: Add issue 23 about alternative implementation based on 823 either GL_RGB12 or GL_RGB16 based on discussions with Jeremy 824 Sandmel. 825 826 0.6: Add issue 22 about GL_COMPRESSED_TEXTURE_FORMATS. 827 828 0.5: Fix grammar, add issues 20 and 21 based on Brian Paul's 829 feedback. 830 831 0.4: Update issue 18 based on Matrox feedback. 832 833 0.3: Update NV_texture_expand_normal interaction. 834