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} |
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 |
|
|
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 |
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)\\ |
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 |
|
|