XXX - Not complete -- needs errors & GLX protocol
work


Name

    SGIX_icc_texture

Name Strings

    GL_SGIX_icc_texture

Version

    $Date: 1999/06/09 18:23:05 $ $Revision: 1.16 $

Number

    154

Dependencies

    OpenGL 1.1 is required.
    EXT_texture3D affects the definition of this extension
    SGIS_texture4D affects the definition of this extension

Overview

    This extension defines new host and internal formats for the
    storage of compressed images.  The formats utilize a variant of
    color cell compression, in which 4x4 pixel blocks are represented
    by two color values and a two bit index per pixel.  Two additional
    values are interpolated between the two explicitly stored values,
    and each pixel's index selects one of these four values.  For RGB
    and RGBA images, two RGB colors and a single index per pixel are
    used to store the R, G, and B channels.  For RGBA and
    LUMINANCE_ALPHA formats, the alpha channel is encoded
    independently using two alpha values and an index per pixel.  

Issues

    - Do we really want compressed textures to be a full-blown host
      format that may be used to specify things like color tables?
      Orthogonality says yes, simplicity says no.  

      A: ICC formats don't seem useful for things other than textures
      so limit it to that.

    - What about one, three, and four dimensional textures?  

      A: Three and four should work as stacks of 2D textures.  One
      could be made to work but the natural hardware implementation
      would be to have a block represent a 16x1 subimage.  The
      locality probably wouldn't be good and equivalent results could
      be obtained with texture filtering.

    - Method of dealing with width & height of host image is awkward
      when downloading small mipmap levels since UNPACK_ROW_LENGTH
      must be set.  Should we say that the rounding up happens
      automatically? 

      A:  Yes.

    - Should unpacking of ICC formats be described in the section
      about pixel rectangles (with the rest of the unpacking) or in
      the section about texture downloads (since they cannot be used
      in any other situation)?  Similar question for readbacks.

    - There are still some problems with the sized and base internal
      formats.  We're ok for now since there is only one sized
      internal format for each base internal format.  Can we get rid
      of the unsized internal formats?

    - Need to say that pixel transfer modes are not applied.  Ideally this
      should be done in such a way that removing this restriction in a
      later extension is not a problem.  We could say that trying to
      do a ICC download with a non-identity pixel transfer operation
      applied results in an error, but checking for non-identity pixel
      transfer operations can be tricky.

    - Is there any way to change this extension such that
      implementations which don't support a certain compressed format
      can "fake it?"  With the "no compressor" limitation this might
      require the texture manager to maintain a shadowed copy of the
      compressed texture and put decompressed versions in texture
      memory. 

    - Need to document behavior when interlacing is on.  Won't work
      but should it be ignored or an error?

Reasoning

    - This spec is designed to avoid adding the ability to compress
      into the ICC formats within GL.  Therefore, we do not allow
      subtexture downloads which are not aligned to the 4x4 tile size
      or downloads of host images which are not already in a ICC
      format.  This ability can be added by a subsequent extension.
      For now, the compression should go in a GLU extension.

New Procedures and Functions

    None

New Tokens

    Accepted by the <internalformat> parameter of TexImage2D,
    TexImage3DEXT, and TexImage4DSGIS:

    RGB_ICC_SGIX			0x8460
    RGBA_ICC_SGIX			0x8461
    ALPHA_ICC_SGIX			0x8462
    LUMINANCE_ICC_SGIX			0x8463
    INTENSITY_ICC_SGIX			0x8464
    LUMINANCE_ALPHA_ICC_SGIX		0x8465

    Accepted by the <internalformat> and <format> parameters of
    TexImage2D, TexImage3DEXT, and TexImage4DSGIS:

    R5_G6_B5_ICC_SGIX			0x8466
    R5_G6_B5_A8_ICC_SGIX		0x8467
    ALPHA16_ICC_SGIX			0x8468
    LUMINANCE16_ICC_SGIX		0x8469
    INTENSITY16_ICC_SGIX		0x846A
    LUMINANCE16_ALPHA8_ICC_SGIX		0x846B

Additions to Chapter 2 of the 1.1 Specification (OpenGL Operation)

    None

Additions to Chapter 3 of the 1.1 Specification (Rasterization)

    The following is added to the end if the last paragraph in the
    introduction: "Six ICC formats are described in this section:
    R5_G6_B5_ICC_SGIX, R5_G6_B5_A8_ICC_SGIX, ALPHA16_ICC_SGIX,
    LUMINANCE16_ICC_SGIX, INTENSITY16_ICC_SGIX, and
    LUMINANCE16_ALPHA8_ICC_SGIX. The ICC formats are used only as
    arguments to texture download commands and not as arguments to
    other commands which take pixel data from client memory.  If the
    format argument to a command other than a texture download command
    is an enumerant for a ICC format, the error INVALID_ENUM is
    generated.  Other restrictions on the use of ICC formats are
    described below and in Section 3.8"

    The following is added to section 3.6.3 at the end of the
    subsection entitled "Unpacking":

    If the data in host memory is in one of the ICC formats, the data
    is treated as being a sequence of blocks each of which represents
    a 4x4 pixel subimage.  The blocks are stored in a row-major order,
    analogous to the host memory storage of pixels.  The length of
    each block in words and how it is decoded depends on the specific
    ICC format.  This information is given in the subsection
    "Decompression from ICC."  For each format, the block length is a
    non-zero integer number of words.  The type argument to the
    function must be set to GL_UNSIGNED_SHORT or the error
    INVALID_ENUM will be generated.

    A ICC-compressed image in host memory must be made of complete 4x4
    blocks.  The width and height arguments give the uncompressed size
    and both must be multiples of four.  The number of pixels in a row
    of the host image is determined in the same manner as for
    uncompressed host images.  If this value is not a multiple of
    four, it is rounded up to the next multiple of four.  The
    resulting value is referred to as l.  If p indicates the location
    in memory of the first byte of the first block of the first row,
    then the first byte of the first block of the Nth row is indicated
    by

        p + (N/4)k

    where N is the row number (counting from zero).  N must be a
    multiple of four; rows which are not four-aligned may not be
    individually accessed. k is defined as:

        k = ceil(sl / a) * a

    where s is the size of a block for the given format in GL ubytes
    and a is the value of UNPACK_ALIGNMENT.

    The height h of the host image is assumed to be:

        h = ceil((height + s) / 4) * 4

    where s is the value of SKIP_ROWS and height is the value of the
    height argument to the pixel function.  In other words, the sum of
    the value of SKIP_ROWS and the height argument to the function is
    rounded up to the next multiple of four to give the height of the
    host image.

    Subrectangles of ICC images may be extracted in a manner similar
    to uncompressed images as determined by the parameters
    UNPACK_ROW_LENGTH, UNPACK_SKIP_ROWS, and UNPACK_SKIP_PIXELS.  For
    compressed images, the lower left corner of the subrectangle must
    be aligned to four-pixel boundaries in both x and y.  The values
    of UNPACK_SKIP_ROWS and UNPACK_SKIP_PIXELS must be multiples of
    four (positive, negative, or zero) or the error INVALID_OPERATION
    is generated.  Before obtaining the first group from memory, the
    pointer p is effectively advanced by (UNPACK_SKIP_PIXELS / 4)s +
    (UNPACK_SKIP_ROWS/4)k bytes.  ceil(width / 4) blocks are
    obtained from contiguous memory (without advancing the pointer),
    after which the pointer is advanced by k bytes.  ceil(height/4)
    sets of ceil(width/4) blocks are obtained this way.

    The following is added to the end of table 3.5:

					Element Meaning		Target
	Name				and Order		Buffer
	----				---------------		--------
	RGB_ICC_SGIX			R, G, B Components	Color
	RGBA_ICC_SGIX			R, G, B, A Components	Color
	LUMINANCE_ICC_SGIX		Luminance Component	Color
	LUMINANCE_ALPHA_ICC_SGIX	Luminance, A Components	Color

    The following subsection is added to section 3.6.3 just prior to
    the subsection entitled "Conversion to floating-point":

    Decompression from ICC

    After being extracted from host memory, a ICC-compressed image is
    converted into a floating-point color image.  Each 4x4 block is
    decompressed independently using mechanisms described below.  We
    start by describing mechanisms we will describe mechanisms common
    to all ICC formats and then describe the organization of the data
    within a block for each format.  In this section, we assume that
    byte swapping (if SWAP_BYTES is TRUE) has already taken place.

    Each ICC format contains one or two fields containing 2-bit
    indices for the each of the 16 pixels in the block.  Within the
    field, the indices are stored in bottom-to-top, left-to-right
    order regardless of user-specified pixel storage modes.  The index
    of the bottom left pixel is stored in the two high-order bits of
    the first byte of the field.  The index of the top right pixel is
    stored in the low-order bits of the last byte.

    For ICC formats which contain RGB data (R5_G6_B5_ICC_SGIX and
    R5_G6_B5_A8_ICC_SGIX), two field contain RGB color values.  The
    fields are each 16 bits wide with the top 5 bits specifying the
    red value, the middle 6 bits specifying the green value, and the
    lower 5 bits specifying the blue value.  For ICC formats which
    contain luminance data (LUMINANCE16_ICC_SGIX and
    LUMINANCE16_ALPHA8_ICC_SGIX), two 16-bit wide fields contain
    luminance values.  For ICC formats which contain alpha data
    (R5_G6_B5_A8_ICC_SGIX and LUMINANCE16_ALPHA8_ICC_SGIX), two 8-bit
    wide fields contain alpha values.  For each channel, the bits are
    interpreted as unsigned fixed-point values between 0 and 1 and are
    converted to floating point using the formula:

        f = c / ((2**N) - 1)

    where f is the floating-point representation of the value, c is
    the value of the bitfield (interpreted as an unsigned integer), N
    is the number of bits in the fixed-point color value, and the
    division is performed in floating-point.

    Once the color fields have been extracted and converted into
    floating point RGB, L, or A values, intermediate values are
    constructed from them.  For each pair of fields c0 and c1, four
    values are created:

        v0 = c0
        v1 = (2 * c0 + c1) / 3
        v2 = (c0 + 2 * c1) / 3
        v3 = c1

    Operations are performed with unspecified precision.  For fields
    which encode RGB data, the computations are performed independently
    on a per-channel basis to give the vectors RGB0, RGB1, RGB2, and
    RGB3.  For fields which encode alpha data, the computations give
    the values A0, A1, A2, and A3.  For fields which encode luminance
    data, the computations give L0, L1, L2, and L3.

    After the intermediate values are created, indices for each pixel
    are used to choose the output value for the pixel.  The indices
    are each two bits.  R5_G6_B5_ICC_SGIX values contain one index per
    pixel to choose the intermediate value RGB0, RGB1, RGB2, or RGB3.
    R5_G6_B5_A8_ICC_SGIX values contain two indices per pixel: one to
    choose the RGB value and one to choose the alpha value.
    Similarly, LUMINANCE16_A8_ICC_SGIX values contain an index per
    pixel to choose the luminance value and an index per pixel to
    choose the alpha value.  LUMINANCE16_ICC_SGIX values contain an
    index per pixel to choose the luminance value.  In each case, an
    index value of 0 results in the channel (or channels) being set to
    the 0th intermediate value (RGB0, A0, or L0).  A value of 1 gives
    the 1st intermediate value and so on.

    The bit encodings for the formats are described below.  Each
    description assumes that the first byte is in the lowest memory
    location and the last byte is in the highest memory location.  The
    high-order bit of each byte is assumed to be the "first."

    An R5_G6_B5_ICC_SGIX encoded block consists of 64 bits divided
    into 3 fields.  The first is a 32 bit field containing the two-bit
    indices for the RGB channels.  The second and third fields are 16
    bit R5G6B5 values containing c0 and c1 for the RGB channels.

    R5_G6_B5_A8_ICC_SGIX blocks encode RGB and alpha independently.
    An R5_G6_B5_A8_ICC_SGIX encoded block consists of 128 bits divided
    into 7 fields.  The first 64 bits of the block contain the two-bit
    RGB indices followed by the two 16-bit R5G6B5 values for c0 and c1
    (this encoding is equivalent to the 64-bit R5_G6_B5_ICC_SGIX block
    described above).  The fourth field is 32 bits wide and contains
    indices for the alpha values.  The fifth and sixth fields are 8
    bit alpha representing c0 and c1.  The seventh field is 16 bits
    wide and is unused.  It is necessary to pad out the block so that
    the 16-bit color boundaries will always fall on half-word
    boundaries in host memory.

    An ALPHA16_ICC_SGIX, LUMINANCE16_ICC_SGIX, or INTENSITY16_ICC_SGIX
    encoded block consists of 64 bits divided into 3 fields.  The
    first is a 32 bit field containing the two-bit indices for the
    alpha, luminance, or intensity values.  The second and third
    fields are 16 bit unsigned fixed-point alpha, luminance, or
    intensity values containing c0 and c1 respectively.  This encoding
    is identical to the encoding of R5_G6_B5_ICC_SGIX blocks except
    that the c0 and c1 fields represent alpha, luminance, or intensity
    instead of RGB.

    A LUMINANCE16_ALPHA8_ICC_SGIX encoded block is identical to a
    R5_G6_B5_A8_ICC_SGIX block except that sixteen-bit unsigned
    luminance values are stored in place of the sixteen-bit RGB
    values.

    After decompression, the image is recombined into a ceil(width /
    4) * 4 by ceil(height / 4) * 4 image of RGB, RGBA, A, L, I, or LA
    pixels.  Pixels whose y positions in the image (where the bottom
    row is 0 and the top row is (ceil(height / 4) * 4) - 1) are
    greater than (height - 1) are discarded.  Likewise, pixels whose x
    positions are greater than (width - 1) are discarded.

    The following is added to Section 3.8:

    In the paragraph beginning "The image itself (pointed to by data)"
    the sentence beginning "Each color component is converted" is
    prefixed by "If the internal format of the texture is not one of
    RGB_ICC_SGIX, RGBA_ICC_SGIX, LUMINANCE_ICC_SGIX,
    LUMINANCE_ALPHA_ICC_SGIX, R5_G6_B5_ICC_SGIX, R5_G6_B5_A8_ICC_SGIX,
    LUMINANCE16_ICC_SGIX, or LUMINANCE16_ALPHA8_ICC_SGIX."  The
    following is added to the end of the paragraph: "If the internal
    format is one of the ICC formats, the format parameter of the
    function must either be equal to the internal format parameter (if
    the internal format parameter is sized) or contain the same
    channels as the internal format (if the internal format is
    unsized) or the error INVALID_ENUM will be generated.  Also, a ICC
    internal format may not be specified for a one-dimensional
    texture.  If the format parameter to TexImage1D is set to one of
    the ICC internal formats, the error INVALID_ENUM is generated."

    The sentence in the paragraph describing CopyTexImage2D which
    reads: "Parameters level, internalformat, and border are specified
    using the same values, with the same meanings, as the equivalent
    arguments of TexImage2D, except that internalformat may not be
    specified as 1, 2, 3, or 4." is changed to read: "Parameters
    level, internalformat, and border are specified using the same
    values, with the same meanings, as the equivalent arguments of
    TexImage2D, except that internalformat may not be specified as 1,
    2, 3, 4, or any of the ICC internal formats."  

    The following is added to the end of the paragraph which describes
    the subtexture download and copy commands: "CopyTexSubImage1D and
    CopyTexSubImage2D may not be used with a target texture whose
    internal format is one of the ICC formats or the error
    INVALID_OPERATION is generated.  For TexSubImage1D and
    TexSubImage2D, the target texture have a ICC internal format but
    requirements in addition to those mentioned above are enforced.
    The xoffset and yoffset parameters must be multiples of four or
    the error INVALID_OPERATION is generated.  Also, the width
    parameter must either be a multiple of four which is less than the
    width of the texture minus xoffset or be equal to the width of the
    texture minus xoffset or the error INVALID_VALUE is generated.
    The height parameter must either a multiple of four which is less
    than the height of the texture minus yoffset or be equal to the
    height of the texture minus yoffset or the error INVALID_VALUE is
    generated.  In other words, the subimage may not partially cover a
    4x4 region of the target texture.  Additionally, for
    TexSubImage2D, TexSubImage3DEXT, and TexSubImage4DSGIS calls, the
    format parameter must have the same channels as the base internal
    format of the texture or the error INVALID_ENUM will be
    generated."

    The following is added to Table 3.8:

    Sized				Base            R       G       B       A       L       I
    Internal Format		Internal Format Bits    Bits    Bits    Bits    Bits    Bits
    ---------------		--------------- ----    ----    ----    ----    ----    ----
    R5_G6_B5_ICC_SGIX		RGB             	5       6       5
    R5_G6_B5_A8_ICC_SGIX	RGBA            	5       6       5       8
    LUMINANCE16_ICC_SGIX	LUMINANCE                               		16
    LUMINANCE16_ALPHA8_ICC_SGIX	LUMINANCE_ALPHA                         	8	16

    The caption for Table 3.8 is updated as follows:
    
    Correspondence of sized internal formats to base internal formats
    and desired component resolutions for each sized internal format.
    For ICC compressed formats, the component resolutions do not
    directly reflect the stored size of each pixel, but rather the
    resolution of the two color values stored for each 4x4 pixel
    block.

    
Additions to Chapter 4 of the 1.1 Specification (Per-Fragment Operations
and the Frame Buffer)

    The following is added to the first paragraph of section 4.3.2
    after the sentence beginning "The arguments after x and y: "As in
    the case of TexImage, ICC formats may only be used for reading
    back ICC textures or the error INVALID_ENUM is generated.  For
    more information, see Chapter 6 (State and State Requests).

Additionally, the host ICC format must have the same
    channels as the base internal format of the source ICC texture of
    the error INVALID_ENUM is generated.  During TexSubImage readbacks of ICC
    textures, the "

Additions to Chapter 5 of the 1.1 Specification (Special Functions)

    None

Additions to Chapter 6 of the 1.1 Specification (State and State Requests)

    Added to the end of the paragraph in the introduction which talks
    about the GetTexImage command:  "Additional restrictions apply if
    the format is one of the ICC formats.  The internal format of the
    texture must have a base internal format equal to the format
    parameter or the error INVALID_ENUM is generated.  Similarly to
    the download case, the width and height of the data read back is
    rounded up to the next multiples of 4 such that only complete
    compressed tiles are returned."

Additions to the GLX Specification

    None

Dependencies on EXT_texture3D

    If EXT_texture3D is not supported, all references to
    TexImage3DEXT, TexSubImage3DEXT, CopyTexImage3DEXT, and
    CopyTexSubImage3DEXT are ignored.

Dependencies on SGIS_texture4D

    If SGIS_texture4D is not supported, all references to
    TexImage4DSGIS, TexSubImage4DSGIS, CopyTexImage4DSGIS, and
    CopyTexSubImage4DSGIS are ignored.

Errors

    XXX

New State

    None

New Implementation Dependent State

    None