\chapter{Literature Review}\label{Background}
-This chapter will \rephrase{review the literature. It will also include some figures created by us from our test programs to aid with conceptual understanding of the literature.}
+\rephrase{0. Here is a brilliant summary of the sections below}
-\rephrase{TODO: Decide exactly what figures to make, then go make them; so far I have some ideas for a few about Floating Point operations, but none about the other stuff}.
+This chapter provides an overview of relevant literature. The areas of interest can be broadly grouped into two largely seperate categories; Documents and Number Representations.
-\rephrase{TODO: Actually (re)write this entire chapter}.
-\rephrase{????: Do I really want to make this go down to} \verb/\subsubsection/
+The first half of this chapter will be devoted to documents themselves, including: the representation and rendering of low level graphics primitives, how collections of these primitives are represented in document formats, and the various standards for documents in use today.
-A paper by paper summary of the literature is also available at: \\ \url{http://szmoore.net/ipdf/documents/LiteratureNotes.pdf}.
+We will find that although there has been a great deal of research into the rendering, storing, editing, manipulation, and extension of document formats, all popular document standards are content to specify at best a single precision IEEE-754 floating point number representations.
+The research on arbitrary precision arithmetic applied to documents is very sparse; however arbitrary precision arithmetic itself is a very active field of research. Therefore, the second half of this chapter will be devoted to considering the IEEE-754 standard, its advantages and limitations, and possible alternative number representations to allow for arbitrary precision arithmetic.
-\rephrase{TODO: Actually make that readable or just remove the link}.
+In Chapter \ref{Progress}, we will discuss our findings so far with regards to arbitrary precision arithmetic applied to document formats.
-\section{Document Formats}
-Since mankind climbed down from the trees... \rephrase{plagiarism alert!}
+\pagebreak
-\subsection{Vector Graphics vs Raster Graphics}
+\section{Raster and Vector Graphics}\label{vector-vs-raster-graphics}
-Raster Graphics: Stores the exact pixels as they would appear on a device. Causes obvious issues with scaling. Lowest level representation of a document.
+\rephrase{1. Here are the fundamentals of graphics (raster and vector, rendering)}
+At a fundamental level everything that is seen on a display device is represented as either a vector or raster image. These images can be stored as stand alone documents or embedded in a much more complex document format capable of containing many other types of information.
-Vector Graphics: Stores relative position of primitives - scales better. BUT still can't scale forever. Vector Graphics must be rasterised before being drawn on most display devices.
+A raster image's structure closely matches it's representation as shown on modern display hardware; the image is represented as a grid of filled square ``pixels''. Each pixel is the same size and contains information describing its colour. This representation is simple and also well suited to storing images as produced by cameras and scanners\cite{citationneeded}.
-Vector Graphics formats may contain more information than is shown on the display device; Raster Graphics always contain as much or less pixel information than is shown.
+The drawback of raster images is that by their very nature there can only be one level of detail. Figures \ref{vector-vs-raster} and \ref{vector-vs-raster-scaled} attempt to illustrate this by comparing raster images to vector images in a similar way to Worth and Packard\cite{worth2003xr}.
-\rephrase{Captain Obvious strikes again!} \\
-Figure \ref{fox} shows an example of scaling. The top image is a vector graphics drawing which has been scaled. The bottom image was a raster image of the original drawing which has then been scaled by the same amount. Scaling in = interpolation/antialiasing/just scale the pixels depending on the viewer and scale; scaling out = blurring of pixels by averaging of neighbours. If you are viewing this document in a PDF viewer you can try it yourself! Otherwise, welcome to the 21st century.
+Consider the right side of Figure \ref{vector-vs-raster}. This is a raster image which should be recognisable as an animal defined by fairly sharp edges. Figure \ref{vector-vs-raster-scaled} shows that zooming on the animal's face causes these edges to appear jagged. There is no information in the original image as to what should be displayed at a larger size, so each square shaped pixel is simply increased in size. A blurring effect will probably be visible in most PDF viewers; the software has attempted to make the ``edge'' appear more realistic using a technique called ``antialiasing'' which averages neighbouring pixels in the original image in order to generate extra pixels in the scaled image\cite{citationneeded}.\footnote{The exact appearance of the images at different zoom levels will depend greatly on the PDF viewer or printer used to display this report. On the author's display using the Atril (1.6.0) viewer, the top images appear to be pixel perfect mirror images at a 100\% scale. In the bottom raster image, antialiasing is not applied at zoom levels above $125\%$ and the effect of scaling is quite noticable.}
+%\footnote{\noindent This behaviour may be configured in some PDF viewers (Adobe Reader) whilst others (Evince, Atril, Okular) will choose whether or not to bother with antialiasing based on the zoom level. For best results experiment with changing the zoom level in your PDF viewer.\footnotemark}\footnotetext{On the author's hardware, the animals in the vector and raster images should appear mirrored pixel for pixel; but they may vary slightly on other PDF viewers or display devices.}
+In contrast, the left sides of Figures \ref{vector-vs-raster} and \ref{vector-vs-raster-scaled} are a vector image. A vector image contains information about a number of geometric shapes. To display this image on modern display hardware, the coordinates are transformed according to the view and \emph{then} the image is converted into a raster like representation. Whilst the raster image merely appears to contain edges, the vector image actually contains information about these edges, meaning they can be displayed ``infinitely sharply'' at any level of detail\cite{citationneeded} --- or they could be if the coordinates are stored with enough precision (see Section \ref{}). Thus, vector images are well suited to high quality digital art\footnote{Figure \ref{vector-vs-raster} is not to be taken as an example of this.} and text\cite{citationneeded}.
+
+
+\rephrase{Woah, an entire page with only one citation ham fisted in after I had written the rest... and the ``actually writing it'' phase of the Lit Review is off to a great start.}
+
+\newlength\imageheight
+\newlength\imagewidth
+\settoheight\imageheight{\includegraphics{figures/fox-raster.png}}
+\settowidth\imagewidth{\includegraphics{figures/fox-raster.png}}
+
+%Height: \the\imageheight
+%Width: \the\imagewidth
+
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[scale=0.7528125]{figures/fox-vector.pdf}
+ \includegraphics[scale=0.7528125]{figures/fox-raster.png}
+ \caption{Original Vector and Raster Images}\label{vector-vs-raster}
+\end{figure} % As much as I hate to break up the party, these fit best over the page (at the moment)
\begin{figure}[H]
\centering
- \includegraphics[width=0.5\textwidth]{figures/fox.pdf}
- \includegraphics[width=0.5\textwidth]{figures/fox.png}
- \caption{Scaling of Vector and Raster Graphics}\label{fox}
+ \includegraphics[scale=0.7528125, viewport=210 85 280 150,clip, width=0.45\textwidth]{figures/fox-vector.pdf}
+ \includegraphics[scale=0.7528125, viewport=0 85 70 150,clip, width=0.45\textwidth]{figures/fox-raster.png}
+ \caption{Scaled Vector and Raster Images}\label{vector-vs-raster-scaled}
\end{figure}
-\rephrase{I am torn as to whether to use a Fox or Rabbit or Rox here}.
+\section{Rendering Vector Images}
+
+Throughout Section \ref{vector-vs-raster-graphics} we were careful to refer to ``modern'' display devices, which are raster based. It is of some historical significance that vector display devices were popular during the 70s and 80s, and so algorithms for drawing a vector image directly without rasterisation exist. An example is the shading of polygons which is somewhat more complicated on a vector display than a raster display\cite{brassel1979analgorithm, lane1983analgorithm}.
+
+All modern displays of practical interest are raster based. In this section we explore the structure of vector graphics in more detail, and how different primitives are rendered.
+
+\rephrase{After the wall of citationless text in Section \ref{vector-vs-raster-graphics} we should probably redeem ourselves a bit here}
+
+\subsection{Bezier Curves}
+
+The bezier curve is of vital importance in vector graphics.
+
+\rephrase{Things this section lacks}
+\begin{itemize}
+ \item Who came up with them (presumably it was a guy named Bezier)
+ \item Flesh out how they evolved or came into use?
+ \item Naive algorithm
+ \item De Casteljau Algorithm
+\end{itemize}
+
+Recently, Goldman presented an argument that Bezier's could be considered as fractal in nature, a fractal being the fixed point of an iterated function system\cite{goldman_thefractal}. Goldman's proof depends upon a modification to the De Casteljau Subdivision algorithm. Whilst we will not go the details of the proof, or attempt comment on its theoretical value, it is interesting to note that Goldman's algorithm is not only worse than the De Casteljau algorithm upon which it was based, but it also performs worse than a naive Bezier rendering algorithm. Figure \ref{bezier-goldman} shows our results using implementations of the various algorithms in python.
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.7\textwidth]{figures/bezier-goldman.png}
+ \caption{Performance of Bezier Subdivision Algorithms}\label{bezier-goldman}
+\end{figure}
+
+\rephrase{Does the Goldman bit need to be here? Probably NOT. Do I need to check very very carefully that I haven't made a mistake before saying this? YES. Will I have made a mistake? Probably.}
+
+
+\subsection{Shapes}
+Shapes are just bezier curves joined together.
+
+\subsubsection{Approximating a Circle Using Cubic Beziers}
+
+An example of a shape is a circle. We used some algorithm on wikipedia that I'm sure is in Literature somewhere
+\cite{citationneeded} and made a circle. It's in my magical ipython notebook with the De Casteljau stuff.
+
+\subsection{Text}
+Text is just Bezier Curves, I think we proved out point with the circle, but maybe find some papers to cite\cite{citationneeded}
+
+
+\subsection{Shading}
+
+Shading is actually extremely complicated! \cite{brassel1979analgorithm, lane1983analgorithm}
+\rephrase{Sure, but do we care enough to talk about it? We will run out of space at this rate}
+
+\subsection{Other Things}
+We don't really care about other things in this report.
+
+\rephrase{6. Sort of starts here... or at least background does}
+
+\subsection{Rendering Vector Graphics on the GPU}
+
+Traditionally, vector graphics have been rasterized by the CPU before being sent to the GPU for drawing\cite{kilgard2012gpu}. Lots of people would like to change this \cite{worth2003xr, loop2007rendering, rice2008openvg, kilgard2012gpu, green2007improved} ... \rephrase{All of these are things David found except kilgard which I thought I found and then realised David already had it :S}
+
+\rephrase{2. Here are the ways documents are structured ... we got here eventually}
+
+\section{Document Representations}
+
+\rephrase{The file format can be either human readable\footnote{For some definition of human and some definition of readable} or binary\footnote{So, our viewer is basically a DOM style but stored in a binary format}. Can also be compressed or not. Here we are interested in how the document is interpreted or traversed in order to produce graphics output.}
-\subsection{Document Format Categories}
+\subsection{Interpreted Model}
-Main reference: Pixels or Perish\cite{hayes2012pixels}
+\rephrase{Did I just invent that terminology or did I read it in a paper? Is there actually existing terminology for this that sounds similar enough to ``Document Object Model'' for me to compare them side by side?}
-\begin{enumerate}
- \item DOM - eg: HTML/XMLish - defined in terms of elements that can contain other elements
- \item Programming Language - eg: PostScript - programmer (or program) produces a program that is interpreted
- \item Combination - eg: Javascript with HTML/XML - Program is interpreted that modifies the DOM.
+\begin{itemize}
+ \item This model treats a document as the source code program which produces graphics
+ \item Arose from the desire to produce printed documents using computers (which were still limited to text only displays).
+ \item Typed by hand or (later) generated by a GUI program
+ \item PostScript --- largely supersceded by PDF on the desktop but still used by printers\footnote{Desktop pdf viewers can still cope with PS, but I wonder if a smartphone pdf viewer would implement it?}
+ \item \TeX --- Predates PostScript! {\LaTeX } is being used to create this very document and until now I didn't even have it here!
\begin{itemize}
- \item The lines are becomming increasingly blurred between 1. and 2.
- \item In the case of Javascript/HTML, a special DOM element \verb/<canvas>/ allows even lower level manipulation of graphics.
+ \item I don't really want to go down the path of investigating the billion steps involved in getting \LaTeX into an actually viewable format
+ \item There are interpreters (usually WYSIWYG editors) for \LaTeX though
+ \item Maybe if \LaTeX were more popular there would be desktop viewers that converted \LaTeX directly into graphics
\end{itemize}
-\end{enumerate}
+ \item Potential for dynamic content, interactivity; dynamic PostScript, enhanced Postscript
-Can be either human readable\footnote{For some definition of human and some definition of readable} or binary\footnote{So, our viewer is basically a DOM style but stored in a binary format}
+ \item Scientific Computing --- Mathematica, Matlab, IPython Notebook --- The document and the code that produces it are stored together
+ \item Problems with security --- Turing complete, can be exploited easily
+\end{itemize}
-\subsection{Modern Graphics Formats}
+\subsection{Crippled Interpreted Model}
-PostScript: Not actually widely used now, but PDF is basically the same thing.
-PDF: A way for adobe to make money
-SVG: Based on the DOM model, vector format
-BMP,PNG,GIF: Are these even worth mentioning?
+\rephrase{I'm pretty sure I made that one up}
-HTML: With the evolution of JavaScript and CSS, this has actually become a competitive document format; it can display much more complex dynamic content than eg: PDF.
+\begin{itemize}
+ \item PDF is PostScript but without the Turing Completeness
+ \item Solves security issues, more efficient
+\end{itemize}
-Web based documents still suffer from precision issues (JavaScript is notorious for its representation of everything, even integers, as floats, so you get rounding errors even with integer maths), and it also has other limitations (requires reasonably skilled programmer to create Javascript and/or a disgusting GUI tool that auto generates 10000 lines to display a button (I have seen one of these)). \rephrase{Hate on javascript a bit less maybe.}
+\subsection{Document Object Model}
-\subsection{Precision Limitations}
+\begin{itemize}
+ \item DOM = Tree of nodes; node may have attributes, children, data
+ \item XML (SGML) is the standard language used to represent documents in the DOM
+ \item XML is plain text
+ \item SVG is a standard for a vector graphics language conforming to XML (ie: a DOM format)
+ \item CSS style sheets represent more complicated styling on objects in the DOM
+\end{itemize}
+
+\subsection{Blurring the Line --- Javascript}
+
+\begin{itemize}
+ \item The document is expressed in DOM format using XML/HTML/SVG
+ \item A Javascript program is run which can modify the DOM
+ \item At a high level this may be simply changing attributes of elements dynamically
+ \item For low level control there is canvas2D and even WebGL which gives direct access to OpenGL functions
+ \item Javascript can be used to make a HTML/SVG interactive
+ \begin{itemize}
+ \item Overlooking the fact that the SVG standard already allows for interactive elements...
+ \end{itemize}
+ \item Javascript is now becoming used even in desktop environments and programs (Windows 8, GNOME 3, Cinnamon, Game Maker Studio) ({\bf shudder})
+ \item There are also a range of papers about including Javascript in PDF ``Pixels or Perish'' being the only one we have actually read\cite{hayes2012pixels}
+ \begin{itemize}
+ \item I have no idea how this works; PDF is based on PostScript... it seems very circular to be using a programming language to modify a document that is modelled on being a (non turing complete) program
+ \item This is yet more proof that people will converge towards solutions that ``work'' rather than those that are optimal or elegant
+ \item I guess it's too much effort to make HTML look like PDF (or vice versa) so we could phase one out
+ \end{itemize}
+\end{itemize}
+
+\subsection{Why do we still use static PDFs}
+
+Despite their limitations, we still use static, boring old PDFs. Particularly in scientific communication.
+\begin{itemize}
+ \item They are portable; you can write an amazing document in Mathematica/Matlab but it
+ \item Scientific journals would need to adapt to other formats and this is not worth the effort
+ \item No network connection is required to view a PDF (although DRM might change this?)
+ \item All rescources are stored in a single file; a website is stored accross many seperate files (call this a ``distributed'' document format?)
+ \item You can create PDFs easily using desktop processing WYSIWYG editors; WYSIWYG editors for web based documents are worthless due to the more complex content
+ \item Until Javascript becomes part of the PDF standard, including Javascript in PDF documents will not become widespread
+ \item Once you complicate a PDF by adding Javascript, it becomes more complicated to create; it is simply easier to use a series of static figures than to embed a shader in your document. Even for people that know WebGL.
+\end{itemize}
+
+\rephrase{3. Here are the ways document standards specify precision (or don't)}
+
+\section{Precision in Modern Document Formats}
+
+\rephrase{All the above is very interesting and provides important context, but it is not actually directly related to the problem of infinite precision which we are going to try and solve. Sorry to make you read it all.}
+
+
+
+\begin{itemize}
+ \item Implementations of PostScript and PDF must by definition restrict themselves to IEEE binary32 ``single precision''\footnote{The original IEEE-754 defined single, double and extended precisions; in the revision these were renamed to binary32, binary64 and binary128 to explicitly state the base and number of bits}
+ floating point number representations in order to conform to the standards\cite{plrm, pdfref17}.
+ \item Implementations of SVG are by definition required to use IEEE binary32 as a {\bf minimum}. ``High Quality'' SVG viewers are required to use at least IEEE binary64.\cite{svg2011-1.1}
+ \item Numerical computation packages such as Mathematica and Maple use arbitrary precision floats
+ \begin{itemize}
+ \item Mathematica is not open source which is an issue when publishing scientific research (because people who do not fork out money for Mathematica cannot verify results)
+ \item What about Maple? \cite{HFP} and \cite{fousse2007mpfr} both mention it being buggy.
+ \item Octave and Matlab use fixed precision doubles
+ \end{itemize}
+\end{itemize}
+
+The use of IEEE binary32 floats in the PostScript and PDF standards is not surprising if we consider that these documents are oriented towards representing static pages. They don't actually need higher precision to do this; 32 bits is more than sufficient for A4 paper.
+
+\rephrase{4. Here is IEEE-754 which is what these standards use}
\section{Representation of Numbers}
-Although this project has been motivated by a desire for more flexible document formats, the fundamental source of limited precision in vector document formats such as PDF and PostScript is the use of floating point numbers to represent the coordinates of vertex positions. In particular, implementations of PostScript and PDF must by definition restrict themselves to IEEE binary32 ``single precision'' floating point number representations in order to conform to the standards\cite{plrm, pdfref17}.
+Although this project has been motivated by a desire for more flexible document formats, the fundamental source of limited precision in vector document formats is the restriction to IEEE floating point numbers for representation of coordinates.
+
+Whilst David Gow will be focusing on structures \rephrase{and the use of multiple coordinate systems} to represent a document so as to avoid or reduce these limitations\cite{proposalGow}, the focus of our own research will be \rephrase{increased precision in the representation of real numbers so as to get away with using a single global coordinate system}.
-Whilst David Gow will be focusing on how to structure a document format so as to avoid or reduce these limitations\cite{proposalGow}, the focus of our own research will be \rephrase{NUMBERS}.
+\subsection{The IEEE Standard}
\subsection{Floating Point Number Representations}
\rephrase{Aside: Are decimal representations for a document format eg: CAD also useful because you can then use metric coordinate systems?}
+
\subsubsection{Precision}
The floats map an infinite set of real numbers onto a discrete set of representations.
\rephrase{Even though that paper that claims double is the best you will ever need because the error can be as much as the size of a bacterium relative to the distance to the moon}\cite{} \rephrase{there are many cases where increased number of bits will not save you}.\cite{HFP}
+\rephrase{5. Here are limitations of IEEE-754 floating point numbers on compatible hardware}
+
+\subsection{Limitations Imposed By CPU}
+
+CPU's are restricted in their representation of floating point numbers by the IEEE standard.
+
+
+
+\subsection{Limitations Imposed By Graphics APIs and/or GPUs}
+
+Traditionally algorithms for drawing vector graphics are performed on the CPU; the image is rasterised and then sent to the GPU for rendering\cite{}. Recently there has been a great deal of literature relating to implementation of algorithms such as bezier curve rendering\cite{} or shading\cite{} on the GPU. As it seems the trend is to move towards GPU
+
+\rephrase{6. Here are ways GPU might not be IEEE-754 --- This goes *somewhere* in here but not sure yet}
+
+\begin{itemize}
+ \item Internal representations are GPU dependent and may not match IEEE\cite{hillesland2004paranoia}
+ \item OpenGL standards specify: binary16, binary32, binary64
+ \item OpenVG aims to become a standard API for SVG viewers but the API only uses binary32 and hardware implementations may use less than this internally\cite{rice2008openvg}
+ \item It seems that IEEE has not been entirely successful; although all modern CPUs and GPUs are able to read and write IEEE floating point types, many do not conform to the IEEE standard in how they represent floating point numbers internally.
+\end{itemize}
+
+
+
+\rephrase{7. Sod all that, let's just use an arbitrary precision library (AND THUS WE FINALLY GET TO THE POINT)}
+
\subsection{Alternate Number Representations}
\rephrase{They exist\cite{HFP}}.
+Do it all using MFPR\cite{}, she'll be right.
+
+\rephrase{8. Here is a brilliant summary of sections 7- above}
+
+Dear reader, thankyou for your persistance in reading this mangled excuse for a Literature Review.
+Hopefully we have brought together the radically different areas of interest together in some sort of coherant fashion.
+In the next chapter we will talk about how we have succeeded in rendering a rectangle. It will be fun. I am looking forward to it.
git.ucc.asn.au / ipdf / sam.git / blobdiff
UCC git Repository :: git.ucc.asn.au