/[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.27 by jvk, Fri Oct 31 17:54:54 2003 UTC revision 1.28 by tjl, Wed Nov 12 13:16:51 2003 UTC
# Line 1  Line 1 
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}
# Line 49  attention to what assumptions have to be Line 55  attention to what assumptions have to be
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}.
# Line 59  On the other hand, in real-time renderin Line 67  On the other hand, in real-time renderin
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
# Line 70  This has led to the development of sever Line 79  This has led to the development of sever
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}}}
# Line 126  The two highlighted diagrams are the one Line 129  The two highlighted diagrams are the one
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,
# Line 139  we found pixel footprint in screen space Line 142  we found pixel footprint in screen space
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
# Line 159  elegantly by probing the hardware accele Line 161  elegantly by probing the hardware accele
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.
# Line 215  to the improvements in the actual filter Line 217  to the improvements in the actual filter
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
# Line 307  Magnified examples of text filtered usin Line 309  Magnified examples of text filtered usin
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 \\
# Line 319  Vertex-based supersampling & Line 324  Vertex-based supersampling &
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}
# Line 379  other manufacturers such as ATI mostly f Line 384  other manufacturers such as ATI mostly f
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    
# Line 432  Digit-life XXX NVIDIA, ATI patterns Line 466  Digit-life XXX NVIDIA, ATI patterns
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    
# Line 487  Note that only the texture matrix and te Line 521  Note that only the texture matrix and te
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}

Legend:
Removed from v.1.27  
changed lines
  Added in v.1.28

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