Footnotes and commentary from the list which have been handled. NOTES ON THINGS TO DO FROM THE DECEMBER ARB MEETING > Determine how histogram and minmax sinking affects defining texture > images. When pixels are sunk, is the texture state updated even though > the texture image is not? Texture state is updated whether or not texture image contents are. FOOTNOTES THAT HAVE BEEN RESOLVED p83 #1 "This is identical to ColorTable language" p83 #2 "Redo like the TexImage2D description" This points towards a significant rewrite of the pixel path section to lift "image specification" out as a separate entity. Then DrawPixels, texturing, color tables, convolution filters, and histograms would all refer to "image specification", which would (a) be much more consistent and (b) much more compact. A great idea, but unlikely to happen in the 1.2 timeframe - I'd be afraid to make such significant changes at this point. ACTION: None. Keep in mind for the future. p85 #3 "Clause is not found for other filter types" If we need to explicitly say that specifying an image replaces the old image, we should do so consistently. But I don't think we need to say so any more than we need to say that specifying any other state replaces the old state (if someone writes an implementation that leaks memory because they don't free unreferenced state, that's their problem, not the spec's, IMO). ACTION: Remove the clause. p88 #4 "Because the internal type is floating point, it's likely that internalformat should be restricted to base internal formats..." It's rather silly to request 4-bit floating point components (which is entirely possible). However, sized internal formats don't have to be obeyed. ACTION: None. p88 #5 "...need a glossary?" Another great idea, but we've lived without one for 7 years or so. ACTION: None. p100 #6 "The interaction with histogram and minmax needs to be thought through carefully - do histogram and minmax take place anyway? How about for scissored pixels?" No resolution yet. ACTION: Histogram and minmax tables are not affected if the raster position is invalid. However, the tables are updated even for clipped or scissored pixels, since those operations occur after pixel transfer operations are applied. p103 #7 "This list is not yet complete" Referring to the table of operations for which 2D convolution applies. ACTION: Added GetTexImage to 1D, 2D, and 2D separable operations. Added CopyTexSubImage3D to 2D and 2D separable operations, because it is intrinsically a two-dimensional operation. Behavior depends on the dimensionality of the source image. p110 #9 "However, we may want to define 32-bit internal component formats, since there's no way to detect if overflow occurs." If we want to do this, it will be far-reaching, since a new sized format would presumably also be allowed for other commands defining/returning images. ACTION: Probably none, no other interest has been expressed. p111 #10 "This entire confusing paragraph could be replaced with a nice table. I also don't care for the ``no semantics defined'' bit - why can't we define clamping of component values to the table range?" I have something like table 6.1 in mind, showing which components are replaced by which components. A minimalist solution to the "no semantics defined" problem is to add two queryable implementation-dependent floating-point values, MINMAX_MAX_VALUE and MINMAX_MIN_VALUE parameters to GetMinMaxParameter(). At worst, MIN would be at most 0, and MAX would be at least 1; I think a compelling argument for a larger required range is obvious, but don't yet have a suggestion for what the range should be. A more complex solution would allow flagging overflow in some fashion, which would also be useful for histogram. Without such a flag, you can only determine that overflow hasn't occurred by restricting the number of pixels sent (for histogram only), or by checking that the computed component range/counts don't exceed the allowed range. ACTION: Instead of introducing MINMAX_{MIN,MAX}_VALUE, observed that the range of a 'floating-point' minmax value should be the same as a floating-point coordinate (2^10). p113 #11 "Need to add a note that convolution may affect the final size of texture images - where?" ACTION: TexImage2D and TexImage1D now mention that the texture width and height may be affected by convolution. p117 #13 "But not depth; MAX_TEXTURE_SIZE only applies to one- and two-dimensional texture images." This is implicit in the language; does it need to be stated explicitly? ACTION: None, unless people have good suggestions. p117 #14 "As a consequence, parameter internalformat of TexImage2D and TexImage1D is of type int, not type enum." This is a "clarification" type of footnote, to explain an otherwise subtle difference. ACTION: I believe the footnote should stay in the spec permanently. p122 #16 "There is no CopyTexImage3D command." Another clarification. ACTION: This footnote should also stay, perhaps explaining that there's no reasonable way to define an entire 3D image from a 2D framebuffer. COMMENTARY THAT HAS BEEN HANDLED Dale Kirkland writes: > Subject: Comments on January Draft of 1.2 OpenGL Spec > > Pg 111. Line 4, Footnote 11. > > Clamping again. If min/max values are not clamped, then the semantics > for converting them to UBYTE, SHORT, etc. when GetMinMax() is called is > undefined. Table 4.7 specifies the conversion from float to the various > types, all of which assume the value f is in the range [0, 1]. I'd > propose that clamping is done before histogram and that the language in > histogram about clamping be removed. > ACTION: None needed; pixel storage modes apply to the query, so it's clamped there (also see discussion of footnote 10, above). ----------------------- Andy Vesper writes: > Subject: Spec draft comments; chapters 1-3 > > 1.1. I'd like a highly visible indicator for all the imaging subset. One > thought is to shade the background of table entries and sections > dealing with the subset. ACTION: Done (mostly). Text dealing with the imaging subset is in gray; state table entries are against a gray background. This will not translate very well to HTML (and is of questionable appearance depending on gamma of your display monitor or the screening of your printer), however. ----------------------- > From: vesper@vesper.eng.pko.dec.com (Andy V) > Subject: Comments on some "Items yet to do for the 1.2 specification" > > > 2.3. Page 39, section 2.11 "Clipping" has a paragraph that starts: > > > > This clipping produces a value, 0 <= t <= 1, for each clipped > > vertex. If the coordinates of a clipped vertex are *P* and the > > original vertices' coordinates are *P1* and *P2* > > > > Are these coordinates in eye space or clip space? Does it depend on > > which clip plane we are discussing -- client-defined clip planes or > > view volume clip planes? > > > > : ACTION: None. As long as P, P1, and P2 are all in the same space, it > : doesn't make any difference, does it? > > After lots of brain exercise, I realized that it doesn't make any > difference. I was confused because I thought that since the projection > transformation can change distances between vertices, that the t > computations would be different in the two spaces. I've now satisfied > myself that the results would be the same. No action taken. > > 3.4. Page 79, Table 3.3 "PixelMap parameters." > > > > PIXEL_MAP_I_TO_I is a floating point table > > > > [... fix to initial value elided] > > > > What resolution can an application expect from 'floating-point' tables? > > >From integer tables? > > : The spec has always been loose about internal sizes. Section 2.1 > : discusses floating point precision. For integer tables, I infer that > : they have at least the same resolution as the corresponding component > : after final color processiong (section 2.13.9). > : > : ACTION: None. > > Note that the sample implementation has PIXEL_MAP_I_TO_I as an integer > table. We'll look at fixing the sample GL; no spec changes needed. > > 3.14. Page 131, section 3.8.5 "Texture Minification"/"Mipmapping". > > I find the combination of text and equations used to describe mipmap > array selection confusing. I propose the following equations, inspired > by the simplicity of equation 3.14, page 127. > > << > For NEAREST_MIPMAP_NEAREST and LINEAR_MIPMAP_NEAREST, the dth mipmap > array is selected, where d is computed as: > > lambda <= c, magnification > > d = TEXTURE_BASE_LEVEL > > lambda > c, minification > > d = TEXTURE_BASE_LEVEL lambda <= 0.5 > > d = CEIL (TEXTURE_BASE_LEVEL + lambda + 0.5) - 1 > lambda > 0.5 AND > TEXTURE_BASE_LEVEL + lambda <= q + 0.5 > > d = q > lambda > 0.5 AND > TEXTURE_BASE_LEVEL + lambda > q + 0.5 > > For NEAREST_MIPMAP_LINEAR and LINEAR_MIPMAP_LINEAR, levels d1 and d2 > mipmap arrays are selected, where d1 and d2 are computed as: > > lambda <= c, magnification > > d1 = d2 = TEXTURE_BASE_LEVEL > > lambda > c, minification > > d1 = d2 = q TEXTURE_BASE_LEVEL + lambda >= q > > d1 = FLOOR (TEXTURE_BASE_LEVEL + lambda + 1) otherwise > d2 = d1 + 1 > > ACTION: Andy's revised equations replaced the previous textual version (thanks!). ********************************************** > From: vesper@vesper.eng.pko.dec.com (Andy V) > Subject: More comments on the OpenGL spec; DRAFT Version 1.2 - Feb 2, 1998 > > Here are some new comments on the OpenGL spec; DRAFT Version 1.2 - Feb > 2, 1998. > > 1. Section 2.13 Colors and Coloring, page 42, Figure 2.8 Processing of > RGBA colors. > > The three color inputs are labeled [0,2^k - 1], [-2^k,2^k - 1] and > [0.0,1.0]. Since floating point values outside the range [0.0,1.0] > are valid and useful, perhaps this should be labeled "float"? Done. > 2. Page 43, Figure 2.9 Processing of color indices. > > Again, perhaps [0.0,2^n - 1] should be "float" because any floating > point number is valid and at least marginally useful. Masking doesn't > take place until clamping or masking (section 2.13.6). Done. > 3. Section 3.8.7 Texture State and Proxy State, page 132, the last > sentence says, "... a boolean flag indicating whether the texture is > resident (see section 3.8.8, and the priority associated with each > set of properties." > > Is the texture resident flag really state? It is not a persistent > attribute of the texture object. Perhaps we want to state that it is > 'transient state'? Nit -- open parenthesis without matching close > parenthesis. I think of it as implementation-dependent state, queryable but not settable by the application. It has been considered state since the days of the texture_object extension spec. Added a statement to this effect. > 4. Page 133, first paragraph says, "... TEXTURE_RESIDENT is false..."; > Isn't this implementation specific? Perhaps a context comes complete > with default textures resident, and when you bind a texture for the > first time it is made resident. Changed the initial value of TEXTURE_RESIDENT (in the state tables) to be defined by the GL. Since there is no way to know that the initial value hasn't changed by the time it's queried, the conformance tests shouldn't (and don't) check for this, so the change should be undetectable. > 5. Page 133, sentence just before section 3.8.8 has an extraneous > period after INVALID_ENUM. "The error INVALID_ENUM. is generated if > this is attempted." Done. > 7. Section 4.3.2 Reading Pixels, page 159, Figure 4.2 Operation of > ReadPixels. > > The top left box says "Convert to [0,1]". Should it say "Convert to > float" like figure 3.7? The results of the conversion will be in > [0.0, 1.0], but the depth buffer is already in the range [0,1] by the > interpretation of the bits in the buffers. Done. > 8. Page 161 Final Conversion. The second paragraph says, "For an RGBA > color, if the type is not FLOAT then each component is clamped to > [0,1]. Then the appropriate conversion from table 4.7 is applied to > the component." This implies that if type IS FLOAT, you don't clamp > but you do convert. I think the proper final conversion is "For an > RGBA color, each component is clamped to [0,1] and then converted > (if the type is not FLOAT) using the appropriate formula from table > 4.7." I don't agree that clamping should occur. It's possible to get back values outside the range [0,1] as a result of pixel transfer operations, and the only way to obtain those values is via a FLOAT return type, since integers can't represent them via the defined conversions (some of our customers depend on this behavior). > 9. Section 4.3.3 Copying Pixels, page 164, Figure 4.3 Operation of > CopyPixels. > > Should the top left box change from "Convert to [0,1]" to "Convert to > float"? (Same as item 7 but for CopyPixels.) Done. > 10. same figure > > The "Clamp to [0,1]" and "Mask to [0, 2^n - 1]" boxes in Figure 3.7 > should be added here. Done. > 11. Section 5.1 Evaluators, page 169, 4th paragraph says, "Analytic > computation, which sometimes yields normals of length zero is one > method which may be used." A comma is needed after "zero". Done. > 12. Section 5.6 Hints, page 182. The initial state should be mentioned > here. Table 6.23 says they are all DONT_CARE. Done. > 13. Appendix D, section D.1 Three-Dimensional Texturing, page 232. The > first sentence needs its first word capitalized. Done. > 14. Section D.6 Texture Coordinate Edge Clamping, page 233, second > paragraph, second sentence says, "When used with a NEAREST or a > LINEAR filter, the color returned ..." This should just start "The > color returned..." since the spec only has NEAREST and LINEAR > filters. Done. ************************************************************ > From: Dan Brokenshire > Subject: OpenGL 1.2 Specification Comments > Date: Tue, 03 Mar 1998 05:20:52 -0600 > > The following comments are for the OpenGL Specification Version 1.2b3 > (February 2, 1998). > > Page 85 Alternate Convolution Filter Specification Commands > > We concur with Intergraph that CopyConvolutionFilter*D should > be removed. I have not seen or heard any good reasons for supporting > these functions. Unless there is specific application need, I (once > again) suggest that these two calls be removed. Settle this at the ARB meeting. > Page 126 - 2nd full paragraph > > The specification only decribes the clamping for NEAREST and > LINEAR filters as if it were different than with other filters. > There is no discussion of the clamping that is performed for > the other filters. Either remove the reference to NEAREST and LINEAR > or include some discussion somewhere in the specfication concerning > CLAMP_TO_EDGE and mipmap filters. Redundant reference to NEAREST and LINEAR removed. Since the mipmap filters are defined in terms of NEAREST and LINEAR after mipmap level selection, the reference is not technically inaccurate, but it is misleading. It was there due to an SGI version of the spec with other types of filtering. > Page 131 - First full paragarph > > The initial value of TEXTURE_BASE_LEVEL and TEXTURE_MAX_LEVEL are > specified. They are also specified at the top of page 133. I think > they should be specified only once. Redundant definition removed. Likewise for redundant definition of TEXTURE_{MIN,MAX}_LOD. > Page 216 - Table 6.24 Implementation Dependent Values > > The 3D texture extension had a query for the MAX_3D_TEXTURE_SIZE. > The 1.2 specification is devoid of this query. I realize that > the texture size query was replaced by the proxy mechanism, but > minimally we need to define a minimum supported 3D texture size. > Otherwise, implementations are free to not support any 3D texture > mapping. Added. Discuss what minimum value this should have at the meeting. > Likewise, there is no query or minimum for the MAX_HISTOGRAM_TABLE Discuss whether we should have this, and if so what minimum value it should have, at the meeting. > Page 217 - Table 6.25 More Implementation Dependent Values > > The MAX_CONVOLUTION_WIDTH and MAX_CONVOLUTION_HEIGHT should have > minimum values. We are not doing application developers any services > without a usable minimums. Discuss what minimum values these should have at the meeting. > Page 218 - Table 6.26 > > x_BITs is not new and should not have a "clover leaf" symbol on it. The state entries are not new, but they have been merged into a single row, and marked as changed for that reason. This goes away once the spec is finalized, in any case.