XXX - Not complete. Name SGIX_image_compression Name Strings GL_SGIX_image_compression Version $Date: 1997/06/05 16:11:49 $ $Revision: 1.5 $ Number ??? Dependencies None. Overview This extension defines new pixel storage modes which are used in the conversion of image data to and from compressed formats on the client side. These new compression and decompression operations take place during the pixel packing and unpacking stages of the OpenGL pipeline, respectively, and obey the same semantics as other packing and unpacking modes. This extension defines a framework in which further extensions can provide support for specific compressed formats, and also provides additional infrastructure which is common to various compression techniques, without defining any specific compression formats. Other extensions will define compression formats which make use of this framework. A new pixel unpacking mode and a new pixel packing mode are defined which specify the compressed format of pixel data on the client side. The only legal value this extension defines for these storage modes is NONE; further compression extensions will define additional legal values. Many compression techniques utilize various component subsamplings, so it is necessary to provide a mechanism to specify the up- and down-sampling of components as pixel data is decompressed from- and compressed to the client. This extension defines a new pixel storage mode to specify these sampling patterns, and four legal values. When pixel data is decompressed from the client and an unpacking upsampling mode other than SAMPLE_444_SGIX is specified, the upsampling is performed via simple component replication. This preserves all information in the incoming image data, so that if an application requires other types of filtering, they may be performed after decompression. Similarly, when pixel data is compressed to the client and a packing downsampling mode other than SAMPLE_444_SGIX is specified, the downsampling is performed via simple component decimation. If an application requires other types of filtering, they must be performed before compression. Some compression formats specify a color space in which the pixels are expressed before compression and after decompression. To make support of these formats more transparent, this extension adds a conversion between the natural color space of the compression format and RGB. This conversion can be enabled separately for packing and for unpacking of pixel data. When it is enabled for unpacking, the pixel data will be converted to RGB after decompression. When it is enabled for packing, the pixel data will be assumed to be represented as RGB, and converted as necessary before compression. The client may wish to disable these automatic conversion in order to apply filtering before the color space conversion in the case of decompression, or after the color space conversion in the case of compression. When the conversions are disabled, the client is responsible for performing the appropriate color space conversions. The alternate color spaces must be defined by the additional compression format extensions. If a new format extension does not specify a preferred color space, this color space conversion has no effect. Issues - Should this be split into multiple extensions? - How should bitrate/quality be controlled for vbr techniques? - Instead of requiring each compression format extension to specify its own color space, this could be specified by the client using the parameter. This would require the creation of additional formats, but would also have the advantage of more accurately reflecting the format of pixel data, i.e., calling the format of DVC compressed data YCrCb rather than RGB. - Should some additional support for up- and down-sampling methods other than replication and decimation be provided? - Should we define an error for a bogus compressed frame? Something like COMPRESSION_DATA_ERROR? - We define all compression standards as operating on RGBA floating-point images. Is this the correct decision? - We ignore color-index images. Is this the correct decision? - The current scheme for subrectangle modes doesn't permit the old trick of drawing fields by setting ROW_LENGTH to twice the actual width of the image. Probably the easiest way to fix this would be to add some new pixel storage parameter (FIELD_EXTRACT or something) which would be treated as though it were part of ROW_LENGTH in the non-compressed unpack case. The non-compressed unpack case is a little harder -- it can be done by setting ROW_LEGNTH to one half the width, but bytes past the end of the last scan line are written. - What about three- and four-dimensional images? - What about three- and four-dimensional subrectangle modes? New Procedures and Functions None. New Tokens Accepted by the parameter of PixelStoref, PixelStorei, GetBooleanv, GetIntegerv, GetFloatv and GetDoublev: PACK_COMPRESSION_TYPE_SGIX UNPACK_COMPRESSION_TYPE_SGIX UNPACK_COMPRESSED_SIZE_SGIX PACK_MAX_COMPRESSED_SIZE_SGIX PACK_SAMPLE_SGIX UNPACK_SAMPLE_SGIX Accepted by the parameter of GetBooleanv, GetIntegerv, GetFloatv and GetDoublev: PACK_COMPRESSED_SIZE_SGIX Accepted by the parameter of PixelStoref and PixelStorei when the parameter is PACK_SAMPLE_SGIX or UNPACK_SAMPLE_SGIX: SAMPLE_444_SGIX SAMPLE_422_SGIX SAMPLE_411_SGIX SAMPLE_420_SGIX Accepted by the parameter of PixelStoref and PixelStorei with a parameter of TRUE or FALSE and by the parameter of GetBooleanv, GetIntegerv, GetFloatv and GetDoublev: PACK_FROM_RGB_SGIX UNPACK_TO_RGB_SGIX Additions to Chapter 2 of the 1.0 Specification (OpenGL Operation) None. Additions to Chapter 3 of the 1.0 Specification (Rasterization) 3.6.1 Pixel Storage Modes The following is added to Table 3.1: Parameter Name Type Initial Value Valid Range -------------- ---- ------------- ----------- UNPACK_COMPRESSION_TYPE_SGIX integer NONE NONE UNPACK_COMPRESSED_SIZE_SGIX integer 0 [0,inf) UNPACK_SAMPLE_SGIX integer SAMPLE_444_SGIX SAMPLE_444_SGIX, SAMPLE_422_SGIX, SAMPLE_411_SGIX, SAMPLE_420_SGIX UNPACK_TO_RGB_SGIX boolean TRUE TRUE/FALSE 3.6.3 Rasterization of Pixel Rectangles The following is added to the introduction to section 3.6.3: "Unpacking" refers to the reading of pixels from host memory. Pixels are unpacked from host memory as either compressed or uncompressed images. If PACK_COMPRESSION_TYPE_SGIX is set to NONE, the images are stored as uncompressed data and are unpacked from host memory as described below. If PACK_COMPRESSION_TYPE_SGIX is set to a value other than NONE, the images are compressed and are unpacked from host memory as described in "Unpacking of Compressed Images". The title of the "Unpacking" subsection is changed to "Unpacking of Uncompressed Images." All references to this subsection are changed as well. A new subsection, "Unpacking of Compressed Images," is added between "Unpacking of Uncompressed Images" and the "Conversion to Floating-Point." The contents of the section are as follows: In this section, we describe the unpacking of compressed images. The first part describes how images are taken from host memory as a byte stream. Next, a description GL's upsampling algorithms is provided since they are used by several compressed formats. After the upsampling description, paragraphs added by other extensions describe the conversion applied to the byte stream for a given UNPACK_COMPRESSION_TYPE_SGIX. After these descriptions, we describe the application of subrectangle pixel storage modes. GL supports four types of upsampling: SAMPLE_444_SGIX, SAMPLE_422_SGIX, SAMPLE_411_SGIX, and SAMPLE_420_SGIX. The type of upsampling performed is determined by the setting of the UNPACK_SAMPLE_SGIX pixel storage parameter. XXX say how the upsampling is performed for each of the things. Compressed images are taken from memory as an uninterrupted sequence of bytes beginning at whose length is given by UNPACK_COMPRESSED_SIZE_SGIX. The byte stream is passed to the GL and interpreted as determined by the compression type given by UNPACK_COMPRESSION_TYPE_SGIX. The dimensions of the image represented by the byte stream are determined as follows. The width of the image is equal to the value of UNPACK_ROW_LENGTH if this value is positive, or to otherwise. The height of the image is equal to the value of IMAGE_HEIGHT_EXT if this value is positive, or to otherwise. The width and height refer to the the size of the image after upsampling (see below). The pixel storage parameters UNPACK_SWAP_BYTES, UNPACK_LSB_FIRST, and UNPACK_ALIGNMENT are ignored for compressed images. Subrectangle storage modes (UNPACK_SKIP_ROWS, UNPACK_SKIP_PIXELS) are not applied as the image is extracted from memory, but instead are applied after the image has been decompressed. This operation is described in detail at the end of this section. Once the byte stream has been taken from host memory, it is decompressed as determined by the setting of UNPACK_COMPRESSION_TYPE_SGIX. The operations are described in detail below. The output of the decompression algorithm is a width by height image. A subrectangle of the image may be extracted as determined by the pixel storage parameters UNPACK_SKIP_PIXELS, UNPACK_SKIP_ROWS and by the and arguments to the original entry point (see figure 3.8. The result of application of the subrect algorithm is a by image. To compute the subrectangle image, we consider the output of the decompression algorithm as a two-dimensional array of pixels Pin[0...(width-1)][0...(height-1)]. The first index selects the column of the image, the second selects the row. We consider the output of the subrectangle algorithm as a two-dimensional array of pixels Pout[0...(-1)][0...(-1)]. Each pixel the output image is defined by: Pout[i][j] = Pin[UNPACK_SKIP_PIXELS + i][UNPACK_SKIP_ROWS + j] In this equation, we define the "=" operation to set each channel of the output pixel equal to the equivalent channel of the input pixel. If any of the output pixels are generated from pixels outside of the input image, the values of the components of these pixels are undefined. Additions to Chapter 4 of the 1.0 Specification (Per-Fragment Operations and the Frame Buffer) 4.3.2 Reading Pixels The following entries are added to Table 4.5: Parameter Name Type Initial Value Valid Range -------------- ---- ------------- ----------- PACK_COMPRESSION_TYPE_SGIX integer NONE NONE PACK_MAX_COMPRESSED_SIZE_SGIX integer 0 [0,inf) PACK_SAMPLE_SGIX integer SAMPLE_444_SGIX SAMPLE_444_SGIX, SAMPLE_422_SGIX, SAMPLE_411_SGIX, SAMPLE_420_SGIX PACK_FROM_RGB_SGIX boolean TRUE TRUE/FALSE The following needs to be added to the end of the "Final Conversion" subsection: If image compression is on (PACK_COMPRESSION_TYPE_SGIX is set to other than NONE), no conversion is applied. The subsection titled "Placement in Client Memory" is renamed "Packing of Uncompressed Images." The following is added to the start of the subsection: If image compression is not on (PACK_COMPRESSION_TYPE_SGIX is set to NONE), the pixels of the image are transferred to host memory as described in this section. If compression is on, the pixels are transferred as described in "Packing of Compressed Images." A new subsection, "Packing of Compressed Images," is added after the subsection "Packing of Uncompressed Images." The contents of the subsection are as follows: If image compression is on (PACK_COMPRESSION_TYPE_SGIX is set to something other than NONE), images are placed in memory as described in this section. The floating-point image from the final conversion step is used as the input to the compression step. The algorithm used for the compression step is determined by the value of PACK_COMPRESSION_TYPE_SGIX. Algorithms are described in separate extensions. The size of the image returned to the host is by . The pixel pack parameters PACK_SWAP_BYTES, PACK_LSB_FIRST, PACK_ROW_LENGTH, PACK_SKIP_ROWS, PACK_SKIP_PIXELS, and PACK_ALIGNMENT are not considered when reading back compressed images. The output of the compression step is a byte stream. The compression algorithm sets the value of PACK_COMPRESSED_SIZE_SGIX to the length of the byte stream. The bytes are placed in an uninterrupted stream starting at the location in host memory. If the value of PACK_MAX_COMPRESSED_SIZE_SGIX is greater than zero and the value of PACK_COMPRESSED_SIZE_SGIX is greater than the value of PACK_MAX_COMPRESSED_SIZE_SGIX, the error INVALID_OPERATION is generated. If this occurs, the contents of the first PACK_MAX_COMPRESSED_SIZE_SGIX bytes after the pointer are undefined, but bytes outside this range are guaranteed to be left unchanged. Additions to Chapter 5 of the 1.0 Specification (Special Functions) None. Additions to Chapter 6 of the 1.0 Specification (State and State Requests) XXX Additions to the GLX Specification Errors XXX INVALID_OPERATION is generated if the compressed data requested by a ReadPixels or GetTexImage will occupy more than PACK_MAX_COMPRESSED_SIZE bytes. New State Get Value Get Command Type Initial Value Attribute --------- ----------- ---- ------------- --------- UNPACK_COMPRESSION_TYPE GetIntegerv Z1* NONE client UNPACK_COMPRESSED_SIZE GetIntegerv Z+ 0 client UNPACK_SAMPLE_SGIX GetIntegerv Z4 SAMPLE_444_SGIX client UNPACK_TO_RGB_SGIX GetBooleanv B TRUE client PACK_COMPRESSION_TYPE GetIntegerv Z1 NONE client PACK_COMPRESSED_SIZE GetIntegerv Z+ 0 client PACK_MAX_COMPRESSED_SIZE GetIntegerv Z+ 0 client PACK_SAMPLE_SGIX GetIntegerv Z4 SAMPLE_444_SGIX client PACK_FROM_RGB_SGIX GetBooleanv B TRUE client New Implementation Dependent State None.