[Gzz-commits] manuscripts/AniFont anifont.tex

[Tuomas J. Lukka]

CVSROOT:        /cvsroot/gzz
Module name:    manuscripts
Branch:         
Changes by:     Tuomas J. Lukka <address@hidden>        03/10/14 09:01:27

Modified files:
        AniFont        : anifont.tex 

Log message:
        Arch sync

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/manuscripts/AniFont/anifont.tex.diff?tr1=1.8&tr2=1.9&r1=text&r2=text

Patches:
Index: manuscripts/AniFont/anifont.tex
diff -u manuscripts/AniFont/anifont.tex:1.8 manuscripts/AniFont/anifont.tex:1.9
--- manuscripts/AniFont/anifont.tex:1.8 Fri Oct 10 10:05:37 2003
+++ manuscripts/AniFont/anifont.tex     Tue Oct 14 09:01:26 2003
@@ -9,7 +9,23 @@
 \maketitle
 
 \begin{abstract}
-    We show...
+We demonstrate a counterintuitive hardware-accelerated
+rendering trick:
+when rendering an isotropically textured 2 1/2D scene,
+stretching an image when putting it into a texture
+and squishing it with texture coordinates when rendering yields 
+a slightly but significantly better 
+image quality than simple trilinear filtering when hardware
+anisotropic filtering is enabled.
+We show a simple way to understand why this trick works, and discuss
+various generalizations. We show examples of text rendered both ways.
+
+As background for the trick, we discuss harware anisotropic 
+texture filtering and show
+how to probe the filters to understand their function, paying 
+attention to what assumptions have to be made for such probing to work.
+
+
 \end{abstract}
 
 \section{Introduction}
@@ -28,6 +44,10 @@
 - basic anisotropic solution: more samples from the mipmaps than the 8 used for
   trilinear - better approximation of EWA. Modern graphics cards support up to 
XXX samples
 
+- Unextended OpenGL aniso: article on using lod bias etc to get it
+
+- supersampling: FSAA / as above; however, most cards focus on multisampling, 
not supersampling - 
+  no help for textures
 
 - Graphics companies unfortunately do not provide ...
 
@@ -41,93 +61,6 @@
 
 The rest of the article is organized as follows.
 
-\section{Probing hardware anisotropic filters}
-\label{secprobing}
-
-In this Section, we 
-
-This seems to be a well-known technique that has not so far been published
-anywhere
-
-Digit-life XXX NVIDIA, ATI patterns
-
-- for careful work, you'll want to know what your driver is doing
-
-\begin{figure*}
-a) \includegraphics[width=5cm]{probe.2}
-b) \includegraphics[width=10cm]{probe.1}
-c)
-\caption{
-\label{figanisoprobe}
-a) Example probe textures for the three smallest mipmap levels.
-Each texture has a single white texel at a single mipmap level, the rest of 
the texels
-and mipmap levels being gray.
-b) The pixel-sized quads using textures such as the ones in a) to give 
-the contributions of each texel to a particular quad. All quads are rendered
-with the exactly same texture coordinates and vertex coordinates relative 
-to the pixel.
-c) An example image produced by such quads: how the XXX card 
-samples the mipmap levels in XXX aniso XXX
-}
-\end{figure*}
-
-- difficulty in probing hardware: each free variable grows number of probes to 
make
-  exponentially - have to make as strict assumptions as possible
-
-- ASSUMPTIONS: 
-  driver not detecting software and applying different rules, driver
-  not changing algorithm for screenshot images / moving images, 
-  driver not looking at texture images and deciding filtering 
-  algorithms based on that (image-sensitive filters). 
-  (can use linear algebra to do this then).
-  Filters are linear (nonlinearities in the filters - to our knowledge none 
yet; gamma correction?).
-
-- SEMI-ASSUMPTIONS (trivial to adjust algorithm): all texture units produce
-  the same results (in some drivers, this is not the case - 3dcenter about nv 
51.XX series
-  DirectX),
-  Driver isn't using a different set of samples for large and small triangles, 
-  e.g. NV patent describing using lower mipmap level!
-  pixel translation invariance, in screen space.
-
-- define separate texture $T_{(k),x,y}$ for each texel of each
-  mipmap level, with exactly one light
-  texel at the point $(x,y)$ of that mipmap level, all other texels and mipmap 
levels middle gray
-  (we define level $(n)$ to be the 1x1 texture, ${n-1}$ to be the 2x2 texture 
etc.
-  Non-square mipmap hierarchies are a simple generalization)
-    
-    - gray so we see also if there are negative weights in the filter!
-
-- select the texture coordinates for a single-pixel quad for which you want
-  to see contributions.
-  In reality, only a triangle gets used so these should be linearly obtained
-  from three coordinates but it's still easier for a human to understand these
-  as quads... 
-
-- For each mipmap level texel, render a one-pixel quad,
-  with the same texture coordinates and 
-
-- Resulting image gives contribution from each texel on a mipmap level
-  to the final image, PROVIDED ASSUMPTIONS HOLD.
-
-- the single-texture quads (or values read from screen) can then be used
-  in other visualizations
-
-- utility in our free software OpenGL libvob system
-
-
-
-A similar technique appears to be used more commonly used for probing hardware
-antialiasing patterns, (XXX should we?). 
-
-- assumptions about the contents of the mipmap levels
-
-    - aniso filter might compute trilinear samples using only one level, etc.
-    
-    - for analysis, the contribution of one texel could be represented
-      as the contribution of four texels on a higher mimap level as per
-      the assumption of generating the mipmap levels in the usual way
-
-
 \section{Surprise: stretch-squish can yield better images in orthogonal 
transformations}
 
 - case we consider: sharp edges, orthogonal (or nearly so) transformations, 
e.g. text
@@ -196,11 +129,14 @@
   the result significantly
 
 
+
 \section{Conclusion}
 
 - described how hardware implementations of anisotropic filtering can be probed
   for better understanding
 
+- NV's fragment program TXD really useful
+
 - showed how, when orthogonal transformations, anisotropic filtering in the 
hardware
   can still be useful - a trick we haven't seen used elsewhere
 
@@ -222,5 +158,95 @@
 
 
 \section{Acknowledgments}
+
+\appendix
+\section*{Appendix}
+
+\section{Probing hardware anisotropic filters}
+\label{secprobing}
+
+In this Section, we 
+
+This seems to be a well-known technique that has not so far been published
+anywhere
+
+Digit-life XXX NVIDIA, ATI patterns
+
+- for careful work, you'll want to know what your driver is doing
+
+\begin{figure*}
+a) \includegraphics[width=5cm]{probe.2}
+b) \includegraphics[width=10cm]{probe.1}
+c)
+\caption{
+\label{figanisoprobe}
+a) Example probe textures for the three smallest mipmap levels.
+Each texture has a single white texel at a single mipmap level, the rest of 
the texels
+and mipmap levels being gray.
+b) The pixel-sized quads using textures such as the ones in a) to give 
+the contributions of each texel to a particular quad. All quads are rendered
+with the exactly same texture coordinates and vertex coordinates relative 
+to the pixel.
+c) An example image produced by such quads: how the XXX card 
+samples the mipmap levels in XXX aniso XXX
+}
+\end{figure*}
+
+- difficulty in probing hardware: each free variable grows number of probes to 
make
+  exponentially - have to make as strict assumptions as possible
+
+- ASSUMPTIONS: 
+  driver not detecting software and applying different rules, driver
+  not changing algorithm for screenshot images / moving images, 
+  driver not looking at texture images and deciding filtering 
+  algorithms based on that (image-sensitive filters). 
+  (can use linear algebra to do this then).
+  Filters are linear (nonlinearities in the filters - to our knowledge none 
yet; gamma correction?).
+
+- SEMI-ASSUMPTIONS (trivial to adjust algorithm): all texture units produce
+  the same results (in some drivers, this is not the case - 3dcenter about nv 
51.XX series
+  DirectX),
+  Driver isn't using a different set of samples for large and small triangles, 
+  e.g. NV patent describing using lower mipmap level!
+  pixel translation invariance, in screen space.
+
+- define separate texture $T_{(k),x,y}$ for each texel of each
+  mipmap level, with exactly one light
+  texel at the point $(x,y)$ of that mipmap level, all other texels and mipmap 
levels middle gray
+  (we define level $(n)$ to be the 1x1 texture, ${n-1}$ to be the 2x2 texture 
etc.
+  Non-square mipmap hierarchies are a simple generalization)
+    
+    - gray so we see also if there are negative weights in the filter!
+
+- select the texture coordinates for a single-pixel quad for which you want
+  to see contributions.
+  In reality, only a triangle gets used so these should be linearly obtained
+  from three coordinates but it's still easier for a human to understand these
+  as quads... 
+
+- For each mipmap level texel, render a one-pixel quad,
+  with the same texture coordinates and 
+
+- Resulting image gives contribution from each texel on a mipmap level
+  to the final image, PROVIDED ASSUMPTIONS HOLD.
+
+- the single-texture quads (or values read from screen) can then be used
+  in other visualizations
+
+- utility in our free software OpenGL libvob system
+
+
+
+A similar technique appears to be used more commonly used for probing hardware
+antialiasing patterns, (XXX should we?). 
+
+- assumptions about the contents of the mipmap levels
+
+    - aniso filter might compute trilinear samples using only one level, etc.
+    
+    - for analysis, the contribution of one texel could be represented
+      as the contribution of four texels on a higher mimap level as per
+      the assumption of generating the mipmap levels in the usual way
+
 
 \end{document}