MindImages - Documentation for P.C. version 2.00: 7 Jan 1993

   V.G.A. required to view the images
   (unless there is sufficient demand for support of other graphics adapters).
   PostScript can be generated on other graphics types.

Program conceived and created by:

 Eric Thompson   : E.Thompson@newcastle.ac.uk
 Rob Scott       : Robert.Scott@newcastle.ac.uk
 Gordon Flanagan : G.J.Flanagan@newcastle.ac.uk

To run MindImages from a dos prompt type:

MINDIMG


Description:
============

 MindImages was written to allow the creation of single image random dot
stereograms (sirds) from compressed depth information. The compression format
was specifically designed to allow direct transmission across the Internet
to the newsgroup alt.3d, where the interest in sirds has snowballed in the
last few months, thanks to Andy Kinsmans' Torus - a couple of hundred K
postscript bit image.

 Needless to say, postscript images take up a lot of network bandwidth, so
it was decided to take the original depth information, compress it and
transmit the much smaller (5 - 30K typ.) files.

 MindImages will take the files as input and create either:
   
  An on screen black and white rds,
  An on screen red/green or red/blue stereogram (use coloured glasses)
  A postscript bit image to throw at your postscript printer.


Viewing sirds:
==============

 There are two ways to view these stereograms. These are:
        
            1) wide eyed.
            2) cross eyed.

 Both will create a 3d image in the brain, but the image will be inverted
using one way as opposed to the other. That is to say, parts of the image
which are raised when viewed wide eyed will descend into the screen or paper
if viewed cross eyed.

 It is helpful when starting to put two small pieces of blu-tac or coloured
sticky tape on the top of the monitor. These should be at exactly 1/5 of 
the display window apart, in the centre.

 With the stereogram on the monitor or piece of paper:

  1) At about 30 - 50 cm from the display, focus on a point directly
behind (3 metres or more away) so that the two marks are out of focus and
have split into four marks. Now, by adjusting your focus/distance try to
get the right hand mark as seen by the left eye and the left hand mark as
seen by the right eye to converge. When these lock together, keep the same
dopey look and allow your eyes to drop down onto the random pattern - 
you should now be smiling as the 3d picture appears from nowhere.

  2) At a distance that is comfortable, cross your eyes until you have
three marks in focus and gaze at the random pattern as above.

Note: If you are using the screen display, *Density 128 makes the picture
easier to see for most people, whereas *Density 200 is easier for a
postscript image (and saves toner).


Compressed file format:
=======================

 [You need only read this if you are curious]

 The first line of the compressed file contains a copyright message
terminated by a line feed and/or carriage return.

 The following lines are separated by line feeds and/or carriage returns
at a convenient line width (usually 75 chars). These separators are ignored
by the program.

 The next two bytes refer to the xcale and yscale respectively. The largest
size handled being 512x by 512y (xscale=1 yscale=1). An xscale of 2 and
yscale of 4 would describe depth info of a 256x by 128y grid. The scale
values are added to 33 to get them into the ascii range (this would have
been 32, the space character, but some terminals/machines strip trailing
spaces).

 In this case, the depth value has been limited to the range 0 - 63,
conveniently leaving 30 unused values in the ascii range after adding the
33 offset. Total range here is 33 to 126.

 In creating the output file, a variation of run length encoding is used to
fill a large buffer with depth values and running counts (up to 96)
i.e. if there are 12 horizontal values of depth 25 then the buffer would
contain 25,12,...
 
Now the unused ascii values come into play:
 We can look at the previous 30 colour/count combinations (or up to the 
current number of combinations processed-2 if we have done less than 30)
and if we find that this 25,12 combination has appeared within this range
at say, the 14th position back, then we would place the single value:

                    33+63+14=110 in our output file.

 If however, this colour/count combination did not exist within this range,
then we would place the values:

                33+colour and 33+count in our output file.

Thus if repeated values are present we reduce the total number of bytes
needed even further.

 The last valid byte in the output file is a checksum which is the sum of all
the bytes in the title string that are greater than 32 added to (the sum of
all the succeeding bytes in the output file - 33, ignoring line feeds etc).

 Now take this number MOD 64 and add 33 ...done!
  
 The checksum allows a check on file integrity and helps to protect the
copyright string at the start which will be printed at the top left hand
corner of the printed image.