/[gzz]/manuscripts/AniFont/anifont.tex
ViewVC logotype

Diff of /manuscripts/AniFont/anifont.tex

Parent Directory Parent Directory | Revision Log Revision Log | View Patch Patch

revision 1.7 by jvk, Thu Oct 2 13:53:27 2003 UTC revision 1.8 by tjl, Fri Oct 10 14:05:37 2003 UTC
# Line 3  Line 3 
3  \usepackage{beton}  \usepackage{beton}
4  \begin{document}  \begin{document}
5    
6  \title{Trick: using harware anisotropic filters in orthogonal contexts to improve quality}  \title{Harware anisotropic filters: Probing the Implementations and Why You Should Make 2D Isotropic Situations Anisotropic}
7    
8    \author{Tuomas J. Lukka and Janne Kujala}
9  \maketitle  \maketitle
10    
11  \begin{abstract}  \begin{abstract}
# Line 15  Line 16 
16    
17  Recently, ...  Recently, ...
18    
19  - Trilinear filtering was designed to avoid temporal and spatial aliasing  - off-line rendering: EWA XXXREF
20    
21    - Trilinear/bilinear (mipmap) filtering was designed to avoid temporal and spatial aliasing XXXREF
22    
23  - can blur sharp edges (text) too much  - can blur sharp edges (text) too much
24    
25    - for 3D rendering, trilinear blurs when seen obliquely, \emph{anisotropically}
26      (squished more in one direction than in another).
27    
28    - basic anisotropic solution: more samples from the mipmaps than the 8 used for
29      trilinear - better approximation of EWA. Modern graphics cards support up to XXX samples
30    
31    
32    - Graphics companies unfortunately do not provide ...
33    
34    
35    - In this article, we argue that isotropic situations should be explicitly avoided
36      in 2D orthogonal rendering - better quality with aniso
37    
38  - For text, setting of the problem: orthogonal transformations are most important,  - For text, setting of the problem: orthogonal transformations are most important,
39  TrueType shows maybe not the right model but ...    TrueType shows maybe not the right model but ...
40    
41    
42    The rest of the article is organized as follows.
43    
44  \section{Hardware anisotropic filters}  \section{Probing hardware anisotropic filters}
45    \label{secprobing}
46    
47    In this Section, we
48    
49  This seems to be a well-known technique that has not so far been published  This seems to be a well-known technique that has not so far been published
50  anywhere  anywhere
51    
 used more commonly in showing FSAA patterns  
   
52  Digit-life XXX NVIDIA, ATI patterns  Digit-life XXX NVIDIA, ATI patterns
53    
54  Graphics companies unfortunately do not provide ...  - for careful work, you'll want to know what your driver is doing
55    
56  \begin{figure*}  \begin{figure*}
57  a) \includegraphics[width=5cm]{probe.2}  a) \includegraphics[width=5cm]{probe.2}
58  c)\\  b) \includegraphics[width=10cm]{probe.1}
59  b)\\\includegraphics[width=15cm]{probe.1}  c)
60  \caption{  \caption{
61  \label{figanisoprobe}  \label{figanisoprobe}
62  a) The probe textures for the three smallest mipmap levels.  a) Example probe textures for the three smallest mipmap levels.
63  Each texture has a single white texel at a single mipmap level.  Each texture has a single white texel at a single mipmap level, the rest of the texels
64  b) The pixel-sized quads and their texture coordinates for  and mipmap levels being gray.
65  probing the sampling of the third and second smallest mipmap levels ...  b) The pixel-sized quads using textures such as the ones in a) to give
66  b) An example image produced by such quads: how the XXX card  the contributions of each texel to a particular quad. All quads are rendered
67    with the exactly same texture coordinates and vertex coordinates relative
68    to the pixel.
69    c) An example image produced by such quads: how the XXX card
70  samples the mipmap levels in XXX aniso XXX  samples the mipmap levels in XXX aniso XXX
71  }  }
72  \end{figure*}  \end{figure*}
73    
74  - ASSUMPTIONS: pixel/texel translation invariance, both in screen and texture-space,  - difficulty in probing hardware: each free variable grows number of probes to make
75    driver not detecting software and applying different rules, driver    exponentially - have to make as strict assumptions as possible
   not changing algorithm for screenshot images / moving images, ...  
76    
77  - define separate texture $T_n$ for each mipmap level, with exactly one light  - ASSUMPTIONS:
78    texel at that mipmap level, all other texels and mipmap levels middle gray(!)    driver not detecting software and applying different rules, driver
79    (we define $T_n$ to be the 1x1 texture, $T_{n-1}$ to be the 2x2 texture etc.    not changing algorithm for screenshot images / moving images,
80      driver not looking at texture images and deciding filtering
81      algorithms based on that (image-sensitive filters).
82      (can use linear algebra to do this then).
83      Filters are linear (nonlinearities in the filters - to our knowledge none yet; gamma correction?).
84    
85    - SEMI-ASSUMPTIONS (trivial to adjust algorithm): all texture units produce
86      the same results (in some drivers, this is not the case - 3dcenter about nv 51.XX series
87      DirectX),
88      Driver isn't using a different set of samples for large and small triangles,
89      e.g. NV patent describing using lower mipmap level!
90      pixel translation invariance, in screen space.
91    
92    - define separate texture $T_{(k),x,y}$ for each texel of each
93      mipmap level, with exactly one light
94      texel at the point $(x,y)$ of that mipmap level, all other texels and mipmap levels middle gray
95      (we define level $(n)$ to be the 1x1 texture, ${n-1}$ to be the 2x2 texture etc.
96    Non-square mipmap hierarchies are a simple generalization)    Non-square mipmap hierarchies are a simple generalization)
97            
98      - gray so we see also if there are negative weights in the filter!      - gray so we see also if there are negative weights in the filter!
99    
100      - set to wrap so no border / edge effects; to see these properly,  - select the texture coordinates for a single-pixel quad for which you want
101        more textures are needed    to see contributions.
   
 - select the texture coordinates for a single-pixel quad where you want  
   to see contributions: $(s_0, t_0), (s_1, t_1), (s_2, t_2), (s_3, t_3)$.  
102    In reality, only a triangle gets used so these should be linearly obtained    In reality, only a triangle gets used so these should be linearly obtained
103    from three coordinates but it's still easier for a human to understand these    from three coordinates but it's still easier for a human to understand these
104    as quads    as quads...
105    
106  - For each miplevel texture, render a one-pixel quad for each texel at that level,  - For each mipmap level texel, render a one-pixel quad,
107    with texture coordinates shifted by multiples of $1/s_n$ where $s_n$ is the    with the same texture coordinates and
   length of the mipmap side on level $n$.  
108    
109  - Resulting image gives contribution from each texel on a mipmap level  - Resulting image gives contribution from each texel on a mipmap level
110    to the final image, PROVIDED ASSUMPTIONS HOLD.    to the final image, PROVIDED ASSUMPTIONS HOLD.
111    
112    - the single-texture quads (or values read from screen) can then be used
113      in other visualizations
114    
115  - utility in our free software OpenGL libvob system  - utility in our free software OpenGL libvob system
116    
 - relatively simple generalization to using projective coordinates  
   
 - problem: image-sensitive filters  
117    
     - need to use linear algebra to find out functions by perturbing images  
118    
119  - nonlinearities - to our knowledge none yet  A similar technique appears to be used more commonly used for probing hardware
120    antialiasing patterns, (XXX should we?).
121    
122  - assumptions about the contents of the mipmap levels  - assumptions about the contents of the mipmap levels
123    
# Line 95  samples the mipmap levels in XXX aniso X Line 127  samples the mipmap levels in XXX aniso X
127        as the contribution of four texels on a higher mimap level as per        as the contribution of four texels on a higher mimap level as per
128        the assumption of generating the mipmap levels in the usual way        the assumption of generating the mipmap levels in the usual way
129    
130    
131  \section{Surprise: stretch-squish can yield better images in orthogonal transformations}  \section{Surprise: stretch-squish can yield better images in orthogonal transformations}
132    
133  - case we consider: sharp edges, orthogonal (or nearly so) transformations, e.g. text  - case we consider: sharp edges, orthogonal (or nearly so) transformations, e.g. text
# Line 105  sampling at too low a resolution for muc Line 138  sampling at too low a resolution for muc
138  - LOD bias sharpening causes spatial and temporal aliasing (flickering)  - LOD bias sharpening causes spatial and temporal aliasing (flickering)
139    
140  - simple solution for improving the situation in one direction:  - simple solution for improving the situation in one direction:
141    stretch the texture in one direction, squish back by texture coordinates. This activates    stretch the texture in one direction, squish back by texture coordinates. activate
142    the aniso filter    the aniso filter. Aniso filters planned so that they don't flicker, either.
143    
144  \begin{figure}  \begin{figure}
145  a)\\  a)\\
# Line 184  Seveeral aspects we did not touch Line 217  Seveeral aspects we did not touch
217    
218  - LCD-text  - LCD-text
219    
220    - due to the driver situation (ATI's Linux drivers still weak) we haven't been able to
221      test ATI cards ...
222    
223    
224  \section{Acknowledgments}  \section{Acknowledgments}
225    

Legend:
Removed from v.1.7  
changed lines
  Added in v.1.8

savannah-hackers-public@gnu.org
ViewVC Help
Powered by ViewVC 1.1.26