Name EXT_paletted_texture Name Strings GL_EXT_paletted_texture Contact Mark J. Kilgard, NVIDIA Corporation (mjk 'at' nvidia.com) Version Last Modified Date: March 24, 2004 Revision: 1.4 Number 78 Support Intel 810/815. Mesa. Microsoft software OpenGL implementation. Selected NVIDIA GPUs: NV1x (GeForce 256, GeForce2, GeForce4 MX, GeForce4 Go, Quadro, Quadro2), NV2x (GeForce3, GeForce4 Ti, Quadro DCC, Quadro4 XGL), and NV3x (GeForce FX 5xxxx, Quadro FX 1000/2000/3000). NV3 (Riva 128) and NV4 (TNT, TNT2) GPUs and NV4x GPUs do NOT support this functionality (no hardware support). Future NVIDIA GPU designs will no longer support paletted textures. S3 ProSavage, Savage 2000. 3Dfx Voodoo3, Voodoo5. 3Dlabs GLINT. Dependencies GL_EXT_paletted_texture shares routines and enumerants with GL_SGI_color_table with the minor modification that EXT replaces SGI. In all other ways these calls should function in the same manner and the enumerant values should be identical. The portions of GL_SGI_color_table that are used are: ColorTableSGI, GetColorTableSGI, GetColorTableParameterivSGI, GetColorTableParameterfvSGI. COLOR_TABLE_FORMAT_SGI, COLOR_TABLE_WIDTH_SGI, COLOR_TABLE_RED_SIZE_SGI, COLOR_TABLE_GREEN_SIZE_SGI, COLOR_TABLE_BLUE_SIZE_SGI, COLOR_TABLE_ALPHA_SIZE_SGI, COLOR_TABLE_LUMINANCE_SIZE_SGI, COLOR_TABLE_INTENSITY_SIZE_SGI. Portions of GL_SGI_color_table which are not used in GL_EXT_paletted_texture are: CopyColorTableSGI, ColorTableParameterivSGI, ColorTableParameterfvSGI. COLOR_TABLE_SGI, POST_CONVOLUTION_COLOR_TABLE_SGI, POST_COLOR_MATRIX_COLOR_TABLE_SGI, PROXY_COLOR_TABLE_SGI, PROXY_POST_CONVOLUTION_COLOR_TABLE_SGI, PROXY_POST_COLOR_MATRIX_COLOR_TABLE_SGI, COLOR_TABLE_SCALE_SGI, COLOR_TABLE_BIAS_SGI. EXT_paletted_texture can be used in conjunction with EXT_texture3D. EXT_paletted_texture modifies TexImage3DEXT to accept paletted image data and allows TEXTURE_3D_EXT and PROXY_TEXTURE_3D_EXT to be used a targets in the color table routines. If EXT_texture3D is unsupported then references to 3D texture support in this spec are invalid and should be ignored. EXT_paletted_texture can be used in conjunction with ARB_texture_cube_map. EXT_paletted_texture modifies TexImage2D to accept paletted image data and allows TEXTURE_CUBE_MAP_ARB, and PROXY_TEXTURE_CUBE_MAP_ARB to be used a targets in the color table routines. If ARB_texture_cube_map is unsupported then references to cube map texture support in this spec are invalid and should be ignored. Overview EXT_paletted_texture defines new texture formats and new calls to support the use of paletted textures in OpenGL. A paletted texture is defined by giving both a palette of colors and a set of image data which is composed of indices into the palette. The paletted texture cannot function properly without both pieces of information so it increases the work required to define a texture. This is offset by the fact that the overall amount of texture data can be reduced dramatically by factoring redundant information out of the logical view of the texture and placing it in the palette. Paletted textures provide several advantages over full-color textures: * As mentioned above, the amount of data required to define a texture can be greatly reduced over what would be needed for full-color specification. For example, consider a source texture that has only 256 distinct colors in a 256 by 256 pixel grid. Full-color representation requires three bytes per pixel, taking 192K of texture data. By putting the distinct colors in a palette only eight bits are required per pixel, reducing the 192K to 64K plus 768 bytes for the palette. Now add an alpha channel to the texture. The full-color representation increases by 64K while the paletted version would only increase by 256 bytes. This reduction in space required is particularly important for hardware accelerators where texture space is limited. * Paletted textures allow easy reuse of texture data for images which require many similar but slightly different colored objects. Consider a driving simulation with heavy traffic on the road. Many of the cars will be similar but with different color schemes. If full-color textures are used a separate texture would be needed for each color scheme, while paletted textures allow the same basic index data to be reused for each car, with a different palette to change the final colors. * Paletted textures also allow use of all the palette tricks developed for paletted displays. Simple animation can be done, along with strobing, glowing and other palette-cycling effects. All of these techniques can enhance the visual richness of a scene with very little data. IP Status None. New Procedures and Functions void ColorTableEXT( enum target, enum internalFormat, sizei width, enum format, enum type, const void *data); void ColorSubTableEXT( enum target, sizei start, sizei count, enum format, enum type, const void *data); void GetColorTableEXT( enum target, enum format, enum type, void *data); void GetColorTableParameterivEXT( enum target, enum pname, int *params); void GetColorTableParameterfvEXT( enum target, enum pname, float *params); New Tokens Accepted by the internalformat parameter of TexImage1D, TexImage2D and TexImage3DEXT: COLOR_INDEX1_EXT 0x80E2 COLOR_INDEX2_EXT 0x80E3 COLOR_INDEX4_EXT 0x80E4 COLOR_INDEX8_EXT 0x80E5 COLOR_INDEX12_EXT 0x80E6 COLOR_INDEX16_EXT 0x80E7 Accepted by the pname parameter of GetColorTableParameterivEXT and GetColorTableParameterfvEXT: COLOR_TABLE_FORMAT_EXT 0x80D8 COLOR_TABLE_WIDTH_EXT 0x80D9 COLOR_TABLE_RED_SIZE_EXT 0x80DA COLOR_TABLE_GREEN_SIZE_EXT 0x80DB COLOR_TABLE_BLUE_SIZE_EXT 0x80DC COLOR_TABLE_ALPHA_SIZE_EXT 0x80DD COLOR_TABLE_LUMINANCE_SIZE_EXT 0x80DE COLOR_TABLE_INTENSITY_SIZE_EXT 0x80DF Accepted by the value parameter of GetTexLevelParameter{if}v: TEXTURE_INDEX_SIZE_EXT 0x80ED Accepted by the target parameter of ColorTableEXT, GetColorTableParameterivEXT, and GetColorTableParameterfvEXT: TEXTURE_1D 0x0DE0 TEXTURE_2D 0x0DE1 TEXTURE_3D_EXT 0x806F TEXTURE_CUBE_MAP_ARB 0x8513 PROXY_TEXTURE_1D 0x8063 PROXY_TEXTURE_2D 0x8064 PROXY_TEXTURE_3D_EXT 0x8070 PROXY_TEXTURE_CUBE_MAP_ARB 0x851B Accepted by the target parameter of ColorSubTableEXT and GetColorTableEXT: TEXTURE_1D 0x0DE0 TEXTURE_2D 0x0DE1 TEXTURE_3D_EXT 0x806F TEXTURE_CUBE_MAP_ARB 0x8513 Additions to Chapter 2 of the GL Specification (OpenGL Operation) None Additions to Chapter 3 of the GL Specification (Rasterization) Section 3.6.4, 'Pixel Transfer Operations,' subsection 'Color Index Lookup,' Point two is modified from 'The groups will be loaded as an image into texture memory' to 'The groups will be loaded as an image into texture memory and the internalformat parameter is not one of the color index formats from table 3.8.' Section 3.8, 'Texturing,' subsection 'Texture Image Specification' is modified as follows: The portion of the first paragraph discussing interpretation of format, type and data is split from the portion discussing target, width and height. The target, width and height section now ends with the sentence 'Arguments width and height specify the image's width and height.' The format, type and data section is moved under a subheader 'Direct Color Texture Formats' and begins with 'If internalformat is not one of the color index formats from table 3.8,' and continues with the existing text through the internalformat discussion. After that section, a new section 'Paletted Texture Formats' has the text: If format is given as COLOR_INDEX then the image data is composed of integer values representing indices into a table of colors rather than colors themselves. If internalformat is given as one of the color index formats from table 3.8 then the texture will be stored internally as indices rather than undergoing index-to-RGBA mapping as would previously have occurred. In this case the only valid values for type are BYTE, UNSIGNED_BYTE, SHORT, UNSIGNED_SHORT, INT and UNSIGNED_INT. The image data is unpacked from memory exactly as for a DrawPixels command with format of COLOR_INDEX for a context in color index mode. The data is then stored in an internal format derived from internalformat. In this case the only legal values of internalformat are COLOR_INDEX1_EXT, COLOR_INDEX2_EXT, COLOR_INDEX4_EXT, COLOR_INDEX8_EXT, COLOR_INDEX12_EXT and COLOR_INDEX16_EXT and the internal component resolution is picked according to the index resolution specified by internalformat. Any excess precision in the data is silently truncated to fit in the internal component precision. An application can determine whether a particular implementation supports a particular paletted format (or any paletted formats at all) by attempting to use the paletted format with a proxy target. TEXTURE_INDEX_SIZE_EXT will be zero if the implementation cannot support the texture as given. An application can determine an implementation's desired format for a particular paletted texture by making a TexImage call with COLOR_INDEX as the internalformat, in which case target must be a proxy target. After the call the application can query TEXTURE_INTERNAL_FORMAT to determine what internal format the implementation suggests for the texture image parameters. TEXTURE_INDEX_SIZE_EXT can be queried after such a call to determine the suggested index resolution numerically. The index resolution suggested by the implementation does not have to be as large as the input data precision. The resolution may also be zero if the implementation is unable to support any paletted format for the given texture image. Table 3.8 should be augmented with a column titled 'Index bits.' All existing formats have zero index bits. The following formats are added with zeroes in all existing columns: Name Index bits COLOR_INDEX1_EXT 1 COLOR_INDEX2_EXT 2 COLOR_INDEX4_EXT 4 COLOR_INDEX8_EXT 8 COLOR_INDEX12_EXT 12 COLOR_INDEX16_EXT 16 At the end of the discussion of level the following text should be added: All mipmapping levels share the same palette. If levels are created with different precision indices then their internal formats will not match and the texture will be inconsistent, as discussed above. In the discussion of internalformat for CopyTexImage{12}D, at end of the sentence specifying that 1, 2, 3 and 4 are illegal there should also be a mention that paletted internalformat values are illegal. At the end of the width, height, format, type and data section under TexSubImage there should be an additional sentence: If the target texture has an color index internal format then format may only be COLOR_INDEX. At the end of the first paragraph describing TexSubImage and CopyTexSubImage the following sentence should be added: If the target of a CopyTexSubImage is a paletted texture image then INVALID_OPERATION is returned. After the Alternate Image Specification Commands section, a new 'Palette Specification Commands' section should be added. Paletted textures require palette information to translate indices into full colors. The command void ColorTableEXT(enum target, enum internalformat, sizei width, enum format, enum type, const void *data); is used to specify the format and size of the palette for paletted textures. target specifies which texture is to have its palette changed and may be one of TEXTURE_1D, TEXTURE_2D, PROXY_TEXTURE_1D, PROXY_TEXTURE_2D, TEXTURE_3D_EXT, PROXY_TEXTURE_3D_EXT, TEXTURE_CUBE_MAP_ARB, or PROXY_TEXTURE_CUBE_MAP_ARB. internalformat specifies the desired format and resolution of the palette when in its internal form. internalformat can be any of the non-index values legal for TexImage internalformat although implementations are not required to support palettes of all possible formats. width controls the size of the palette and must be a power of two greater than or equal to one. format and type specify the number of components and type of the data given by data. format can be any of the formats legal for DrawPixels although implementations are not required to support all possible formats. type can be any of the types legal for DrawPixels except GL_BITMAP. Data is taken from memory and converted just as if each palette entry were a single pixel of a 1D texture. Pixel unpacking and transfer modes apply just as with texture data. After unpacking and conversion the data is translated into a internal format that matches the given format as closely as possible. An implementation does not, however, have a responsibility to support more than one precision for the base formats. If the palette's width is greater than than the range of the color indices in the texture data then some of the palettes entries will be unused. If the palette's width is less than the range of the color indices in the texture data then the most-significant bits of the texture data are ignored and only the appropriate number of bits of the index are used when accessing the palette. Specifying a proxy target causes the proxy texture's palette to be resized and its parameters set but no data is transferred or accessed. If an implementation cannot handle the palette data given in the call then the color table width and component resolutions are set to zero. Portions of the current palette can be replaced with void ColorSubTableEXT(enum target, sizei start, sizei count, enum format, enum type, const void *data); target can be any of the non-proxy values legal for ColorTableEXT. start and count control which entries of the palette are changed out of the range allowed by the internal format used for the palette indices. count is silently clamped so that all modified entries all within the legal range. format and type can be any of the values legal for ColorTableEXT. The data is treated as a 1D texture just as in ColorTableEXT. In the 'Texture State and Proxy State' section the sentence fragment beginning 'six integer values describing the resolutions...' should be changed to refer to seven integer values, with the seventh being the index resolution. Palette data should be added in as a third category of texture state. After the discussion of properties, the following should be added: Next there is the texture palette. All textures have a palette, even if their internal format is not color index. A texture's palette is initially one RGBA element with all four components set to 1.0. The sentence mentioning that proxies do not have image data or properties should be extended with 'or palettes.' The sentence beginning 'If the texture array is too large' describing the effects of proxy failure should change to read: If the implementation is unable to handle the texture image data the proxy width, height, border width and component resolutions are set to zero. This situation can occur when the texture array is too large or an unsupported paletted format was requested. Additions to Chapter 4 of the GL Specification (Per-Fragment Operations and the Framebuffer) None Additions to Chapter 5 of the GL Specification (Special Functions) Section 5.4, 'Display Lists' is modified as follows: Include PROXY_TEXTURE_1D, PROXY_TEXTURE_2D, PROXY_TEXTURE_3D, and PROXY_TEXTURE_CUBE_MAP_ARB in the list of tokens for which ColorTableEXT is executed immediately. Additions to Chapter 6 of the GL Specification (State and State Requests) In the section on GetTexImage, the sentence saying 'The components are assigned among R, G, B and A according to' should be changed to be If the internal format of the texture is not a color index format then the components are assigned among R, G, B, and A according to Table 6.1. Specifying COLOR_INDEX for format in this case will generate the error INVALID_ENUM. If the internal format of the texture is color index then the components are handled in one of two ways depending on the value of format. If format is not COLOR_INDEX, the texture's indices are passed through the texture's palette and the resulting components are assigned among R, G, B, and A according to Table 6.1. If format is COLOR_INDEX then the data is treated as single components and the palette indices are returned. Components are taken starting... Following the GetTexImage section there should be a new section: GetColorTableEXT is used to get the current texture palette. void GetColorTableEXT(enum target, enum format, enum type, void *data); GetColorTableEXT retrieves the texture palette of the texture given by target. target can be any of the non-proxy targets valid for ColorTableEXT. format and type are interpreted just as for ColorTableEXT. All textures have a palette by default so GetColorTableEXT will always be able to return data even if the internal format of the texture is not a color index format. Palette parameters can be retrieved using void GetColorTableParameterivEXT(enum target, enum pname, int *params); void GetColorTableParameterfvEXT(enum target, enum pname, float *params); target specifies the texture being queried and pname controls which parameter value is returned. Data is returned in the memory pointed to by params. Querying COLOR_TABLE_FORMAT_EXT returns the internal format requested by the most recent ColorTableEXT call or the default. COLOR_TABLE_WIDTH_EXT returns the width of the current palette. COLOR_TABLE_RED_SIZE_EXT, COLOR_TABLE_GREEN_SIZE_EXT, COLOR_TABLE_BLUE_SIZE_EXT and COLOR_TABLE_ALPHA_SIZE_EXT return the actual size of the components used to store the palette data internally, not the size requested when the palette was defined. Table 6.11, "Texture Objects" should have a line appended for TEXTURE_INDEX_SIZE_EXT: TEXTURE_INDEX_SIZE_EXT n x Z+ GetTexLevelParameter 0 xD texture image i's index resolution 3.8 - New State In table 6.16, Texture Objects, p. 224, add the following: Get Value Type Get Command Initial Value Description Sec. Attribute ---------------------- -------- --------------------------- ------------- ---------------- ----- --------- TEXTURE_1D I GetColorTableEXT empty 1D palette 3.8 - TEXTURE_2D I GetColorTableEXT empty 2D palette 3.8 - TEXTURE_3D I GetColorTableEXT empty 3D palette 3.8 - TEXTURE_CUBE_MAP I GetColorTableEXT empty cube map palette 3.8 - COLOR_TABLE_FORMAT_EXT 2x4xZn GetColorTableParameterivEXT RGBA paletted texture 3.8 - formats COLOR_TABLE_WIDTH_EXT 2x4xZ+ GetColorTableParameteriv 0 paletted texture 3.8 - width COLOR_TABLE_x_SIZE_EXT 6x2x4xZ+ GetColorTableParameteriv 0 paletted texture 3.8 - component sizes TEXTURE_INDEX_SIZE_EXT nxZ+ GetTexLevelParameter 0 texture image's 3.8 - index resolution New Implementation Dependent State None Revision History Original draft, revision 0.5, December 20, 1995 (drewb) Created Minor revisions and clarifications, revision 0.6, January 2, 1996 (drewb) Replaced all request-for-comment blocks with final text based on implementation. Minor revisions and clarifications, revision 0.7, Feburary 5, 1996 (drewb) Specified the state of the palette color information when existing data is replaced by new data. Clarified behavior of TexPalette on inconsistent textures. Major changes due to ARB review, revision 0.8, March 1, 1996 (drewb) Switched from using TexPaletteEXT and GetTexPaletteEXT to using SGI's ColorTableEXT routines. Added ColorSubTableEXT so equivalent functionality is available. Allowed proxies in all targets. Changed PALETTE?_EXT values to COLOR_INDEX?_EXT. Added support for one and two bit palettes. Removed PALETTE_INDEX_EXT in favor of COLOR_INDEX. Decoupled palette size from texture data type. Palette size is controlled only by ColorTableEXT. Changes due to ARB review, revision 1.0, May 23, 1997 (drewb) Mentioned texture3D. Defined TEXTURE_INDEX_SIZE_EXT. Allowed implementations to return an index size of zero to indicate no support for a particular format. Allowed usage of GL_COLOR_INDEX as a generic format in proxy queries for determining an optimal index size for a particular texture. Disallowed CopyTexImage and CopyTexSubImage to paletted formats. Deleted mention of index transfer operations during GetTexImage with paletted formats. Changes due to ARB_texture_cube_map, revision 1.1, June 27, 2002 (Mark Kilgard) Add language to section 5.4 about proxy texture tokens for ColorTable executing immediately. Document ARB_texture_cube_map interactions. Document texture target usage for ColorTable API. Add "New State" section with table and "New Implementation Dependent State" sections. Changes when incorporating into the registry, September 4, 2002 (Jon Leech) Added missing IP Status / Contact fields (without bumping the revision) and incorporated Mark's changes into the registry. Changes, revision 1.4, March 24, 2004 (Mark Kilgard) Document vendor support for this extension; note that future NVIDIA GPU designs will not support this extension.