[Top][All Lists]
[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",
- [Gzz-commits] manuscripts ./gzigzag.bib AniFont/Makefile AniF...,
Tuomas J. Lukka <=