[Gzz-commits] manuscripts/AniFont anifont.tex

[Janne V. Kujala]

CVSROOT:        /cvsroot/gzz
Module name:    manuscripts
Branch:         
Changes by:     Janne V. Kujala <address@hidden>        03/10/31 11:55:54

Modified files:
        AniFont        : anifont.tex 

Log message:
        twids

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/manuscripts/AniFont/anifont.tex.diff?tr1=1.25&tr2=1.26&r1=text&r2=text

Patches:
Index: manuscripts/AniFont/anifont.tex
diff -u manuscripts/AniFont/anifont.tex:1.25 
manuscripts/AniFont/anifont.tex:1.26
--- manuscripts/AniFont/anifont.tex:1.25        Fri Oct 31 04:16:31 2003
+++ manuscripts/AniFont/anifont.tex     Fri Oct 31 11:55:53 2003
@@ -22,7 +22,7 @@
 \title{Stretch-Squish Improves Image Quality on Hardware Accelerators: 
 Why You Should Make 2D Isotropic Situations Anisotropic}
 
-\author{Tuomas J. Lukka and Janne Kujala}
+\author{Tuomas J. Lukka and Janne V. Kujala}
 \maketitle
 
 \begin{abstract}
@@ -53,7 +53,7 @@
 primitive\cite{heckbert86survey,haeberli93texture}
 originally introduced in \cite{catmull74}. 
 In off-line rendering, good algorithms for calculating 
-pixel values by a weighted numerically integral of the texels falling
+pixel values by a weighted numerical integral of the texels falling
 inside a pixel have been known for a long time(XXX EWAREF).
 On the other hand, in real-time rendering through 
 hardware-accelerators, it is important that the number of samples can be
@@ -63,17 +63,19 @@
 was designed to avoid temporal and spatial aliasing while only requiring 8 
 texture samples per pixel. 
 For 3D rendering, the most well-known problem of
-trilinear filtering is that it blurs the texture the pixel footprint in 
texture space
+trilinear filtering is that it blurs the texture when the pixel footprint in 
texture space
 is far from square, i.e., in \emph{anisotropic} situations
 (squished more in one direction than in another).
 This has led to the development of several anisotropic filtering 
algorithms(REFS feline texram talisman spaf ffp...)
 that usually work through some type of
 \emph{footprint assembly}, i.e. assembling a better approximation
 to the pixel footprint in texture space from normal mipmap samples or by using
-trilinear \emph{probes}.
+trilinear \emph{probes}. %probes?
 
 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
@@ -117,6 +119,10 @@
 is much larger in the vertical direction than it should be.
 The two highlighted diagrams are the ones relevant to understanding 
stretch-squish.
 }
+% Should we use the same orientation in both iso and aniso case so that
+% the strech-squish imporvement could be directly assessed?
+% Perhaps the difference should be explained in the caption as 
+% the aniso/tri+aniso cannot be obviosly seen as better than iso/trilinear.
 \end{figure*}
 
 
@@ -132,8 +138,9 @@
 we found pixel footprint in screen space (PFSS) diagrams 
 extremely useful, contrary to the usual practice in the
 texture filtering literature to 
-visualize the pixel footprint is exclusively in the texture space.
+visualize the pixel footprint exclusively in the texture space.
 Our PFSS diagrams show a highly magnified pixel (e.g. 100 pixels in side)
+% 100 pixels in side? 100x mag?
 and the contributions (assuming box filtering for the mipmap levels)
 from the texels mapped to the surrounding area by a color.
 Figure~\ref{figallpfss} shows 
@@ -170,7 +177,7 @@
 number of samples from textures and cannot be easily implemented on current 
hardware..
 Summed-area tables\cite{crow84summedareatables} could be a great improvement 
but,
 while they can be implemented using fragment programs on some of the current 
hardware,
-are rather slow in such an implementation.
+are rather slow in such an implementation. % ref?
 
 A conventional way to obtain blurring or sharpening
 blurring artifacts is to use a
@@ -188,6 +195,7 @@
 to anisotropic filtering using unextended OpenGL 
 given in \cite{olano01vertexbasedaniso}
 to supersampling by adjusting the texture coordinates in screen space.
+% the above is ambiguous ``the approach to anisotropic filtering''
 However, this approach does restrict the OpenGL texture environment
 and blend modes available unless the hardware supports enough texture
 accesses to accomplish the complete operation in one pass (e.g., 4 for 2x2 
supersampling).
@@ -204,6 +212,7 @@
 The Advanced OpenGL course notes(XXX REF) suggest ``generating the mipmap 
levels carefully, e.g.  XXX''.
 This appears to be largely unexplored territory and seems to be, in any case, 
orthogonal
 to the improvements in the actual filtering methods.
+% is orthogonoal in the opengl functionality sense generally understood?
 
 \section{Stretch and squish improves image quality}
 
@@ -241,7 +250,7 @@
 an isotropic texture. This is shown in detail in 
Fig.~\ref{figstretchsquishwhyworks}.
 The trilinear filter footpring size depends strongly on subpixel position and 
 can be quite large compared to the actual pixel, causing blurring.
-When using the anisotropic filter, the footprint is remains significantly 
smaller
+When using the anisotropic filter, the footprint remains significantly smaller
 in one direction regardless of subpixel shifting --- in the other direction,
 it is similar.
 
@@ -266,6 +275,10 @@
 \caption{
 \label{figexamples}
 Magnified examples of text filtered using several algorithms.
+% Hard to assess quality if zoomed too much (if the pixels are clearly
+% visible, the grid structure will obscure the actual image).
+% Is this fig referred to?
+
 }
 \end{figure*}