code.vuplus.com Git - vuplus_xbmc/blob - lib/libsquish/texture_compression_s3tc.txt

   1 Name
   2
   3     EXT_texture_compression_s3tc
   4
   5 Name Strings
   6
   7     GL_EXT_texture_compression_s3tc
   8
   9 Contact
  10
  11     Pat Brown, NVIDIA Corporation (pbrown 'at' nvidia.com)
  12
  13 Status
  14
  15     FINAL
  16
  17 Version
  18
  19     1.1, 16 November 2001 (containing only clarifications relative to
  20                            version 1.0, dated 7 July 2000)
  21
  22 Number
  23
  24     198
  25
  26 Dependencies
  27
  28     OpenGL 1.1 is required.
  29
  30     GL_ARB_texture_compression is required.
  31
  32     This extension is written against the OpenGL 1.2.1 Specification.
  33
  34 Overview
  35
  36     This extension provides additional texture compression functionality
  37     specific to S3's S3TC format (called DXTC in Microsoft's DirectX API),
  38     subject to all the requirements and limitations described by the extension
  39     GL_ARB_texture_compression.
  40
  41     This extension supports DXT1, DXT3, and DXT5 texture compression formats.
  42     For the DXT1 image format, this specification supports an RGB-only mode
  43     and a special RGBA mode with single-bit "transparent" alpha.
  44
  45 IP Status
  46
  47     Contact S3 Incorporated (http://www.s3.com) regarding any intellectual
  48     property issues associated with implementing this extension.
  49
  50     WARNING:  Vendors able to support S3TC texture compression in Direct3D
  51     drivers do not necessarily have the right to use the same functionality in
  52     OpenGL.
  53
  54 Issues
  55
  56     (1) Should DXT2 and DXT4 (premultiplied alpha) formats be supported?
  57
  58         RESOLVED:  No -- insufficient interest.  Supporting DXT2 and DXT4
  59         would require some rework to the TexEnv definition (maybe add a new
  60         base internal format RGBA_PREMULTIPLIED_ALPHA) for these formats.
  61         Note that the EXT_texture_env_combine extension (which extends normal
  62         TexEnv modes) can be used to support textures with premultipled alpha.
  63
  64     (2) Should generic "RGB_S3TC_EXT" and "RGBA_S3TC_EXT" enums be supported
  65         or should we use only the DXT<n> enums?
  66
  67         RESOLVED:  No.  A generic RGBA_S3TC_EXT is problematic because DXT3
  68         and DXT5 are both nominally RGBA (and DXT1 with the 1-bit alpha is
  69         also) yet one format must be chosen up front.
  70
  71     (3) Should TexSubImage support all block-aligned edits or just the minimal
  72         functionality required by the ARB_texture_compression extension?
  73
  74         RESOLVED:  Allow all valid block-aligned edits.
  75
  76     (4) A pre-compressed image with a DXT1 format can be used as either an
  77         RGB_S3TC_DXT1 or an RGBA_S3TC_DXT1 image.  If the image has
  78         transparent texels, how are they treated in each format?
  79
  80         RESOLVED:  The renderer has to make sure that an RGB_S3TC_DXT1 format
  81         is decoded as RGB (where alpha is effectively one for all texels),
  82         while RGBA_S3TC_DXT1 is decoded as RGBA (where alpha is zero for all
  83         texels with "transparent" encodings).  Otherwise, the formats are
  84         identical.
  85
  86     (5) Is the encoding of the RGB components for DXT1 formats correct in this
  87         spec?  MSDN documentation does not specify an RGB color for the
  88         "transparent" encoding.  Is it really black?
  89
  90         RESOLVED:  Yes.  The specification for the DXT1 format initially
  91         required black, but later changed that requirement to a
  92         recommendation.  All vendors involved in the definition of this
  93         specification support black.  In addition, specifying black has a
  94         useful behavior.
  95
  96         When blending multiple texels (GL_LINEAR filtering), mixing opaque and
  97         transparent samples is problematic.  Defining a black color on
  98         transparent texels achieves a sensible result that works like a
  99         texture with premultiplied alpha.  For example, if three opaque white
 100         and one transparent sample is being averaged, the result would be a
 101         75% intensity gray (with an alpha of 75%).  This is the same result on
 102         the color channels as would be obtained using a white color, 75%
 103         alpha, and a SRC_ALPHA blend factor.
 104
 105     (6) Is the encoding of the RGB components for DXT3 and DXT5 formats
 106         correct in this spec?  MSDN documentation suggests that the RGB blocks
 107         for DXT3 and DXT5 are decoded as described by the DXT1 format.
 108
 109         RESOLVED:  Yes -- this appears to be a bug in the MSDN documentation.
 110         The specification for the DXT2-DXT5 formats require decoding using the
 111         opaque block encoding, regardless of the relative values of "color0"
 112         and "color1".
 113
 114 New Procedures and Functions
 115
 116     None.
 117
 118 New Tokens
 119
 120     Accepted by the <internalformat> parameter of TexImage2D, CopyTexImage2D,
 121     and CompressedTexImage2DARB and the <format> parameter of
 122     CompressedTexSubImage2DARB:
 123
 124         COMPRESSED_RGB_S3TC_DXT1_EXT                   0x83F0
 125         COMPRESSED_RGBA_S3TC_DXT1_EXT                  0x83F1
 126         COMPRESSED_RGBA_S3TC_DXT3_EXT                  0x83F2
 127         COMPRESSED_RGBA_S3TC_DXT5_EXT                  0x83F3
 128
 129 Additions to Chapter 2 of the OpenGL 1.2.1 Specification (OpenGL Operation)
 130
 131     None.
 132
 133 Additions to Chapter 3 of the OpenGL 1.2.1 Specification (Rasterization)
 134
 135     Add to Table 3.16.1:  Specific Compressed Internal Formats
 136
 137         Compressed Internal Format         Base Internal Format
 138         ==========================         ====================
 139         COMPRESSED_RGB_S3TC_DXT1_EXT       RGB
 140         COMPRESSED_RGBA_S3TC_DXT1_EXT      RGBA
 141         COMPRESSED_RGBA_S3TC_DXT3_EXT      RGBA
 142         COMPRESSED_RGBA_S3TC_DXT5_EXT      RGBA
 143
 144
 145     Modify Section 3.8.2, Alternate Image Specification
 146
 147     (add to end of TexSubImage discussion, p.123 -- after edit from the
 148     ARB_texture_compression spec)
 149
 150     If the internal format of the texture image being modified is
 151     COMPRESSED_RGB_S3TC_DXT1_EXT, COMPRESSED_RGBA_S3TC_DXT1_EXT,
 152     COMPRESSED_RGBA_S3TC_DXT3_EXT, or COMPRESSED_RGBA_S3TC_DXT5_EXT, the
 153     texture is stored using one of the several S3TC compressed texture image
 154     formats.  Such images are easily edited along 4x4 texel boundaries, so the
 155     limitations on TexSubImage2D or CopyTexSubImage2D parameters are relaxed.
 156     TexSubImage2D and CopyTexSubImage2D will result in an INVALID_OPERATION
 157     error only if one of the following conditions occurs:
 158
 159         * <width> is not a multiple of four or equal to TEXTURE_WIDTH,
 160           unless <xoffset> and <yoffset> are both zero.
 161         * <height> is not a multiple of four or equal to TEXTURE_HEIGHT,
 162           unless <xoffset> and <yoffset> are both zero.
 163         * <xoffset> or <yoffset> is not a multiple of four.
 164
 165     The contents of any 4x4 block of texels of an S3TC compressed texture
 166     image that does not intersect the area being modified are preserved during
 167     valid TexSubImage2D and CopyTexSubImage2D calls.
 168
 169
 170     Add to Section 3.8.2, Alternate Image Specification (adding to the end of
 171     the CompressedTexImage section introduced by the ARB_texture_compression
 172     spec)
 173
 174     If <internalformat> is COMPRESSED_RGB_S3TC_DXT1_EXT,
 175     COMPRESSED_RGBA_S3TC_DXT1_EXT, COMPRESSED_RGBA_S3TC_DXT3_EXT, or
 176     COMPRESSED_RGBA_S3TC_DXT5_EXT, the compressed texture is stored using one
 177     of several S3TC compressed texture image formats.  The S3TC texture
 178     compression algorithm supports only 2D images without borders.
 179     CompressedTexImage1DARB and CompressedTexImage3DARB produce an
 180     INVALID_ENUM error if <internalformat> is an S3TC format.
 181     CompressedTexImage2DARB will produce an INVALID_OPERATION error if
 182     <border> is non-zero.
 183
 184
 185     Add to Section 3.8.2, Alternate Image Specification (adding to the end of
 186     the CompressedTexSubImage section introduced by the
 187     ARB_texture_compression spec)
 188
 189     If the internal format of the texture image being modified is
 190     COMPRESSED_RGB_S3TC_DXT1_EXT, COMPRESSED_RGBA_S3TC_DXT1_EXT,
 191     COMPRESSED_RGBA_S3TC_DXT3_EXT, or COMPRESSED_RGBA_S3TC_DXT5_EXT, the
 192     texture is stored using one of the several S3TC compressed texture image
 193     formats.  Since the S3TC texture compression algorithm supports only 2D
 194     images, CompressedTexSubImage1DARB and CompressedTexSubImage3DARB produce
 195     an INVALID_ENUM error if <format> is an S3TC format.  Since S3TC images
 196     are easily edited along 4x4 texel boundaries, the limitations on
 197     CompressedTexSubImage2D are relaxed.  CompressedTexSubImage2D will result
 198     in an INVALID_OPERATION error only if one of the following conditions
 199     occurs:
 200
 201         * <width> is not a multiple of four or equal to TEXTURE_WIDTH.
 202         * <height> is not a multiple of four or equal to TEXTURE_HEIGHT.
 203         * <xoffset> or <yoffset> is not a multiple of four.
 204
 205     The contents of any 4x4 block of texels of an S3TC compressed texture
 206     image that does not intersect the area being modified are preserved during
 207     valid TexSubImage2D and CopyTexSubImage2D calls.
 208
 209 Additions to Chapter 4 of the OpenGL 1.2.1 Specification (Per-Fragment
 210 Operations and the Frame Buffer)
 211
 212     None.
 213
 214 Additions to Chapter 5 of the OpenGL 1.2.1 Specification (Special Functions)
 215
 216     None.
 217
 218 Additions to Chapter 6 of the OpenGL 1.2.1 Specification (State and
 219 State Requests)
 220
 221     None.
 222
 223 Additions to Appendix A of the OpenGL 1.2.1 Specification (Invariance)
 224
 225     None.
 226
 227 Additions to the AGL/GLX/WGL Specifications
 228
 229     None.
 230
 231 GLX Protocol
 232
 233     None.
 234
 235 Errors
 236
 237     INVALID_ENUM is generated by CompressedTexImage1DARB or
 238     CompressedTexImage3DARB if <internalformat> is
 239     COMPRESSED_RGB_S3TC_DXT1_EXT, COMPRESSED_RGBA_S3TC_DXT1_EXT,
 240     COMPRESSED_RGBA_S3TC_DXT3_EXT, or COMPRESSED_RGBA_S3TC_DXT5_EXT.
 241
 242     INVALID_OPERATION is generated by CompressedTexImage2DARB if
 243     <internalformat> is COMPRESSED_RGB_S3TC_DXT1_EXT,
 244     COMPRESSED_RGBA_S3TC_DXT1_EXT, COMPRESSED_RGBA_S3TC_DXT3_EXT, or
 245     COMPRESSED_RGBA_S3TC_DXT5_EXT and <border> is not equal to zero.
 246
 247     INVALID_ENUM is generated by CompressedTexSubImage1DARB or
 248     CompressedTexSubImage3DARB if <format> is COMPRESSED_RGB_S3TC_DXT1_EXT,
 249     COMPRESSED_RGBA_S3TC_DXT1_EXT, COMPRESSED_RGBA_S3TC_DXT3_EXT, or
 250     COMPRESSED_RGBA_S3TC_DXT5_EXT.
 251
 252     INVALID_OPERATION is generated by TexSubImage2D CopyTexSubImage2D, or
 253     CompressedTexSubImage2D if TEXTURE_INTERNAL_FORMAT is
 254     COMPRESSED_RGB_S3TC_DXT1_EXT, COMPRESSED_RGBA_S3TC_DXT1_EXT,
 255     COMPRESSED_RGBA_S3TC_DXT3_EXT, or COMPRESSED_RGBA_S3TC_DXT5_EXT and any of
 256     the following apply: <width> is not a multiple of four or equal to
 257     TEXTURE_WIDTH; <height> is not a multiple of four or equal to
 258     TEXTURE_HEIGHT; <xoffset> or <yoffset> is not a multiple of four.
 259
 260
 261     The following restrictions from the ARB_texture_compression specification
 262     do not apply to S3TC texture formats, since subimage modification is
 263     straightforward as long as the subimage is properly aligned.
 264
 265     DELETE: INVALID_OPERATION is generated by TexSubImage1D, TexSubImage2D,
 266     DELETE: TexSubImage3D, CopyTexSubImage1D, CopyTexSubImage2D, or
 267     DELETE: CopyTexSubImage3D if the internal format of the texture image is
 268     DELETE: compressed and <xoffset>, <yoffset>, or <zoffset> does not equal
 269     DELETE: -b, where b is value of TEXTURE_BORDER.
 270
 271     DELETE: INVALID_VALUE is generated by CompressedTexSubImage1DARB,
 272     DELETE: CompressedTexSubImage2DARB, or CompressedTexSubImage3DARB if the
 273     DELETE: entire texture image is not being edited:  if <xoffset>,
 274     DELETE: <yoffset>, or <zoffset> is greater than -b, <xoffset> + <width> is
 275     DELETE: less than w+b, <yoffset> + <height> is less than h+b, or <zoffset>
 276     DELETE: + <depth> is less than d+b, where b is the value of
 277     DELETE: TEXTURE_BORDER, w is the value of TEXTURE_WIDTH, h is the value of
 278     DELETE: TEXTURE_HEIGHT, and d is the value of TEXTURE_DEPTH.
 279
 280     See also errors in the GL_ARB_texture_compression specification.
 281
 282 New State
 283
 284     In the "Textures" state table, increment the TEXTURE_INTERNAL_FORMAT
 285     subscript for Z by 4 in the "Type" row.
 286
 287 New Implementation Dependent State
 288
 289     None
 290
 291 Appendix
 292
 293     S3TC Compressed Texture Image Formats
 294
 295     Compressed texture images stored using the S3TC compressed image formats
 296     are represented as a collection of 4x4 texel blocks, where each block
 297     contains 64 or 128 bits of texel data.  The image is encoded as a normal
 298     2D raster image in which each 4x4 block is treated as a single pixel.  If
 299     an S3TC image has a width or height less than four, the data corresponding
 300     to texels outside the image are irrelevant and undefined.
 301
 302     When an S3TC image with a width of <w>, height of <h>, and block size of
 303     <blocksize> (8 or 16 bytes) is decoded, the corresponding image size (in
 304     bytes) is:
 305
 306         ceil(<w>/4) * ceil(<h>/4) * blocksize.
 307
 308     When decoding an S3TC image, the block containing the texel at offset
 309     (<x>, <y>) begins at an offset (in bytes) relative to the base of the
 310     image of:
 311
 312         blocksize * (ceil(<w>/4) * floor(<y>/4) + floor(<x>/4)).
 313
 314     The data corresponding to a specific texel (<x>, <y>) are extracted from a
 315     4x4 texel block using a relative (x,y) value of
 316
 317         (<x> modulo 4, <y> modulo 4).
 318
 319     There are four distinct S3TC image formats:
 320
 321     COMPRESSED_RGB_S3TC_DXT1_EXT:  Each 4x4 block of texels consists of 64
 322     bits of RGB image data.
 323
 324     Each RGB image data block is encoded as a sequence of 8 bytes, called (in
 325     order of increasing address):
 326
 327             c0_lo, c0_hi, c1_lo, c1_hi, bits_0, bits_1, bits_2, bits_3
 328
 329         The 8 bytes of the block are decoded into three quantities:
 330
 331             color0 = c0_lo + c0_hi * 256
 332             color1 = c1_lo + c1_hi * 256
 333             bits   = bits_0 + 256 * (bits_1 + 256 * (bits_2 + 256 * bits_3))
 334
 335         color0 and color1 are 16-bit unsigned integers that are unpacked to
 336         RGB colors RGB0 and RGB1 as though they were 16-bit packed pixels with
 337         a <format> of RGB and a type of UNSIGNED_SHORT_5_6_5.
 338
 339         bits is a 32-bit unsigned integer, from which a two-bit control code
 340         is extracted for a texel at location (x,y) in the block using:
 341
 342             code(x,y) = bits[2*(4*y+x)+1..2*(4*y+x)+0]
 343
 344         where bit 31 is the most significant and bit 0 is the least
 345         significant bit.
 346
 347         The RGB color for a texel at location (x,y) in the block is given by:
 348
 349             RGB0,              if color0 > color1 and code(x,y) == 0
 350             RGB1,              if color0 > color1 and code(x,y) == 1
 351             (2*RGB0+RGB1)/3,   if color0 > color1 and code(x,y) == 2
 352             (RGB0+2*RGB1)/3,   if color0 > color1 and code(x,y) == 3
 353
 354             RGB0,              if color0 <= color1 and code(x,y) == 0
 355             RGB1,              if color0 <= color1 and code(x,y) == 1
 356             (RGB0+RGB1)/2,     if color0 <= color1 and code(x,y) == 2
 357             BLACK,             if color0 <= color1 and code(x,y) == 3
 358
 359         Arithmetic operations are done per component, and BLACK refers to an
 360         RGB color where red, green, and blue are all zero.
 361
 362     Since this image has an RGB format, there is no alpha component and the
 363     image is considered fully opaque.
 364
 365
 366     COMPRESSED_RGBA_S3TC_DXT1_EXT:  Each 4x4 block of texels consists of 64
 367     bits of RGB image data and minimal alpha information.  The RGB components
 368     of a texel are extracted in the same way as COMPRESSED_RGB_S3TC_DXT1_EXT.
 369
 370         The alpha component for a texel at location (x,y) in the block is
 371         given by:
 372
 373             0.0,               if color0 <= color1 and code(x,y) == 3
 374             1.0,               otherwise
 375
 376         IMPORTANT:  When encoding an RGBA image into a format using 1-bit
 377         alpha, any texels with an alpha component less than 0.5 end up with an
 378         alpha of 0.0 and any texels with an alpha component greater than or
 379         equal to 0.5 end up with an alpha of 1.0.  When encoding an RGBA image
 380         into the COMPRESSED_RGBA_S3TC_DXT1_EXT format, the resulting red,
 381         green, and blue components of any texels with a final alpha of 0.0
 382         will automatically be zero (black).  If this behavior is not desired
 383         by an application, it should not use COMPRESSED_RGBA_S3TC_DXT1_EXT.
 384         This format will never be used when a generic compressed internal
 385         format (Table 3.16.2) is specified, although the nearly identical
 386         format COMPRESSED_RGB_S3TC_DXT1_EXT (above) may be.
 387
 388
 389     COMPRESSED_RGBA_S3TC_DXT3_EXT:  Each 4x4 block of texels consists of 64
 390     bits of uncompressed alpha image data followed by 64 bits of RGB image
 391     data.
 392
 393     Each RGB image data block is encoded according to the
 394     COMPRESSED_RGB_S3TC_DXT1_EXT format, with the exception that the two code
 395     bits always use the non-transparent encodings.  In other words, they are
 396     treated as though color0 > color1, regardless of the actual values of
 397     color0 and color1.
 398
 399     Each alpha image data block is encoded as a sequence of 8 bytes, called
 400     (in order of increasing address):
 401
 402             a0, a1, a2, a3, a4, a5, a6, a7
 403
 404         The 8 bytes of the block are decoded into one 64-bit integer:
 405
 406             alpha = a0 + 256 * (a1 + 256 * (a2 + 256 * (a3 + 256 * (a4 +
 407                          256 * (a5 + 256 * (a6 + 256 * a7))))))
 408
 409         alpha is a 64-bit unsigned integer, from which a four-bit alpha value
 410         is extracted for a texel at location (x,y) in the block using:
 411
 412             alpha(x,y) = bits[4*(4*y+x)+3..4*(4*y+x)+0]
 413
 414         where bit 63 is the most significant and bit 0 is the least
 415         significant bit.
 416
 417         The alpha component for a texel at location (x,y) in the block is
 418         given by alpha(x,y) / 15.
 419
 420
 421     COMPRESSED_RGBA_S3TC_DXT5_EXT:  Each 4x4 block of texels consists of 64
 422     bits of compressed alpha image data followed by 64 bits of RGB image data.
 423
 424     Each RGB image data block is encoded according to the
 425     COMPRESSED_RGB_S3TC_DXT1_EXT format, with the exception that the two code
 426     bits always use the non-transparent encodings.  In other words, they are
 427     treated as though color0 > color1, regardless of the actual values of
 428     color0 and color1.
 429
 430     Each alpha image data block is encoded as a sequence of 8 bytes, called
 431     (in order of increasing address):
 432
 433         alpha0, alpha1, bits_0, bits_1, bits_2, bits_3, bits_4, bits_5
 434
 435         The alpha0 and alpha1 are 8-bit unsigned bytes converted to alpha
 436         components by multiplying by 1/255.
 437
 438         The 6 "bits" bytes of the block are decoded into one 48-bit integer:
 439
 440           bits = bits_0 + 256 * (bits_1 + 256 * (bits_2 + 256 * (bits_3 +
 441                           256 * (bits_4 + 256 * bits_5))))
 442
 443         bits is a 48-bit unsigned integer, from which a three-bit control code
 444         is extracted for a texel at location (x,y) in the block using:
 445
 446             code(x,y) = bits[3*(4*y+x)+1..3*(4*y+x)+0]
 447
 448         where bit 47 is the most significant and bit 0 is the least
 449         significant bit.
 450
 451         The alpha component for a texel at location (x,y) in the block is
 452         given by:
 453
 454               alpha0,                   code(x,y) == 0
 455               alpha1,                   code(x,y) == 1
 456
 457               (6*alpha0 + 1*alpha1)/7,  alpha0 > alpha1 and code(x,y) == 2
 458               (5*alpha0 + 2*alpha1)/7,  alpha0 > alpha1 and code(x,y) == 3
 459               (4*alpha0 + 3*alpha1)/7,  alpha0 > alpha1 and code(x,y) == 4
 460               (3*alpha0 + 4*alpha1)/7,  alpha0 > alpha1 and code(x,y) == 5
 461               (2*alpha0 + 5*alpha1)/7,  alpha0 > alpha1 and code(x,y) == 6
 462               (1*alpha0 + 6*alpha1)/7,  alpha0 > alpha1 and code(x,y) == 7
 463
 464               (4*alpha0 + 1*alpha1)/5,  alpha0 <= alpha1 and code(x,y) == 2
 465               (3*alpha0 + 2*alpha1)/5,  alpha0 <= alpha1 and code(x,y) == 3
 466               (2*alpha0 + 3*alpha1)/5,  alpha0 <= alpha1 and code(x,y) == 4
 467               (1*alpha0 + 4*alpha1)/5,  alpha0 <= alpha1 and code(x,y) == 5
 468               0.0,                      alpha0 <= alpha1 and code(x,y) == 6
 469               1.0,                      alpha0 <= alpha1 and code(x,y) == 7
 470
 471
 472 Revision History
 473
 474     1.1,  11/16/01 pbrown:    Updated contact info, clarified where texels
 475                               fall within a single block.
 476
 477     1.0,  07/07/00 prbrown1:  Published final version agreed to by working
 478                               group members.
 479
 480     0.9,  06/24/00 prbrown1:  Documented that block-aligned TexSubImage calls
 481                               do not modify existing texels outside the
 482                               modified blocks.  Added caveat to allow for a
 483                               (0,0)-anchored TexSubImage operation of
 484                               arbitrary size.
 485
 486     0.7,  04/11/00 prbrown1:  Added issues on DXT1, DXT3, and DXT5 encodings
 487                               where the MSDN documentation doesn't match what
 488                               is really done.  Added enum values from the
 489                               extension registry.
 490
 491     0.4,  03/28/00 prbrown1:  Updated to reflect final version of the
 492                               ARB_texture_compression extension.  Allowed
 493                               block-aligned TexSubImage calls.
 494
 495     0.3,  03/07/00 prbrown1:  Resolved issues pertaining to the format of RGB
 496                               blocks in the DXT3 and DXT5 formats (they don't
 497                               ever use the "transparent" encoding).  Fixed
 498                               decoding of DXT1 blocks.  Pointed out issue of
 499                               "transparent" texels in DXT1 encodings having
 500                               different behaviors for RGB and RGBA internal
 501                               formats.
 502
 503     0.2,  02/23/00 prbrown1:  Minor revisions; added several issues.
 504
 505     0.11, 02/17/00 prbrown1:  Slight modification to error semantics
 506                               (INVALID_ENUM instead of INVALID_OPERATION).
 507
 508     0.1,  02/15/00 prbrown1:  Initial revision.