My life with Mona.

by Curt Rostenbach

First Mona

Back in the early to mid '70s it was the rage to print copies of the Mona Lisa on computer paper using character overstrikes.  This was necessary because there were no (or none that I'd ever seen) graphical printers attached to the mainframes of the time.  All printing was performed on what were called "Lineprinters".  The paper was continuous perforated pinfeed sheets (typically 14"x11") that were fed to the printers that used either drums or chains.  The drums and chains held the character set and were continuously spinning.  Hammers would be timed to strike when the desired character was underneath to print the character in a manner similar to a typewriter, but much faster.  The character set available to you for printing was fixed, it could not be changed.  Also the paper pitch could only be changed manually to 6 lines per inch or 8 lines per inch.  Not very conducive to graphical displays.

But, by setting the paper advance to 8 lines per inch and then performing a series of overstrikes you could approach a grayscale.  An overstrike was when you printed a line of characters and then instead of advancing the paper, you printed another line of characters over the previous characters.  To achieve a sixteen level grayscale, it would take up to six overstrikes.

At first, I had to beg my friends who worked in the computer departments to print copies for me so I could give them to friends.  They were very popular at the time.  But I really wanted the ability to print them myself, and after I got a job as computer operator in late 1973, I was able to get a copy of the data tape that had been passed around from data center to data center across the country.  I do not know where the original dataset came from but as I would find out later, the data had become corrupted with all the copying that it had endured.  More on that later.  I had expected the data to merely be in the form of overprint characters.  If it had, this story would not have gone much further.

Instead, the data tape contained over 380 records (rows) with 254 fields (columns) that contained values between 0 and 4095.  The dataset was Mona digitized with 12 bit values!  The accompanying program read the records, reduced the data to 16 grayscale values and then used a set of characters to overprint and produce the grayscale on the printer.

Hmmm.

The computer center I worked at had drum plotters and a microfilm (35mm and 16mm) plotter.  The department also had a special Xerox machine that could make 11"x14" enlargements of 35mm film frames.  At first glance, the microfilm plotter was the ideal device to use.  It supported beam intensity setting from 0 to 15.  However, speaking to the users of the microfilm plotter, they said the beam intensity was not linear.  Also, the Xerox enlarger could not handle grayscale values, it was either black or white, no gray.

So I considered how photographs are made in newsprint.  They had the same limitations, black & white only.  With newsprint, the problem was solved by using dots of different sizes to achieve the grayscale from pure black and white.  The drum and microfilm plotters could only output a dot of a fixed size.  The plotters also moved in discrete steps, 100 steps per inch on the drum plotters, so I couldn't really draw circles of different sizes.

I pondered this for a few weeks and inspiration finally came in the form of recognizing that a 50% gray area would have every other square filled in.

And 100% would have every square filled in.

1% would only have a dot in the middle. 

99% would have every square but the middle filled in. 

It seems we need two different algorithms, one for less than 50% and another for greater than 50%.  But what about all the values in between?  It finally occurred to me to do a spiral pattern.

Well, two really, one starting on the outside going in, and the other starting at the center and moving out.  I would construct a grid and then fill in the dots depending on the darkness of the particular pixel (picture element).  Initially I started with a 10x10 grid, because I was thinking in terms of percentages.  Later I reduced it to a 5x5 grid (as used in these illustrations).

Now for say, 25%, I would need to fill in approximately every fourth location within the grid.  Since it's less than 50%, I'd have to start from the outside and spiral in.  So the following example has the order the dots would be placed.

And now reality intrudes on this glorious design.

The problem is quite literally putting a round peg an a square hole.  The movement of the plotter head is in strict, integer, (X,Y) co-ordinates.  The pen, a Rapidograph ink pen familiar to drafting students, lays down a round dot.  So instead of getting 100% black, you get,

Spacing them closer together to get an overlap, creates another problem.

The plotter pens work by depositing a drop of ink.  With the dots spaced this close, the ink does not have time to dry before another dot is being deposited, and eventually enough ink has been deposited so that when the pen tip lands on the paper, it splashes.

So I had to settle for 100% black, not really being 100% black.  Now I did consider drawing the pen in a spiral manner to create circles of different sizes, but it just seemed the spacing was too far or too close with the plotter steps vs. pen width.  We did have pens with different line thicknesses, but I was worried that as I was dragging the pen around, as the ink piled up and soaked the paper, that I'd just end up drilling little holes in the paper.  I had seen that happening when users would specify the symbols marking the data points in their plots that were too small.  The edge of the pen barrel could become quite sharp and snag on the paper fibers.  Picking up and dropping the pen for every dot I thought would avoid that problem and would promote ink flow for the life of the ink supply.  I had seen cases where the pens would dry out as they stroked a line on the paper.  A human draftsman would just stop and shake the pen before continuing, the computer would have no idea the ink flow had stopped.

Another problem was that while shaking the Rapidograph pens promotes ink flow, we are also picking up and dropping a pen around a half million times.  I never finished a physical plot of Mona, even in the reduced grid.  And if I remember correctly, I was still using the 10x10 grid when doing the plotter experiments, so make that almost two and a half million times!

So the obvious solution was to move the plotting algorithm to the microfilm plotter.

A microfilm plotter works by having a camera stare at a CRT (cathode ray tube or TV screen) while the plotter sweeps the beam across the face of the screen.  After the plot is finished, the frame is then advanced.  The film is a high contrast negative that when dried, is a drab green in color.  Where the beam has been used, the film is clear, otherwise the film is opaque.

Changing to the microfilm plotter only took a few changes to the JCL (Job Control Language), but plotting the first image took 6 hours of computer time with the Univac 418 model II.  The Univac 418 was an 18 bit unary math processor with 8K for core RAM and a 2 µsec (2 microsecond) instruction cycle time. You can see me in front of it on the home page (see the picture), it's the computer on the left and then just over my head you can see the lights of the microfilm plotter against the back wall.  There were no hard drives, only tape drives.

My first Mona Lisa circa early 1975

Needless to say, I was totally blown away by what I had gotten.  If I didn't have to work the night I was given the film (I worked 3rd shift), I would have hit the Iowa City bars pretty hard.  Instead I found that the microfilm plotter beams were not as precise as the ink pens when it came to sharpness of points.  This resulted in a more photographic image with grays instead of the hard black & white I was going for.  So the Xerox film enlarger could not make a blow up of the frame.  I had to wait until I had access to a darkroom with an enlarger.

As you can see, there are duplicated records down by her hands.  From the original overprint versions, we used to think she was holding a sheaf of wheat.  We didn't have a real picture to compare against.  She also has terminal acne.  But I'll cure that later.

I tried to speed the plotting by having the program draw back and forth on each row, instead of starting at the beginning of each.  Even though the microfilm plotter did not have a mechanical arm to move, you still had to give the commands to move it back to the beginning of the line.  Somehow I miscalculated and got this;

I finally located the duplicate records and removed them.  They were still in the dataset, I just skipped over them when it came time to draw them.  Somehow I managed to lose the program that knew where those records were.  I had painstakedly found them by hand and wasn't in the mood to do it all again.  Instead, I tried to write a program to locate them automatically.  The first version failed.  Not because of a program bug, but because the data was not exactly duplicated.  It was close, but not the same.  I dialed down the numbers and tried again.  I was surprised to discover that there were two sets of duplicated records in the dataset, not just the obvious set by her hands.  The other set was near her shoulder.

This was my first exposure to data "noise".  The data points that gave her acne were wildly out of place.  I determined that by plotting her once as a series of lines.  It was my first attempt to draw her as a mountain range.  The darkness of a point was used to compute an offset from a horizontal line.  I wanted to do hidden lines, but since there was a series of lines that I'd have to compute intersection points for, I just gave up on that notion (remember, I had limited memory to work in) and just plotted the points as a series of jaggies.  When I would encounter a bad datapoint, I'd see the plotter (I was using the drum plotters for this) suddenly make a big spike compared to the surrounding area.  My first attempt to clean up the data was to average the datapoints in a 3x3 grid.  This resulted in a Mona that looked fuzzy.  Discussing the problem with a co-worker, he suggested I keep track of how the center point of the 3x3 grid compared to it's neighbors.  If you were looking down at all the others, possibly that datapoint was bad and needed to be hammered down to the average.  The same applied for when the center point was lower than all it's neighbors.  This did a much better cleanup and gave me this,

I must say I was truly astonished by what I was able to recreate from the numbers.  I honestly did not expect to achieve photographic results.  I expected a very blocky and pixilated image at best.  Especially after all those overprint versions we had made on paper.

I never considered the commercial applications that this could have been used for.  Mainly because I did not have a way to digitize new datasets.  Years later I would kick myself when people started selling programs to uncompress pictures that had been sent through phone modems.  But that was almost ten years after I had developed the program to recreate the Mona Lisa.

Digitized Photo	Reconstructed Image

But I didn't stop there.  I had also later collected other computer portraits, but they would be in pure overprint format.  I was able to get the files transferred to data disks for my Apple ][ and I wrote programs to reverse engineer the overstrike character sets back into numbers.  From the numbers, I was able to apply the Mona program and create photographs of the posters.

Copyright © Curt Rostenbach 2007 - 2009

E-mail curt@rostenbach.com