[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gzz-commits] manuscripts/AniFont anifont.tex probe.mp
From: |
Tuomas J. Lukka |
Subject: |
[Gzz-commits] manuscripts/AniFont anifont.tex probe.mp |
Date: |
Fri, 10 Oct 2003 10:05:38 -0400 |
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;
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Gzz-commits] manuscripts/AniFont anifont.tex probe.mp,
Tuomas J. Lukka <=