[Gzz-commits] manuscripts/AniFont Makefile SCRATCH anifont.te...

[Tuomas J. Lukka]

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

Modified files:
        AniFont        : Makefile SCRATCH anifont.tex 
Added files:
        AniFont        : methods.gnumeric 
        AniFont/snaps  : aniso-font-horiz2.png aniso-font-lodbias.png 
                         aniso-font-trilinear.png aniso-font-vert2.png 
                         aniso-gf4go-aniso-nearest.png 
                         aniso-gf4go-aniso.png aniso-gf4go-bilinear.png 
                         aniso-gf4go-nearest.png 
                         aniso-gf4go-ortho-stretchsquish.png 
                         aniso-gf4go-ortho-trilinear.png 
                         aniso-gf4go-trilinear-aniso.png 
                         aniso-gf4go-trilinear.png 

Log message:
        Merge

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/manuscripts/AniFont/methods.gnumeric?rev=1.1
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/manuscripts/AniFont/Makefile.diff?tr1=1.4&tr2=1.5&r1=text&r2=text
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/manuscripts/AniFont/SCRATCH.diff?tr1=1.1&tr2=1.2&r1=text&r2=text
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/manuscripts/AniFont/anifont.tex.diff?tr1=1.14&tr2=1.15&r1=text&r2=text
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/manuscripts/AniFont/snaps/aniso-font-horiz2.png?rev=1.1
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/manuscripts/AniFont/snaps/aniso-font-lodbias.png?rev=1.1
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/manuscripts/AniFont/snaps/aniso-font-trilinear.png?rev=1.1
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/manuscripts/AniFont/snaps/aniso-font-vert2.png?rev=1.1
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/manuscripts/AniFont/snaps/aniso-gf4go-aniso-nearest.png?rev=1.1
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/manuscripts/AniFont/snaps/aniso-gf4go-aniso.png?rev=1.1
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/manuscripts/AniFont/snaps/aniso-gf4go-bilinear.png?rev=1.1
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/manuscripts/AniFont/snaps/aniso-gf4go-nearest.png?rev=1.1
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/manuscripts/AniFont/snaps/aniso-gf4go-ortho-stretchsquish.png?rev=1.1
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/manuscripts/AniFont/snaps/aniso-gf4go-ortho-trilinear.png?rev=1.1
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/manuscripts/AniFont/snaps/aniso-gf4go-trilinear-aniso.png?rev=1.1
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/manuscripts/AniFont/snaps/aniso-gf4go-trilinear.png?rev=1.1

Patches:
Index: manuscripts/AniFont/Makefile
diff -u manuscripts/AniFont/Makefile:1.4 manuscripts/AniFont/Makefile:1.5
--- manuscripts/AniFont/Makefile:1.4    Fri Oct 17 14:17:37 2003
+++ manuscripts/AniFont/Makefile        Wed Oct 22 05:38:05 2003
@@ -1,5 +1,19 @@
+GF4GOSNAPNAMES= \
+       aniso-gf4go-nearest.png  aniso-gf4go-bilinear.png  
aniso-gf4go-trilinear.png \
+       aniso-gf4go-aniso-nearest.png  aniso-gf4go-trilinear-aniso.png  
aniso-gf4go-aniso.png    \
+       aniso-gf4go-ortho-trilinear.png aniso-gf4go-ortho-stretchsquish.png
 
-anifont.ps: probe.1 probe.2 footprint.1 footprint.2 anifont.tex
+LOOPSNAPBASES= \
+       aniso-font-trilinear aniso-font-lodbias aniso-font-horiz2 
aniso-font-vert2
+
+SNAPDIR=../../libvob/snaps
+
+GF4GOSNAPSSOURCE:=$(GF4GOSNAPNAMES:%=../../libvob/snaps/%)
+GF4GOSNAPS:=$(GF4GOSNAPNAMES:%=snaps/%)
+GF4GOSNAPSPS:=$(GF4GOSNAPNAMES:%.png=snapsps/%.ps)
+
+
+anifont.ps: probe.1 probe.2 footprint.1 footprint.2 anifont.tex 
$(GF4GOSNAPSPS) $(LOOPSNAPBASES:%=snapsps/%.ps)
        latex anifont
        BIBINPUTS=..:$$BIBINPUTS bibtex anifont
        latex anifont
@@ -11,3 +25,18 @@
 
 footprint.1: footprint.mp
        mpost footprint.mp
+
+
+
+gf4gosnaps:: $(GF4GOSNAPSPS)
+
+snapsps/%.ps: snaps/%.png
+       pngtopnm < $< | pnmtops > $@ 
+
+$(GF4GOSNAPS): $(GF4GOSNAPSSOURCE)
+       cp $(GF4GOSNAPSSOURCE) snaps/
+
+copyloopsnaps: $(LOOPSNAPBASES:%=../../libvob/snaps/%.png)
+       cp $(LOOPSNAPBASES:%=../../libvob/snaps/%.png) snaps
+
+
Index: manuscripts/AniFont/SCRATCH
diff -u manuscripts/AniFont/SCRATCH:1.1 manuscripts/AniFont/SCRATCH:1.2
--- manuscripts/AniFont/SCRATCH:1.1     Fri Oct 17 05:15:22 2003
+++ manuscripts/AniFont/SCRATCH Wed Oct 22 05:38:05 2003
@@ -17,3 +17,52 @@
 }
 \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.
+
+\begin{figure}
+\begin{tabular*}{\columnwidth}{rc}
+a) & \includegraphics[width=5cm]{footprint.1}  \\
+b) & \includegraphics[width=4cm]{footprint.2}  
+\end{tabular*}
+\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 without
+mipmapping (mockup, just diagrammatic). 
+In screen space, the
+filter is circular and has soft edges, while in texture space it would be
+elliptical.
+}
+\end{figure}
+
+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.
+
+In Section~\ref{seccomp}, we compare the performance of different filtering
+methods, including trilinear, stretch-squish aniso and supersampling, on a 
test image.
+
+
+- For text, setting of the problem: orthogonal transformations are most 
important,
+  TrueType shows maybe not the right model but ...
+
+
+- case we consider: sharp edges, orthogonal (or nearly so) transformations, 
e.g. text
+
+- simple solution for improving the situation in one direction: 
+  stretch the texture in one direction, squish back by texture coordinates. 
activate
+  the aniso filter. Aniso filters planned so that they don't flicker, either.
+
Index: manuscripts/AniFont/anifont.tex
diff -u manuscripts/AniFont/anifont.tex:1.14 
manuscripts/AniFont/anifont.tex:1.15
--- manuscripts/AniFont/anifont.tex:1.14        Fri Oct 17 14:17:37 2003
+++ manuscripts/AniFont/anifont.tex     Wed Oct 22 05:38:05 2003
@@ -12,19 +12,19 @@
 \begin{abstract}
 We demonstrate a simple but counterintuitive hardware-accelerated
 rendering trick for improving image quality.
-When rendering an isotropically textured 2 1/2D scene,
+When rendering isotropically textured polygons (using 2D rotations and 
isotropic
+scaling but no 3D rotations or shearing),
 stretching an image when putting it into a texture
 and squishing it with texture coordinates when rendering yields 
 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
-various generalizations. We show examples of text rendered both ways.
+We show a simple way to understand why this trick works, based 
+on filter footprints.
 
-To show how our demonstration figures were
-generated,
-in an appendix we show how to probe and visualize the texture filtering 
happening
-on an actual hardware graphics accelerator in a general way, paying
+In an appendix we show how our figures showing the actual texel samples used
+by the hardware in different situations were generated,
+paying
 attention to what assumptions have to be made for such probing to work.
 
 
@@ -34,38 +34,27 @@
 \section{Introduction}
 
 Recently, we were looking at increasing the resolution of the page
-textures in our system which shows PDF files in a fisheye view, using
+textures in our FenPDF 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
+but scaled isotropically in the texture.  
+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 texture coordinates improved image quality. In this article, we show
+why this is the case and how easy it is to take advantage of this effect.
 
 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{secrelated},  we discuss related work, i.e., texture filtering 
in general.
 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.
 
@@ -78,131 +67,100 @@
 % \subsection{The texture mapping primitive}
 
 Texture mapping is a ubiquitous ... \cite{heckbert86survey,haeberli93texture}
-originally introduced introduced by Catmull\cite{catmull74}.
+originally introduced by Catmull\cite{catmull74}.
 
 In off-line rendering, off
 
 - 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}
-\begin{tabular*}{\columnwidth}{lc}
-a) &  \\
- & \includegraphics[width=5cm]{footprint.1} \\
-b) & \\
- & \includegraphics[width=4cm]{footprint.2} \\
-\end{tabular*}
-\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 without
-mipmapping (mockup, just diagrammatic). 
-In screen space, the
-filter is circular and has soft edges, while in texture space it would be
-elliptical.
-}
-\end{figure}
-
 % \subsection{Mipmapping: bi- and trilinear filtering}
 
+On the other hand, in real-time rendering through 
+hardware-accelerators, it is important that the number of samples can be
+kept constant regardless of the pixel footprint.
+
 - 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).
+For 3D rendering, the most well-known problem of
+trilinear filtering is that it blurs the texture the pixel footprint in 
texture space
+is far from round, i.e., in \emph{anisotropic} situation
+(squished more in one direction than in another).
+However, even in isotropic situations trilinear filtering
+can blur sharp edges (text) too much.
+
+- for sharp edges / small features, even under orthogonal transformations, 
trilinear bad:
+sampling at too low a resolution for much of the time!
 
 
-\begin{figure}
-a)\\
-b)\\
-c)\\
+    - LOD bias sharpening causes spatial and temporal aliasing (flickering)
+
+\def\snapsize{3cm}
+
+\begin{figure*}
+\begin{tabular}{rcrcrc}
+c) & 
+  \includegraphics[width=\snapsize]{snapsps/aniso-gf4go-nearest.ps}   &
+c) & 
+  \includegraphics[width=\snapsize]{snapsps/aniso-gf4go-bilinear.ps}  &
+c) & 
+  \includegraphics[width=\snapsize]{snapsps/aniso-gf4go-trilinear.ps}   \\
+c) & 
+  \includegraphics[width=\snapsize]{snapsps/aniso-gf4go-aniso-nearest.ps}  &
+c) & 
+  \includegraphics[width=\snapsize]{snapsps/aniso-gf4go-trilinear-aniso.ps}  &
+c) & 
+  \includegraphics[width=\snapsize]{snapsps/aniso-gf4go-aniso.ps} 
+\end{tabular}
 \caption{
 \label{figbitrilinear}
-Example PFSS diagrams: a) bilinear, b), c) trilinear filtering.
+PFSS (Pixel Footprint in Screen Space) diagrams generated on a Geforce4Go 
(NV17M), showing
+different types of filtering as they actually occur on the hardware 
+(see Appendix A for how to generate such diagrams).
+The dark, orthogonal square is a single pixel, enlarged, over which the 
contributions
+from texels around it are shown by their color.
+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.
+Hardware anisotropic filtering. 
+On the same card and same texture coordinates as
+c), but with anisotropic
+filtering enabled, the PFSS diagram shows a much better 
+footprint fitting more closely around the pixel.
 }
-\end{figure}
+\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
+  XXX Feline texram talisman
 
 - 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
 
-- Graphics companies unfortunately do not provide ...
-
-
-- In this article, we argue that isotropic situations should be explicitly 
avoided
-  in 2D orthogonal rendering - better quality with aniso
-
-- For text, setting of the problem: orthogonal transformations are most 
important,
-  TrueType shows maybe not the right model but ...
-
-
-- case we consider: sharp edges, orthogonal (or nearly so) transformations, 
e.g. text
-
-- for sharp edges / small features, even under orthogonal transformations, 
trilinear bad:
-sampling at too low a resolution for much of the time!
-
-- LOD bias sharpening causes spatial and temporal aliasing (flickering)
-
-- simple solution for improving the situation in one direction: 
-  stretch the texture in one direction, squish back by texture coordinates. 
activate
-  the aniso filter. Aniso filters planned so that they don't flicker, either.
-
-
-\begin{figure}
-a)\\
-b)\\
-c)\\
-\caption{
-\label{figaniso}
-Hardware 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}
 
 
 \section{Why does stretch and squish improve image quality?}
 
+- quality of trilinear filtering result depends strongly on subpixel position
+
 \begin{figure}
-a)\\
-b)\\
+a)\\\includegraphics[width=\snapsize]{snapsps/aniso-gf4go-ortho-trilinear.ps}\\
+b)\\\includegraphics[width=\snapsize]{snapsps/aniso-gf4go-ortho-stretchsquish.ps}\\
 \caption{
 \label{figstretchsquishsamples}
-PFSS diagrams of an orthonormal rendering situation,
+PFSS diagrams of an simple 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. 
+a) Normal trilinear filtering. 
 b) Stretching the texture and squishing it allows more samples to be used
-through an anisotropic filter. The footprint in XXX direction is much closer
-to the actual pixel; there is less blur in the output.
+when using an anisotropic filter. The footprint in XXX direction is much closer
+to the actual pixel; there is less blur in the output. Here, 2x anisotropy was
+used; using more anisotropy sharpens the filter further.
 }
 \end{figure}
 
@@ -220,12 +178,17 @@
 }
 \end{table}
 
-\begin{figure}
+\def\fontexamplesize{8cm}
+\begin{figure*}
+\includegraphics[width=\fontexamplesize]{snapsps/aniso-font-trilinear.ps}
+\includegraphics[width=\fontexamplesize]{snapsps/aniso-font-lodbias.ps}
+\includegraphics[width=\fontexamplesize]{snapsps/aniso-font-horiz2.ps}
+\includegraphics[width=\fontexamplesize]{snapsps/aniso-font-vert2.ps}
 \caption{
 \label{figexamples}
 Magnified examples of text filtered using several algorithms.
 }
-\end{figure}
+\end{figure*}
 
 - comparison:
 
@@ -241,6 +204,7 @@
       NV GF FX supports that, nothing else. Others can only bias the lod so 
have to use supersampling 1 or 2x2
 
 
+
 - benefit / cost ratio analysis: how much slower than trilinear and
   how must faster than real supersampling -- does aniso filter provide
   ``optimal'' quality / cost ratio?
@@ -249,6 +213,10 @@
 
 \section{Conclusion}
 
+- In this article, we argue that isotropic situations should be explicitly 
avoided
+  in 2D orthogonal rendering - better quality with aniso
+
+
 - described how hardware implementations of anisotropic filtering can be probed
   for better understanding
 
@@ -280,13 +248,25 @@
 \appendix
 \section*{Appendix}
 
-\section{Probing hardware anisotropic filters}
+\section{Probing hardware texture filters for drawing realistic PFSS snapshots}
 \label{secprobing}
 
+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.
+
 In this Section, we 
+- Graphics companies unfortunately do not provide ...
+
+The diagrams assume a box filter for generating the mipmaps, 
+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
+
+
+- Graphics companies unfortunately do not provide ...
 
 Digit-life XXX NVIDIA, ATI patterns