diff options
author | Norbert Preining <norbert@preining.info> | 2019-09-02 13:46:59 +0900 |
---|---|---|
committer | Norbert Preining <norbert@preining.info> | 2019-09-02 13:46:59 +0900 |
commit | e0c6872cf40896c7be36b11dcc744620f10adf1d (patch) | |
tree | 60335e10d2f4354b0674ec22d7b53f0f8abee672 /fonts/halftone/pix.tex |
Initial commit
Diffstat (limited to 'fonts/halftone/pix.tex')
-rw-r--r-- | fonts/halftone/pix.tex | 326 |
1 files changed, 326 insertions, 0 deletions
diff --git a/fonts/halftone/pix.tex b/fonts/halftone/pix.tex new file mode 100644 index 0000000000..5e0a469535 --- /dev/null +++ b/fonts/halftone/pix.tex @@ -0,0 +1,326 @@ +% --- ------------------------------------------------------------------ +% --- Halftone Output from TeX. +% --- ------------------------------------------------------------------ + +% --- This file should be formatted by LaTeX and printed with an half an +% --- inch of top and an inch of left margin. The page layout should be +% --- compatible with TUGboat. + + +% --- ------------------------------------------------------------------ +% --- Macros and mnemonics. +% --- ------------------------------------------------------------------ + +\def\|#1|{{\tt#1}} % teletype text +\def\cmd#1{{\tt\char92#1}} % for `\command' +\def\fig#1{Fig.~#1} % references to figures + +\def\mc{\small} % medium caps + +\def\ASCII{{\mc ASCII}} +\def\bigTeX{{big \large\TeX}} +\def\FTN{{\mc FORTRAN}} + +\def\VAX{\leavevmode\hbox{V\kern-.12em A\kern-.1em X}} +\def\VMS{\leavevmode\hbox{V\kern-.06em MS}} + +% --- ------------------------------------------------------------------ +% --- Document style. +% --- ------------------------------------------------------------------ + +\nofiles +\font\halftone=halftone % the halftone font + +\documentstyle[tugboat]{article} + +% --- ------------------------------------------------------------------ +% --- The title. +% --- ------------------------------------------------------------------ + +\title{Halftone Output from \TeX} +\author{Adrian F. Clark} + +% --- ------------------------------------------------------------------ +% --- The article itself. +% --- ------------------------------------------------------------------ + +\begin{document} + \maketitle + +\noindent Don Knuth's article in \TUB\ volume~8 number~2 described the +development of a number of fonts which allow halftone +output---pictures---to be incorporated into \TeX\ documents. This +article chronicles the author's experiments into halftone production on +a particular computer/laser printer combination, \VAX/\VMS\ and the +LN03. It is important to understand that the picture is actually {\em +typeset,\/} not just inserted into the final output by some +printer-specific \cmd{special} command; the following results can, in +principle, be achieved on {\em any\/} output device using a perfectly +normal implementation of \TeX. + +In the image processing field, where the author works, technical reports +are invariably crammed with halftone output. The conventional method of +reproducing pictures is photographically. This is slow and +expensive, particularly for internal reports with small distributions. +Moreover, unless great care is taken over the photographs---using a +flat-screen {\mc CRT}, calibrating films, standardising the processing, +and so on---much of the visual impact can be lost. Hence, the +possibility of incorporating imagery into \TeX\ document without +recourse to a dark room is very attractive. + +A great deal of work has been carried out into the properties of the human eye. +One result is that the eye is only really capable of distinguishing about +64~grey levels, although it is very good at detecting boundaries between +regions of slightly differing grey level (see, for example, {\sl ``Digital +Image Processing''\/} by R.~C.~Gonzalez and P.~Wintz, published by +Addison-Wesley in 1977). Another result is that the eye is much more sensitive +to boundaries in dark regions than in light regions. + +The halftone font used here is more or less the same as the `double-dot' +font described by Knuth. It has some 65~different grey levels, +represented by the \ASCII\ characters `{\tt 0}' (white) to `{\tt p}' +(black). In principle, all one needs to do is to convert the grey +levels of the individual pixels (``picture elements'') of an image +to the appropriate characters of the halftone font and sprinkle in +a few \TeX\ commands to ensure that the lines of the image are lined +up in the output. + +The only minor complication is that this sequence of characters includes +`\verb"\"', `\verb"^"' and `\verb"_"', which have special meanings to \TeX. +These must be treated specially. Knuth's approach was to delimit the picture +data between macros, \cmd{beginhalftone} and \cmd{endhalftone} which disable +the special characters in a similar way to the `verbatim' macros in Appendix~E +of {\sl ``The \TeX book''.\/} The approach developed by the author is much less +elegant and builds larger disc files, but does not require special-purpose +macros. + +Each line of the image is built up as a single \cmd{hbox}. These +lines are stacked into a \cmd{vbox}, with the inter-line skip turned +off. Finally, the \cmd{vbox} is enclosed in another \cmd{hbox}, which makes +it easier to handle the picture in constructs such as +\cmd{centerline}. The scheme can be summarised as: + +\begin{verbatim} +\hbox{ \vbox{ \halftone + \offinterlineskip + \hbox{...} + ... + \hbox{...} +}} +\end{verbatim} + +\noindent The \cmd{halftone} command is used to select the halftone +font, which would be loaded with a command such as + +\begin{verbatim} +\font\halftone=hf300 +\end{verbatim} + +\noindent assuming the {\mc TFM} file is called {\tt HF300.TFM}. + +A \FTN\ \|SUBROUTINE|, \|TEXPIC|, was written to output images to files +in this format. The image is represented as a \|REAL| array dimensioned +as \|(M,N)|, where \|M| is the number of pixels per line and \|N| the +number of lines. (The use of a \|REAL| array to hold data which are +usually 8-bit may seem a little strange, but this representation has +many advantages---for example, when Fourier transforming an image.) + +Since we would normally like our pictures to have the best contrast, +\|TEXPIC| scans through the image to find its minimum and maximum, then +scales the output to make full use of the grey levels in the halftone +font. For most purposes, a single + +\begin{verbatim} + CALL TEXPIC( PIC, M, N, FN ) +\end{verbatim} + +\noindent is sufficient. (\|FN| is a \|CHARACTER| variable or quoted +string holding the output filename.) + +Of course, there are occasions when we would like to compare pictures, +so fixing the contrast is sometimes desirable; hence, \|TEXPIC| has +associated routines to fix the range of intensities (\|ZRANGE|) and +re-select automatic intensity scaling (\|ZAUTO|), which must be invoked +before \|TEXPIC| to have an effect. Similarly, \|TEXPIC| can plot +negative pictures as well as positive ones: \|DONEG| tells it to output +subsequent pictures as negatives and \|DOPOS| returns it to the default +state. + +Inserting the picture into a document prepared with plain \TeX\ is +quite simple, using commands to generate a `float', such as + +\begin{verbatim} +\midinsert + \centerline{\input picture} +\endinsert +\end{verbatim} + +\noindent assuming the picture is in the file {\tt PICTURE.TEX}. +This command sequence should be typed between paragraphs, when \TeX\ +is in `vertical mode'. To draw a border around the picture, as for +the examples presented here, one would define a macro \cmd{border} + +\begin{verbatim} +\def\border#1{\vbox{\hrule\hbox{ + \vrule\kern3pt\vbox{\kern3pt#1 + \kern3pt}\kern3pt\vrule}\hrule}} +\end{verbatim} + +\noindent The picture would then be set with + +\begin{verbatim} +\centerline{\border{\input picture}} +\end{verbatim} + +The procedure with \LaTeX\ is somewhat different. The most sensible +approach is to use the {\tt figure} environment ({\em not\/} the {\tt +picture} environment) + +\begin{verbatim} +\begin{figure} + \centering + \mbox{\input picture\relax} + \caption{...} +\end{figure} +\end{verbatim} + +\noindent This generates a `floating' figure, which usually surfaces at +the top of the next page of output. The \cmd{relax} following the +filename in the \cmd{mbox} command ensures that \LaTeX\ knows where the +filename ends. To draw a border around the picture, replace the +\cmd{mbox} with a \cmd{fbox}. + +It is traditional to test out new image processing techniques on the +`girl' picture from the image database of the University of Southern +California's Signal and Image Processing Institute. She is shown +in \fig{1} ($64 \times 64$ pixels). The output was plotted on a standard +{\tt LN03} laser printer using version~10 of Flavio Rose's {\tt +DVI2LN3}. For those unfamiliar with the {\tt LN03}, it is a 300~dpi, +white-writing laser printer based a Ricoh mechanism, supporting the +down-loading of fonts into on-board and plug-in RAM cartridges. The +quality of the picture does not appear to be particularly good, but this +is due to the comparatively low spatial resolution of the image data: +$256 \times 256$ pixels are needed to give a visually satisfying +result---as we shall see. + +\begin{figure} + \centering + \fbox{\input picture\relax} + \caption{The Ubiquitous `Girl' Image} +\end{figure} + +Unfortunately, the standard \|LN03| will not output images much greater +than 64~pixels wide: if one tries to do so, it generates ``band too +complex'' errors and produced broad white bands in the output. The +actual cause of this is not known; however, it seems to be because the +\|LN03| buffers the plotting commands internally rather than writing +dark pixels into a bitmap. When the print operation actually starts, +the driving microprocessor cannot translate the commands sufficiently +quickly. + +However, the \|LN03+| device (a field-installable hardware and firmware +upgrade) has a full-page bitmap, and is quite capable of printing off +large pictures. (However, a little care is needed in setting up the +terminal line to which the printer is attached.) + +The is another problem in producing these large pictures, and it +concerns \TeX\ itself. Since \TeX\ was designed for typesetting text +rather than pictures, its memory capacity is too small. Increasing the +size of the memory (i.e., \verb"mem_size") is obviously feasible, at +least on \VAX en, but there is a snag: \TeX\ was written to use 16-bit +integers for subscripts into the memory arrays. However, the change file +mechanism of {\mc WEB} and the careful way in which \TeX\ was written, +makes the conversion of 16-bit integers to 32-bit integers quite +straightforward. (It is also necessary to disable some of \TeX's initial +consistency checking.) + +When the author did this, producing a ``\bigTeX'', he found that the +16-bit and 32-bit versions of \TeX\ were identical in almost every +respect. The executable file was a few percent bigger, probably due to +the increased memory space rather than the different integer +representation. Likewise, the string pool and format files were slightly +larger. However, there is {\em no\/} perceivable impact on execution +times. (In fact, the author replaced the 16-bit version with \bigTeX\ +without telling users---and no-one noticed any difference!) + +This may seem a little surprising at first, but an examination of the +(pseudo-) assembler generated by the {\mc PASCAL} compiler provides the +answer. The machine code generated for variables declared as \|0..65535| +(or, indeed, \|0..255|) is {\em identical\/} to that for, say +\|0..262144|; 32-bit integers are used in all cases. (This does, of +course, not apply to {\bf packed array}s.) +\TeX\ is very frugal in the way it handles its memory arrays, +always re-using the same region if possible; this keeps the page fault +rate low. Since the \VAX\ initialises all memory to be `demand-zero' +when a program is loaded, there is no increase in the system overhead +due to unused regions of \TeX's memory. + +\begin{figure*} + \centering + \fbox{\input boat\relax} + \caption{A $256 \times 256$ Lake Scene} +\end{figure*} + +The version of \TeX\ at the author's site has a large enough memory +capacity for four $256 \times 256$ pictures (or one $512 \times 512$ +picture!) in addition to the usual text, fonts and macro definitions. +This allows users to put a few images into floating figures, as +described above, without overflowing \TeX's memory. A $256 \times 256$ +picture is shown in \fig{2}. + +Indeed, to a certain extent, the physical size of a picture on the +printed page determines the maximum number of pixels which can be +plotted. Images of $512 \times 512$ pixels are more or less standard in +the image processing community, while satellite images used in remote +sensing applications have several thousand pixels on a side! Hence, if +the image size exceeds a proscribed maximum (256~pixels, say), +\|TEXPIC| must {\em interpolate} between pixels to reduce the size of an +image. Another associated \|SUBROUTINE|, \|TEXMAX|, is used to tell +\|TEXPIC| the maximum number of pixels which can be output. If the \|M| +dimension of an image exceeds this value, the image is interpolated down +to this plottable maximum number of pixels. + +\begin{figure*} + \centering + \fbox{\input mandy\relax} + \caption{Mandrill Image, Reduced to $200 \times 200$ + Pixels from $512 \times 512$ Pixels} +\end{figure*} + +There are many ways to perform the interpolation. The theoretical +optimum is to use a $\sin x / x$ interpolation function (usually +achieved via Fourier transformation), but this is slow. Cubic or linear +interpolators tend to be used in practise. Recognising that \TeX\ output +of a reduced $4000 \times4000$~pixel image will inevitably be +inaccurate, \|TEXPIC| uses a linear interpolation scheme. However, since +linear interpolators usually blur edges (a particularly undesirable +effect), it attempts to reduce the blur by using a {\em +context-sensitive\/} interpolator. This interpolates between triplets of +pixels at right angles and selects the value of the line with maximum +gradient. For example, \fig{3} is a $200 \times 200$~pixel image, reduced +from a $512 \times 512$ image in this way. + +All the software described here is available. \|TEXPIC| and supporting +routines exist in both standard \FTN\ and \VAX\ \FTN; the \VAX\ version +does clever things with filenames and channel numbers. The \bigTeX\ +change file is, of course, specific to \VMS, but may be useful for +people making similar enhancements on other machines. + + +\subsection*{Enhancements to the Software} + +Since this article was submitted to \TUB, a few improvements have been made +to \|TEXPIC|. Firstly, the code used an \|ASSIGN|ed \|GO~TO|, which is no +longer a part of the \FTN\ standard. The latest version of the routine has this +section of code in both the places where it is needed. The second improvement +is to output the picture in a more concise format, along the lines of Don +Knuth's macros in \TUB\ volume~8 number~1. The files written in this new format +are fully compatible with existing \TeX\ documents. There has been no +perceivable change in execution time. + +Another support routine has been written, too: \|ZSAME| tells \|TEXPIC| that +subsequent pictures should be scaled with the same factors as the last picture. +(An error message is generated if no previous picture has been plotted.) Thanks +to Guy Facius of SFEBP Paris for this suggestion. + +\end{document} |