gzz-commits
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gzz-commits] manuscripts ./gzigzag.bib AniFont/Makefile AniF...


From: Tuomas J. Lukka
Subject: [Gzz-commits] manuscripts ./gzigzag.bib AniFont/Makefile AniF...
Date: Fri, 17 Oct 2003 05:15:23 -0400

CVSROOT:        /cvsroot/gzz
Module name:    manuscripts
Branch:         
Changes by:     Tuomas J. Lukka <address@hidden>        03/10/17 05:15:22

Modified files:
        .              : gzigzag.bib 
        AniFont        : Makefile anifont.tex 
Added files:
        AniFont        : SCRATCH footprint.mp 

Log message:
        Arch sync

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/manuscripts/gzigzag.bib.diff?tr1=1.140&tr2=1.141&r1=text&r2=text
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/manuscripts/AniFont/SCRATCH?rev=1.1
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/manuscripts/AniFont/footprint.mp?rev=1.1
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/manuscripts/AniFont/Makefile.diff?tr1=1.2&tr2=1.3&r1=text&r2=text
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/manuscripts/AniFont/anifont.tex.diff?tr1=1.11&tr2=1.12&r1=text&r2=text

Patches:
Index: manuscripts/AniFont/Makefile
diff -u manuscripts/AniFont/Makefile:1.2 manuscripts/AniFont/Makefile:1.3
--- manuscripts/AniFont/Makefile:1.2    Tue Sep 30 06:46:17 2003
+++ manuscripts/AniFont/Makefile        Fri Oct 17 05:15:22 2003
@@ -1,7 +1,13 @@
 
-anifont.ps: probe.1 probe.2 anifont.tex
+anifont.ps: probe.1 probe.2 footprint.1 anifont.tex
+       latex anifont
+       BIBINPUTS=..:$$BIBINPUTS bibtex anifont
+       latex anifont
        latex anifont
        dvips anifont
 
 probe.1 probe.2: probe.mp
        mpost probe.mp
+
+footprint.1: footprint.mp
+       mpost footprint.mp
Index: manuscripts/AniFont/anifont.tex
diff -u manuscripts/AniFont/anifont.tex:1.11 
manuscripts/AniFont/anifont.tex:1.12
--- manuscripts/AniFont/anifont.tex:1.11        Wed Oct 15 06:36:40 2003
+++ manuscripts/AniFont/anifont.tex     Fri Oct 17 05:15:22 2003
@@ -3,7 +3,8 @@
 \usepackage{beton}
 \begin{document}
 
-\title{Harware anisotropic filters: Probing the Implementations and Why You 
Should Make 2D Isotropic Situations Anisotropic}
+\title{Stretch-Squish Improves Image Quality on Hardware Accelerators: 
+Why You Should Make 2D Isotropic Situations Anisotropic}
 
 \author{Tuomas J. Lukka and Janne Kujala}
 \maketitle
@@ -14,7 +15,7 @@
 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 
+a clearly 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
@@ -32,23 +33,113 @@
 
 \section{Introduction}
 
-Recently, ...
+Recently, we were looking at increasing the resolution of the page
+textures in our system which shows PDF files in a fisheye view, using
+2048x2048 textures for the pages.  
+Hardware anisotropic filtering was
+enabled in order for the fisheye transformation not to blur the textures.  
+The pages were approximately
+letter-size and already scaled vertically nearly to the maximum size,
+but scaled isotropically.  We decided to try to scale both axes to
+the maximum extent, anisotropically, even though we suspected it might
+degrade the image quality.
+
+However, it did not. To our great surprise, the image quality (the
+readability of the text) actually \emph{improved significantly}.
+Stretching the text in the texture and squishing it back with adjusting
+the texture coordinates improved image quality.
+
+The most important area for reading is naturally the center of the fisheye,
+where the transformation is nearly orthonormal - the 
+edges are mostly used for getting a sense of the context, not for reading.
+
+After some investigation, we discovered that we had found a special case
+of a general principle: if a texture image is only transformed through 
+rotation and isotropic scaling, a better filtering result is always obtained
+by applying the stretch-squish operation.
+
+The rest of the article is organized as follows.
+In Section~\ref{secrelated},  we discuss related work
+and texture filtering in general, using pixel footprint in screen space (PFSS)
+diagrams to explain different filtering methods.
+In Section~\ref{secsquish}, we show why the stretch-squish method improves
+image quality and its relation to other filtering methods.
+In Section~\ref{seccomp}, we compare the performance of different filtering
+methods, including trilinear, stretch-squish aniso and supersampling, on a 
test image.
+Finally, we conclude. In Appendix A, we show how PFSS diagrams can be generated
+in an elegant fashion by probing the hardware accelerators' true filtering 
behaviour.
+
+
+\section{Related work; Understanding texture filtering}
+
+\label{secrelated}
+
+
+\subsection{The texture mapping primitive}
 
 Texture mapping is a ubiquitous ... \cite{haeberli93texture}
+originally introduced introduced by Catmull\cite{catmull74}.
+
 
 - off-line rendering: EWA XXXREF
 
+In our investigations for this article, we found the pixel footprint
+diagrams in screen space (PFSS) diagrams most useful for understanding
+the properties of a filtering method w.r.t.~anisotropy.
+Figure~\ref{figfootprint} shows a legend of PFSS diagrams and 
+a diagram for the EWA filtering method.
+Appendix A shows how
+PFSS diagrams can be generated easily to show the actual behaviour of a 
hardware accelerator.
+
+\begin{figure}
+a)\\\includegraphics[width=\columnwidth]{footprint.1}
+b)\\
+\caption{
+\label{figfootprint}
+Pixel footprint in screen space (PFSS) diagram.
+Texture samples' contribution to a pixel's value.
+a) An explanation of PFSS diagrams: the diagrams
+show the contribution of each texel to the pixel
+as a color (black = no contribution, white = large contribution).
+b) An example PFSS of an EWA texture filterer. In screen space, the
+filter is circular and has soft edges.
+}
+\end{figure}
+
+\subsection{Mipmapping: bi- and trilinear filtering}
+
 - Trilinear/bilinear (mipmap) filtering was designed to avoid temporal and 
spatial aliasing\cite{williams83pyramidal}
 
 - can blur sharp edges (text) too much
-
 - for 3D rendering, trilinear blurs when seen obliquely, 
\emph{anisotropically} 
   (squished more in one direction than in another).
 
+
+\begin{figure}
+a)\\
+b)\\
+c)\\
+\caption{
+\label{figbitrilinear}
+Example PFSS diagrams: a) bilinear, b), c) trilinear filtering.
+The trilinear footprint is the weighted sum of two bilinear footprints.
+In c), the texture is mapped quite anisotropically and the 
+blurring effect of trilinear filtering is obvious - the footprint
+is much larger in the XXX direction than it should be.
+These filters were probed on an XXX.
+The diagrams assume a box filter for generating the mipmaps, 
+as contributions from different mipmaps are directly blended
+over each other.
+}
+\end{figure}
+
+
+\subsection{Anisotropic texture filtering}
+
 - 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\cite{olano98pixelflow}
+- Unextended OpenGL aniso: article on using lod bias etc to get 
it\cite{olano01vertexbasedaniso}
 
 - supersampling: FSAA / as above; however, most cards focus on multisampling, 
not supersampling - 
   no help for textures
@@ -75,47 +166,35 @@
   the aniso filter. Aniso filters planned so that they don't flicker, either.
 
 
-The rest of the article is organized as follows.
-
-\section{Surprise: stretch-squish can yield better images in orthogonal 
transformations}
-
-Recently, we were looking at increasing the resolution of the page
-textures in our system which shows PDF files in a fisheye view, using
-2048x2048 textures for the pages.  
-Hardware anisotropic filtering was
-enabled in order for the fisheye transformation not to blur the textures.  
-The pages were approximately
-letter-size and already scaled vertically nearly to the maximum size,
-but scaled isotropically.  We decided to try to scale both axes to
-the maximum extent, anisotropically, even though we suspected it might
-degrade the image quality.
-
-However, it did not. To our great surprise, the image quality (the
-readability of the text) actually \emph{improved significantly}.
-Stretching the text in the texture and squishing it back with adjusting
-the texture coordinates improved image quality.
+\begin{figure}
+a)\\
+b)\\
+c)\\
+\caption{
+\label{figaniso}
+Anisotropic filtering. 
+On the same card and same texture coordinates as
+Fig.~\ref{figbitrilinear} c), but with anisotropic
+filtering enabled, the PFSS diagram shows a much better (smaller)
+footprint.
+}
+\end{figure}
 
-The most important area for reading is naturally the center of the fisheye,
-where the transformation is nearly orthonormal - the 
-edges are mostly used for getting a sense of the context, not for reading.
 
-After some investigation, we discovered that we had found a special case
-of a general principle: if a texture image is only transformed through 
-rotation and isotropic scaling, a better filtering result is always obtained
-by applying the stretch-squish operation.
+\section{Why does stretch and squish improve image quality?}
 
 \begin{figure}
 a)\\
 b)\\
 \caption{
 \label{figstretchsquishsamples}
-Texture samples' contribution to a pixel's value.
-Appendix A shows how
-these figures can be generated easily to show the actual behaviour of the 
hardware.
+PFSS diagrams of an orthonormal rendering situation,
+showing how stretch-squish works. 
 a) Normal trilinear filtering. Playing around with a view like this of 
filtering
 can show how \emph{bad} trilinear filtering really is. 
 b) Stretching the texture and squishing it allows more samples to be used
-through an anisotropic filter. Here: XXX
+through an anisotropic filter. The footprint in XXX direction is much closer
+to the actual pixel; there is less blur in the output.
 }
 \end{figure}
 
@@ -205,24 +284,6 @@
 
 - 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
 
@@ -279,6 +340,8 @@
       as the contribution of four texels on a higher mimap level as per
       the assumption of generating the mipmap levels in the usual way
 
+\bibliographystyle{abbrv}
+\bibliography{gzigzag}
 
 \appendix
 
Index: manuscripts/gzigzag.bib
diff -u manuscripts/gzigzag.bib:1.140 manuscripts/gzigzag.bib:1.141
--- manuscripts/gzigzag.bib:1.140       Wed Oct 15 06:36:40 2003
+++ manuscripts/gzigzag.bib     Fri Oct 17 05:15:21 2003
@@ -5823,9 +5823,8 @@
     title = {Asymptotically Efficient Approaches to Fault-Tolerance in 
Peer-to-Peer Networks},
     booktitle = {Proceedings of 17th International Symposium on Distributed 
Computing},
     year = {2003},
-    month = {October}   
-    url = {http://oceanstore.cs.berkeley.edu/publications/papers/pdf/disc.pdf},
-
+    month = {October}   ,
+    url = {http://oceanstore.cs.berkeley.edu/publications/papers/pdf/disc.pdf}
 }
 
 @comment -------------------------
@@ -6093,7 +6092,7 @@
 }
 
 
address@hidden
address@hidden,
   AUTHOR = {Ben Lynn},
   TITLE = {Authenticated Identity-Based Encryption},
   INSTITUTION = {Cryptology ePrint Archive},  
@@ -6165,7 +6164,7 @@
 @article{ fraser90live,
     author = "C. Fraser and B. Krishnamurthy",
     title = "Live Text",
-    journal = "Software Practice and Experience"
+    journal = "Software Practice and Experience",
     volume = "20",
     number = "8",
     pages = "851-858",




reply via email to

[Prev in Thread] Current Thread [Next in Thread]