David's lit notes, LaTeXiFiEd

diff --git a/LiteratureNotes.pdf b/LiteratureNotes.pdf
index 8760bb2..f5b15bd 100644 (file)
Binary files a/LiteratureNotes.pdf and b/LiteratureNotes.pdf differ

diff --git a/LiteratureNotes.tex b/LiteratureNotes.tex
index 6dfa524..39cb258 100644 (file)
--- a/LiteratureNotes.tex
+++ b/LiteratureNotes.tex
@@ -258,6 +258,127 @@ Proves with maths, that rounding errors mean that you need at least $q$ bits for
 \end{itemize}
 
 
+%%%%
+% David's Stuff
+%%%%
+\section{Compositing Digital Images\cite{porter1984compositing}}
+
+
+
+Perter and Duff's classic paper "Compositing Digital Images" lays the
+foundation for digital compositing today. By providing an "alpha channel,"
+images of arbitrary shapes — and images with soft edges or sub-pixel coverage
+information — can be overlayed digitally, allowing separate objects to be
+rasterized separately without a loss in quality.
+
+Pixels in digital images are usually represented as 3-tuples containing
+(red component, green component, blue component). Nominally these values are in
+the [0-1] range. In the Porter-Duff paper, pixels are stored as $(R,G,B,\alpha)$
+4-tuples, where alpha is the fractional coverage of each pixel. If the image
+only covers half of a given pixel, for example, its alpha value would be 0.5.
+
+To improve compositing performance, albeit at a possible loss of precision in
+some implementations, the red, green and blue channels are premultiplied by the
+alpha channel. This also simplifies the resulting arithmetic by having the
+colour channels and alpha channels use the same compositing equations.
+
+Several binary compositing operations are defined:
+\begin{itemize}
+\item over
+\item in
+\item out
+\item atop
+\item xor
+\item plus
+\end{itemize}
+
+The paper further provides some additional operations for implementing fades and
+dissolves, as well as for changing the opacity of individual elements in a
+scene.
+
+The method outlined in this paper is still the standard system for compositing
+and is implemented almost exactly by modern graphics APIs such as \texttt{OpenGL}. It is
+all but guaranteed that this is the method we will be using for compositing
+document elements in our project.
+
+\section{Bresenham's Algorithm: Algorithm for computer control of a digital plotter\cite{bresenham1965algorithm}}
+Bresenham's line drawing algorithm is a fast, high quality line rasterization
+algorithm which is still the basis for most (aliased) line drawing today. The
+paper, while originally written to describe how to control a particular plotter,
+is uniquely suited to rasterizing lines for display on a pixel grid.
+
+Lines drawn with Bresenham's algorithm must begin and end at integer pixel
+coordinates, though one can round or truncate the fractional part. In order to
+avoid multiplication or division in the algorithm's inner loop, 
+
+The algorithm works by scanning along the long axis of the line, moving along
+the short axis when the error along that axis exceeds 0.5px. Because error
+accumulates linearly, this can be achieved by simply adding the per-pixel
+error (equal to (short axis/long axis)) until it exceeds 0.5, then incrementing
+the position along the short axis and subtracting 1 from the error accumulator.
+
+As this requires nothing but addition, it is very fast, particularly on the
+older CPUs used in Bresenham's time. Modern graphics systems will often use Wu's
+line-drawing algorithm instead, as it produces antialiased lines, taking
+sub-pixel coverage into account. Bresenham himself extended this algorithm to
+produce Bresenham's circle algorithm. The principles behind the algorithm have
+also been used to rasterize other shapes, including B\'{e}zier curves.
+
+\section{Quad Trees: A Data Structure for Retrieval on Composite Keys\cite{finkel1974quad}}
+
+This paper introduces the ``quadtree'' spatial data structure. The quadtree structure is
+a search tree in which every node has four children representing the north-east, north-west,
+south-east and south-west quadrants of its space.
+
+\section{Xr: Cross-device Rendering for Vector Graphics\cite{worth2003xr}}
+
+Xr (now known as Cairo) is an implementation of the PDF v1.4 rendering model,
+independent of the PDF or PostScript file formats, and is now widely used
+as a rendering API. In this paper, Worth and Packard describe the PDF v1.4 rendering
+model, and their PostScript-derived API for it.
+
+The PDF v1.4 rendering model is based on the original PostScript model, based around
+a set of \emph{paths} (and other objects, such as raster images) each made up of lines
+and B\'{e}zier curves, which are transformed by the ``Current Transformation Matrix.''
+Paths can be \emph{filled} in a number of ways, allowing for different handling of self-intersecting
+paths, or can have their outlines \emph{stroked}.
+Furthermore, paths can be painted with RGB colours and/or patterns derived from either
+previously rendered objects or external raster images.
+PDF v1.4 extends this to provide, amongst other features, support for layering paths and
+objects using Porter-Duff compositing\cite{porter1984compositing}, giving each painted path
+the option of having an $\alpha$ value and a choice of any of the Porter-Duff compositing
+methods.
+
+The Cairo library approximates the rendering of some objects (particularly curved objects
+such as splines) with a set of polygons. An \texttt{XrSetTolerance} function allows the user
+of the library to set an upper bound on the approximation error in fractions of device pixels,
+providing a trade-off between rendering quality and performance. The library developers found
+that setting the tolerance to greater than $0.1$ device pixels resulted in errors visible to the
+user.
+
+\section{Glitz: Hardware Accelerated Image Compositing using OpenGL\cite{nilsson2004glitz}}
+
+This paper describes the implementation of an \texttt{OpenGL} based rendering backend for
+the \texttt{Cairo} library. 
+
+The paper describes how OpenGL's Porter-Duff compositing is easily suited to the Cairo/PDF v1.4
+rendering model. Similarly, traditional OpenGL (pre-version 3.0 core) support a matrix stack
+of the same form as Cairo.
+
+The ``Glitz'' backend will emulate support for tiled, non-power-of-two patterns/textures if
+the hardware does not support it.
+
+Glitz can render both triangles and trapezoids (which are formed from pairs of triangles).
+However, it cannot guarantee that the rasterization is pixel-precise, as OpenGL does not proveide
+this consistently.
+
+Glitz also supports multi-sample anti-aliasing, convolution filters for raster image reads (implemented
+with shaders).
+
+Performance was much improved over the software rasterization and over XRender accellerated rendering
+on all except nVidia hardware. However, nVidia's XRender implementation did slow down significantly when
+some transformations were applied.
+
 
 
 \pagebreak

diff --git a/ProjectProposalDavid.pdf b/ProjectProposalDavid.pdf
index 6c3f16e..f2ece22 100644 (file)
Binary files a/ProjectProposalDavid.pdf and b/ProjectProposalDavid.pdf differ

diff --git a/ProjectProposalSam.pdf b/ProjectProposalSam.pdf
index 7cc5d2f..0549d9a 100644 (file)
Binary files a/ProjectProposalSam.pdf and b/ProjectProposalSam.pdf differ

diff --git a/papers.bib b/papers.bib
index c4a857c..e2aa0e9 100644 (file)
--- a/papers.bib
+++ b/papers.bib
@@ -16,6 +16,39 @@
   year={2006}
 }
 
+%%%%%%%%%%%%%%%%%%%%%%%%
+% Basic Rendering Theory
+%%%%%%%%%%%%%%%%%%%%%%%%
+
+%Porter-Duff compositing.
+% Keith Packard has a really nice PDF version of this.
+@inproceedings{porter1984compositing,
+  title={Compositing digital images},
+  author={Porter, Thomas and Duff, Tom},
+  booktitle={ACM Siggraph Computer Graphics},
+  volume={18},
+  number={3},
+  pages={253--259},
+  year={1984},
+  organization={ACM}
+}
+
+%Bresenham's Line Drawing Algorithm
+% See Michael Abrash's Graphics Programming Black Book for a
+% much better guide to implementing this (at least on the 486)
+@article{bresenham1965algorithm,
+  title={Algorithm for computer control of a digital plotter},
+  author={Bresenham, Jack E},
+  journal={IBM Systems journal},
+  volume={4},
+  number={1},
+  pages={25--30},
+  year={1965},
+  publisher={IBM Corp.}
+}
+
+
+
 %%%%%%%%%%%%%%%%%%%%%%%
 % Floating-pt Precision
 %%%%%%%%%%%%%%%%%%%%%%%
@@ -209,6 +242,21 @@ Goldberg:1991:CSK:103162.103163,
   organization={IEEE}
 }
 
+%%%%%%%%%%%%%%%%%
+% Quadtrees
+%%%%%%%%%%%%%%%%%
+@article{finkel1974quad,
+  title={Quad trees a data structure for retrieval on composite keys},
+  author={Finkel, Raphael A. and Bentley, Jon Louis},
+  journal={Acta informatica},
+  volume={4},
+  number={1},
+  pages={1--9},
+  year={1974},
+  publisher={Springer}
+}
+
+
 % Basic overview of PDF and how it is awesome.
 % This doesn't seem like a major revelation for 2002
 @article{cheng2002portable,

diff --git a/references/finkle1974quad.pdf b/references/finkle1974quad.pdf
new file mode 100644 (file)
index 0000000..d3ae073
Binary files /dev/null and b/references/finkle1974quad.pdf differ