1 |
\documentclass[twocolumn,10pt]{article} |
\documentclass[twocolumn,10pt]{article} |
2 |
\usepackage{graphicx} |
\usepackage{graphicx} |
3 |
\usepackage{fancybox} |
\usepackage{fancybox} |
4 |
\usepackage{beton} |
% \usepackage{beton} |
5 |
|
\usepackage{times} |
6 |
\usepackage{caption2} |
\usepackage{caption2} |
7 |
|
|
8 |
|
%\makeatletter |
9 |
|
%\def\verbatim@font{\normalfont\small\sffamily} |
10 |
|
%\makeatother |
11 |
|
|
12 |
\begin{document} |
\begin{document} |
13 |
|
|
14 |
\renewcommand{\topfraction}{.1} |
\renewcommand{\topfraction}{.1} |
55 |
|
|
56 |
\section{Introduction} |
\section{Introduction} |
57 |
|
|
58 |
|
XXX GAMMA |
59 |
|
|
60 |
Texture mapping is a ubiquitous computer graphics |
Texture mapping is a ubiquitous computer graphics |
61 |
primitive\cite{heckbert86survey,haeberli93texture} |
primitive\cite{heckbert86survey,haeberli93texture} |
62 |
originally introduced in \cite{catmull74}. |
originally introduced in \cite{catmull74}. |
67 |
hardware-accelerators, it is important that the number of samples can be |
hardware-accelerators, it is important that the number of samples can be |
68 |
kept constant regardless of the pixel footprint. |
kept constant regardless of the pixel footprint. |
69 |
|
|
70 |
Trilinear (mipmap) filtering\cite{williams83pyramidal} |
Trilinear (mipmap) filtering\cite{williams83pyramidal}, |
71 |
|
the current \emph{de facto} standard texture filter, |
72 |
was designed to avoid temporal and spatial aliasing while only requiring 8 |
was designed to avoid temporal and spatial aliasing while only requiring 8 |
73 |
texture samples per pixel. |
texture samples per pixel. |
74 |
For 3D rendering, the most well-known problem of |
For 3D rendering, the most well-known problem of |
79 |
that usually work through some type of |
that usually work through some type of |
80 |
\emph{footprint assembly}, i.e. assembling a better approximation |
\emph{footprint assembly}, i.e. assembling a better approximation |
81 |
to the pixel footprint in texture space from normal mipmap samples or by using |
to the pixel footprint in texture space from normal mipmap samples or by using |
82 |
trilinear \emph{probes}. %probes? |
trilinear \emph{probes}. |
83 |
|
Most graphics accelerators today support trilinear filtering along |
84 |
|
with some type of anisotropic filtering and either super- or multisampling. |
85 |
|
|
|
While summed-area tables(XXX CROWREF) can often provide |
|
|
better rendering quality, their hardware implementation is not easy, as discussed in |
|
|
% isn't it not even applicable to rotated mappings?! |
|
|
% so ``today ...'' below doesn't seem to follow from the above |
|
|
(XXX ref to fast footprint/... discussing this), so today trilinear rendering, supplemented |
|
|
with some form of anisotropic filtering |
|
|
is the \emph{de facto} standard in hardware accelerators, supplemented by |
|
|
support for full-screen super- or multisampling. |
|
86 |
|
|
87 |
\def\snapsize{2.4cm} |
\def\snapsize{2.4cm} |
88 |
\def\snapshot#1{\raisebox{-2cm}{\includegraphics[totalheight=\snapsize]{#1}}} |
\def\snapshot#1{\raisebox{-2cm}{\includegraphics[totalheight=\snapsize]{#1}}} |
129 |
\end{figure*} |
\end{figure*} |
130 |
|
|
131 |
|
|
132 |
In this article, we consider texture filtering in the overlooked, |
In this article, we consider texture filtering in the often overlooked |
133 |
isotropic or nearly isotropic case. Even in the isotropic case, trilinear |
isotropic or nearly isotropic case. Even in the isotropic case, trilinear |
134 |
can blur small features that appear in, e.g., text. |
can blur small features that appear in, e.g., text. |
135 |
We discovered accidentally that stretching an image anisotropically |
We discovered accidentally that stretching an image anisotropically |
136 |
when placing it into a texture and squishing it back when rendering |
when placing it into a texture and squishing it back when rendering |
137 |
using texture coordinates, all the while enabling anisotropic filtering, |
using texture coordinates, while enabling anisotropic filtering, |
138 |
yields a considerably better image quality for text. |
yields a considerably better image quality for text. |
139 |
|
|
140 |
In looking to understand why the stretch-squish method works, |
In looking to understand why the stretch-squish method works, |
142 |
extremely useful, contrary to the usual practice in the |
extremely useful, contrary to the usual practice in the |
143 |
texture filtering literature to |
texture filtering literature to |
144 |
visualize the pixel footprint exclusively in the texture space. |
visualize the pixel footprint exclusively in the texture space. |
145 |
Our PFSS diagrams show a highly magnified pixel (e.g. 100 pixels in side) |
Our PFSS diagrams show a highly magnified (e.g., 100x) pixel |
|
% 100 pixels in side? 100x mag? |
|
146 |
and the contributions (assuming box filtering for the mipmap levels) |
and the contributions (assuming box filtering for the mipmap levels) |
147 |
from the texels mapped to the surrounding area by a color. |
from the texels mapped to the surrounding area by a color. |
148 |
Figure~\ref{figallpfss} shows |
Figure~\ref{figallpfss} shows |
161 |
|
|
162 |
|
|
163 |
|
|
|
\label{secrelated} |
|
164 |
|
|
165 |
|
|
166 |
\section{Related work} |
\section{Related work} |
167 |
|
\label{secrelated} |
168 |
|
|
169 |
In this Section, we discuss the known methods to improve the quality of |
In this Section, we discuss the known methods to improve the quality of |
170 |
hardware-accelerated texture filtering in isotropic situations. |
hardware-accelerated texture filtering in isotropic situations. |
217 |
% is orthogonoal in the opengl functionality sense generally understood? |
% is orthogonoal in the opengl functionality sense generally understood? |
218 |
|
|
219 |
\section{Stretch and squish improves image quality} |
\section{Stretch and squish improves image quality} |
220 |
|
\label{secsquish} |
221 |
|
|
222 |
\begin{figure}[thb!] |
\begin{figure}[thb!] |
223 |
\centering |
\centering |
309 |
\begin{table*} |
\begin{table*} |
310 |
\begin{minipage}{\textwidth} |
\begin{minipage}{\textwidth} |
311 |
\begin{tabular}{p{3cm}|lllll} |
\begin{tabular}{p{3cm}|lllll} |
312 |
Method & HW req & Clarity & Aliasing & Code changes & Relative time per pixel\\ |
Method & HW req & Clarity & Aliasing & Code changes & Relative time per pixel |
313 |
|
\footnote{The numbers are approximate, |
314 |
|
combined from measurements on several |
315 |
|
kinds of hardware}\\ |
316 |
\hline\\ |
\hline\\ |
317 |
Trilinear & Any & Blurry & --- & --- & 1 \\ |
Trilinear & Any & Blurry & --- & --- & 1 \\ |
318 |
Trilinear, LOD bias & Any & Less blurry & Bad & trivial & 1---2 \\ |
Trilinear, LOD bias & Any & Less blurry & Bad & trivial & 1---2 \\ |
324 |
supporting LOD biasing, however with a significantly larger performance drop due to multiple passes |
supporting LOD biasing, however with a significantly larger performance drop due to multiple passes |
325 |
and blending..} & Good & --- & significant & 4---6 \\ |
and blending..} & Good & --- & significant & 4---6 \\ |
326 |
Fragment-based supersampling & |
Fragment-based supersampling & |
327 |
NV3X+ & Good & --- & trivial & 10---20 \\ |
NV3X+ & Good & --- & trivial & 10---12 \\ |
328 |
\hline |
\hline |
329 |
\end{tabular} |
\end{tabular} |
330 |
\end{minipage} |
\end{minipage} |
384 |
In our investigations for this article, we found the pixel footprint |
In our investigations for this article, we found the pixel footprint |
385 |
diagrams in screen space (PFSS) diagrams most useful for understanding |
diagrams in screen space (PFSS) diagrams most useful for understanding |
386 |
the properties of a filtering method w.r.t.~anisotropy. |
the properties of a filtering method w.r.t.~anisotropy. |
387 |
|
These diagrams show, as dark lines, the edges of the highly |
388 |
|
(100x or more) |
389 |
|
magnified pixel. The texture is mapped on top of the magnified pixel |
390 |
|
with the some transformation, but instead of colors, the texels are |
391 |
|
made to represent the \emph{contribution} of the texel to the final |
392 |
|
value of the pixel. |
393 |
|
|
394 |
|
It is unfortunate that manufacturers do not provide details of what their |
395 |
|
hardware is actually doing; |
396 |
|
for careful graphics work, it is useful to be able to understand the algorithms |
397 |
|
used. We are left with the approach of looking at the hardware as a physical |
398 |
|
phenomenon and doing \emph{experiments} to find out how it functions. |
399 |
|
This is not always simple: |
400 |
|
each free variable grows number of experiments to make |
401 |
|
exponentially, which is why we have to make as strict assumptions as possible |
402 |
|
about invariances beforehand. |
403 |
|
|
404 |
|
The most important invariance asusmptions we make are |
405 |
|
that the driver is not detecting which software is being run |
406 |
|
and changing its behavior and that the driver is not changing |
407 |
|
the filtering algorithms for screenshot images versus normal images. |
408 |
|
If it is, working around it is nontrivial. Also, we assume that the filters |
409 |
|
used by the hardware are linear --- nonlinear filters would be much more |
410 |
|
difficult to probe experimentally. |
411 |
|
|
412 |
|
Some other assumptions whose violations would be somewhat easier to |
413 |
|
work around are: that the implementation is not looking at the contents |
414 |
|
of the texture images and deciding filtering algorithms based on |
415 |
|
them (image-sensitive filtering; if this is the case, linear algebra |
416 |
|
might be used to find the filter for particular kinds of |
417 |
|
input images); that there are no negative weights in the filter (if this |
418 |
|
is suspected, gray should be used instead of black in the probe texture, |
419 |
|
and the blending of the final image should be altered); |
420 |
|
that all texture units produce the same results (workaround: |
421 |
|
use more texture units and linear algebra to separate the contribution |
422 |
|
of one); |
423 |
|
that pixel translation invariance in screen space holds |
424 |
|
accurately (workaround: instead of rendering the pixels below |
425 |
|
at different locations, render and CopyTexSubImage a single pixel sequentially); |
426 |
|
that a quad rendered at a single pixel affects no neighbouring |
427 |
|
pixels (violated, e.g., in NVIDIA's Quincunx multisampling; workaround: |
428 |
|
render 3x3 quads as probes and use the middle pixel for CopyTexSubImage). |
429 |
|
|
430 |
|
%Digit-life XXX NVIDIA, ATI patterns - ? Method of probing not explained; |
431 |
|
%is the data real? |
432 |
|
|
433 |
|
|
434 |
|
%- ASSUMPTIONS: |
435 |
|
% driver not detecting software and applying different rules, driver |
436 |
|
% not changing algorithm for screenshot images / moving images, |
437 |
|
% driver not looking at texture images and deciding filtering |
438 |
|
% algorithms based on that (image-sensitive filters). |
439 |
|
% (can use linear algebra to do this then). |
440 |
|
% Filters are linear (nonlinearities in the filters - to our knowledge none yet; gamma correction?). |
441 |
|
|
442 |
|
%- SEMI-ASSUMPTIONS (trivial to adjust algorithm): all texture units produce |
443 |
|
% the same results (in some drivers, this is not the case - 3dcenter about nv 51.XX series |
444 |
|
% DirectX), |
445 |
|
% Driver isn't using a different set of samples for large and small triangles, |
446 |
|
% pixel translation invariance, in screen space. |
447 |
|
% Only positive weights in the filter (can use |
448 |
|
% gray so we see also if there are negative weights in the filter) |
449 |
|
|
450 |
In this Section, we |
%- FSAA does not blur samples from neighbouring pixels |
451 |
- Graphics companies unfortunately do not provide ... |
% |
452 |
|
% - if it does, render larger quads further apart. |
453 |
The diagrams assume a box filter for generating the mipmaps, |
% and use CopyTexSubImage instead of CopyTexImage |
|
as contributions from different mipmaps are directly blended |
|
|
over each other. |
|
|
|
|
|
This seems to be a well-known technique that has not so far been published |
|
|
anywhere |
|
|
A similar technique appears to be used more commonly used for probing hardware |
|
|
antialiasing patterns, |
|
|
|
|
|
|
|
|
- Graphics companies unfortunately do not provide ... |
|
|
|
|
|
Digit-life XXX NVIDIA, ATI patterns |
|
|
|
|
|
- for careful work, you'll want to know what your driver is doing |
|
|
|
|
|
- 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, |
|
|
pixel translation invariance, in screen space. |
|
|
|
|
|
- gray so we see also if there are negative weights in the filter! |
|
454 |
|
|
455 |
- select the texture matrix to map the single-pixel texture quad ... |
- select the texture matrix to map the single-pixel texture quad ... |
456 |
|
|
466 |
|
|
467 |
- utility in our free software OpenGL libvob system |
- utility in our free software OpenGL libvob system |
468 |
|
|
|
- FSAA does not blur samples from neighbouring pixels |
|
469 |
|
|
|
- if it does, render larger quads further apart. |
|
|
and use CopyTexSubImage instead of CopyTexImage |
|
470 |
|
|
471 |
|
The diagrams assume a box filter for generating the mipmaps, |
472 |
|
as contributions from different mipmaps are directly blended |
473 |
|
over each other. |
474 |
|
|
475 |
- assumptions about the contents of the mipmap levels |
- assumptions about the contents of the mipmap levels |
476 |
|
|
521 |
for texture 1 need to be changed |
for texture 1 need to be changed |
522 |
for probing different texture-to-screen mappings |
for probing different texture-to-screen mappings |
523 |
|
|
524 |
|
Probing hardware texture filters in this |
525 |
|
way is a simple technique that does not appear to have been published |
526 |
|
anywhere; |
527 |
|
a somewhat analogous technique appears to be used more commonly used for probing hardware |
528 |
|
antialiasing patterns, by rendering subpixel-sized quads with different |
529 |
|
subpixel shifts and seeing which ones actually cause something to be rendered(XXXREF). |
530 |
|
|
531 |
\end{document} |
\end{document} |