[Gzz-commits] manuscripts/AniFont anifont.tex probe.mp

[Tuomas J. Lukka]

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

Modified files:
        AniFont        : anifont.tex probe.mp 

Log message:
        Arch sync

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/manuscripts/AniFont/anifont.tex.diff?tr1=1.7&tr2=1.8&r1=text&r2=text
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/manuscripts/AniFont/probe.mp.diff?tr1=1.4&tr2=1.5&r1=text&r2=text

Patches:
Index: manuscripts/AniFont/anifont.tex
diff -u manuscripts/AniFont/anifont.tex:1.7 manuscripts/AniFont/anifont.tex:1.8
--- manuscripts/AniFont/anifont.tex:1.7 Thu Oct  2 09:53:27 2003
+++ manuscripts/AniFont/anifont.tex     Fri Oct 10 10:05:37 2003
@@ -3,8 +3,9 @@
 \usepackage{beton}
 \begin{document}
 
-\title{Trick: using harware anisotropic filters in orthogonal contexts to 
improve quality}
+\title{Harware anisotropic filters: Probing the Implementations and Why You 
Should Make 2D Isotropic Situations Anisotropic}
 
+\author{Tuomas J. Lukka and Janne Kujala}
 \maketitle
 
 \begin{abstract}
@@ -15,77 +16,108 @@
 
 Recently, ...
 
-- Trilinear filtering was designed to avoid temporal and spatial aliasing
+- off-line rendering: EWA XXXREF
+
+- Trilinear/bilinear (mipmap) filtering was designed to avoid temporal and 
spatial aliasing XXXREF
 
 - 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).
+
+- 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
+
+
+- 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 ...
+  TrueType shows maybe not the right model but ...
+
 
+The rest of the article is organized as follows.
 
-\section{Hardware anisotropic filters}
+\section{Probing hardware anisotropic filters}
+\label{secprobing}
+
+In this Section, we 
 
 This seems to be a well-known technique that has not so far been published
 anywhere
 
-used more commonly in showing FSAA patterns
-
 Digit-life XXX NVIDIA, ATI patterns
 
-Graphics companies unfortunately do not provide ...
+- for careful work, you'll want to know what your driver is doing
 
 \begin{figure*}
 a) \includegraphics[width=5cm]{probe.2}
-c)\\
-b)\\\includegraphics[width=15cm]{probe.1}
+b) \includegraphics[width=10cm]{probe.1}
+c)
 \caption{
 \label{figanisoprobe}
-a) The probe textures for the three smallest mipmap levels.
-Each texture has a single white texel at a single mipmap level.
-b) The pixel-sized quads and their texture coordinates for
-probing the sampling of the third and second smallest mipmap levels ...
-b) An example image produced by such quads: how the XXX card 
+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*}
 
-- ASSUMPTIONS: pixel/texel translation invariance, both in screen and 
texture-space,
-  driver not detecting software and applying different rules, driver
-  not changing algorithm for screenshot images / moving images, ...
+- difficulty in probing hardware: each free variable grows number of probes to 
make
+  exponentially - have to make as strict assumptions as possible
 
-- define separate texture $T_n$ for each mipmap level, with exactly one light
-  texel at that mipmap level, all other texels and mipmap levels middle gray(!)
-  (we define $T_n$ to be the 1x1 texture, $T_{n-1}$ to be the 2x2 texture etc.
+- 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, 
+  e.g. NV patent describing using lower mipmap level!
+  pixel translation invariance, in screen space.
+
+- define separate texture $T_{(k),x,y}$ for each texel of each
+  mipmap level, with exactly one light
+  texel at the point $(x,y)$ of that mipmap level, all other texels and mipmap 
levels middle gray
+  (we define level $(n)$ to be the 1x1 texture, ${n-1}$ to be the 2x2 texture 
etc.
   Non-square mipmap hierarchies are a simple generalization)
     
     - gray so we see also if there are negative weights in the filter!
 
-    - set to wrap so no border / edge effects; to see these properly, 
-      more textures are needed
-
-- select the texture coordinates for a single-pixel quad where you want
-  to see contributions: $(s_0, t_0), (s_1, t_1), (s_2, t_2), (s_3, t_3)$.
+- select the texture coordinates for a single-pixel quad for which you want
+  to see contributions.
   In reality, only a triangle gets used so these should be linearly obtained
   from three coordinates but it's still easier for a human to understand these
-  as quads
+  as quads... 
 
-- For each miplevel texture, render a one-pixel quad for each texel at that 
level,
-  with texture coordinates shifted by multiples of $1/s_n$ where $s_n$ is the
-  length of the mipmap side on level $n$.
+- For each mipmap level texel, render a one-pixel quad,
+  with the same texture coordinates and 
 
 - Resulting image gives contribution from each texel on a mipmap level
   to the final image, PROVIDED ASSUMPTIONS HOLD.
 
+- the single-texture quads (or values read from screen) can then be used
+  in other visualizations
 
 - utility in our free software OpenGL libvob system
 
-- relatively simple generalization to using projective coordinates
-
-- problem: image-sensitive filters
 
-    - need to use linear algebra to find out functions by perturbing images
 
-- nonlinearities - to our knowledge none yet
+A similar technique appears to be used more commonly used for probing hardware
+antialiasing patterns, (XXX should we?). 
 
 - assumptions about the contents of the mipmap levels
 
@@ -95,6 +127,7 @@
       as the contribution of four texels on a higher mimap level as per
       the assumption of generating the mipmap levels in the usual way
 
+
 \section{Surprise: stretch-squish can yield better images in orthogonal 
transformations}
 
 - case we consider: sharp edges, orthogonal (or nearly so) transformations, 
e.g. text
@@ -105,8 +138,8 @@
 - 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. 
This activates
-  the aniso filter
+  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)\\
@@ -183,6 +216,9 @@
   should darken / sharpen the mipmap levels in combination
 
 - LCD-text
+
+- due to the driver situation (ATI's Linux drivers still weak) we haven't been 
able to 
+  test ATI cards ...
 
 
 \section{Acknowledgments}
Index: manuscripts/AniFont/probe.mp
diff -u manuscripts/AniFont/probe.mp:1.4 manuscripts/AniFont/probe.mp:1.5
--- manuscripts/AniFont/probe.mp:1.4    Tue Sep 30 07:20:56 2003
+++ manuscripts/AniFont/probe.mp        Fri Oct 10 10:05:37 2003
@@ -15,57 +15,37 @@
     (gridp(x,y) + 45*(s,t))
 enddef;
 
-vardef Tlev(expr lev) =
+vardef Tlev(expr lev, lightat) =
+    string texstr;
+    texstr := "$T_{(";
     if lev = 0:
-       TEX( "$T_n$")
+       texstr := texstr & "n";
     else:
-       TEX( "$T_{n-"&(decimal lev)&"}$")
+       texstr := texstr & "n-"&(decimal lev);
     fi
+    texstr := texstr & "),\," & (decimal xpart lightat) & ",\," & (decimal 
ypart lightat) & "}$";
+    TEX( texstr )
 enddef;
 
 cornermeas = 5pt;
 
 def stlabel(expr ind, x, y, side) =
-    (TEX("$\eqalign{(s_"&(decimal ind)&"0 + " & (decimal x) & "/" & (decimal 
side) &",\cr " &
-       "t_"&(decimal ind)&"0 + " & (decimal y) & "/" & (decimal side) &")}$" 
+    (TEX("$\eqalign{(s_"&(decimal ind)&" + " & (decimal x) & "/" & (decimal 
side) &",\cr " &
+       "t_"&(decimal ind)&" + " & (decimal y) & "/" & (decimal side) &")}$" 
     ) scaled .8)
 enddef;
 
 vardef drawlev(expr lev, side, xoffs, yoffs) =
     for x := 0 upto side-1:
        for y := 0 upto side-1:
-           addto currentpicture also Tlev(lev) shifted gridp(xoffs+x,yoffs+y);
-
-           draw
-               gridc(xoffs+x,yoffs+y, -1, -1) --
-               gridc(xoffs+x,yoffs+y, -1,  1) --
-               gridc(xoffs+x,yoffs+y,  1,  1) --
-               gridc(xoffs+x,yoffs+y,  1, -1) -- cycle;
-
-           dotlabel.urt(
-               stlabel(0, x, y, side),
-               gridc(xoffs+x,yoffs+y, -1, -1) 
-               );
-           dotlabel.ulft(
-               stlabel(1, x+1, y, side),
-               gridc(xoffs+x,yoffs+y, 1, -1) 
-               );
-           dotlabel.lrt(
-               stlabel(2, x, y+1, side),
-               gridc(xoffs+x,yoffs+y, -1, 1) 
-               );
-           dotlabel.llft(
-               stlabel(3, x+1, y+1, side),
-               gridc(xoffs+x,yoffs+y, 1, 1) 
-               );
-           
+           label(Tlev(lev, (x, y)) scaled 2, gridp(xoffs+x,yoffs+y));
        endfor;
     endfor;
 enddef;
 
 beginfig(1);
 
-maxx = 7;
+maxx = 9;
 
 for x := 0 upto maxx:
     draw gridedge(x,0) -- gridedge(x,4);
@@ -77,21 +57,21 @@
        
 drawlev(2, 4, 0, 0);
 drawlev(1, 2, 5, 0);
-% drawlev(0, 1, 8, 0);
+drawlev(0, 1, 8, 0);
 
 endfig;
 
 size = 15pt;
 
-def drawgrid(expr x, y, side, light) =
+def drawgrid(expr x, y, side, light, lightat) =
 
     fill (x,y)--(x+side*size,y)--
            (x+side*size,y+side*size)--(x,y+side*size)--cycle
                withcolor 0.5 * white;
 
     if light:
-       fill (x,y)--(x+size,y)--
-               (x+size,y+size)--(x,y+size)--cycle
+       fill ((x,y)--(x+size,y)--
+               (x+size,y+size)--(x,y+size)--cycle) shifted (lightat * size)
                    withcolor  white;
     fi;
     
@@ -104,20 +84,20 @@
 
 enddef;
 
-vardef drawmipmaps(expr x, y, lightlevel) =
+vardef drawmipmaps(expr x, y, lightlevel, lightat) =
 
-    label.top(Tlev(lightlevel), (x + 2*size,y + 2*size));
-    drawgrid(x, y, 1, lightlevel=0);
-    drawgrid(x, y - 3*size, 2, lightlevel=1);
-    drawgrid(x, y - 8*size, 4, lightlevel=2);
+    label.top(Tlev(lightlevel,lightat), (x + 2*size,y + 2*size));
+    drawgrid(x, y, 1, lightlevel=0, lightat);
+    drawgrid(x, y - 3*size, 2, lightlevel=1, lightat);
+    drawgrid(x, y - 8*size, 4, lightlevel=2, lightat);
     
 enddef;
 
 beginfig(2);
 
-    drawmipmaps(0,0,2);
-    drawmipmaps(5*size,0,1);
-    drawmipmaps(10*size,0,0);
+    drawmipmaps(0,0,0,  (0,0));
+    drawmipmaps(5.5*size,0,1,  (1,0));
+    drawmipmaps(11*size,0,2, (1,2));
 
 
 endfig;