Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA
Path: utzoo!watmath!clyde!bonnie!akgua!whuxlm!harpo!decvax!genrad!mit-eddie!think!harvard!seismo!brl-tgr!ron
From: ron@brl-tgr.ARPA (Ron Natalie )
Newsgroups: net.graphics
Subject: Re: run length encoding
Message-ID: <11513@brl-tgr.ARPA>
Date: Thu, 11-Jul-85 17:48:36 EDT
Article-I.D.: brl-tgr.11513
Posted: Thu Jul 11 17:48:36 1985
Date-Received: Wed, 17-Jul-85 03:41:02 EDT
References: <964@sdcsvax.UUCP>
Organization: Ballistic Research Lab
Lines: 107

> I was recently given some image files that have a filename ending in ``.rle''.
> They appear to be encoded in some dense way.
> 
Here's the documentation.  I've got image converters for Adage (Ikonas) 3000's
as well as versadreks and applicon printers.

-Ron

.TH RLE 5 9/14/82 5
.UC 4 
.SH NAME
rle \- Run Length Encoded file format
.SH DESCRIPTION
The output file format is (note: all words are 16 bits and bytes
are saved in PDP-11 order):
.TP
.B Word 0
A ``magic'' number.  The top byte of the word contains the letter `R' or the
letter `W'.  `W' indicates that only black and white information was saved.
The bottom byte is one of the following:  
.TP
.B ` '
Means a straight ``box'' save, -S flag was given.  
.TP
.B `B'
Image saved with background color, clear screen to background before restoring
image.  
.TP
.B `O'
Image saved in overlay mode.  I.e., pixels of background color were not
saved, and screen should NOT be cleared before restoring.  However,
background color information is still saved, so the image may be
restored with background if desired.
.TP
.B Words 1-6
The structure:

.nf
{
    short   xpos,                       /* Lower left corner
            ypos,
            xsize,                      /* Size of saved box
            ysize;
    char    rgb[3];                     /* Background color
    char    map;                        /* flag for map presence
}

.fi
\&
.PP 
If the map flag is non-zero, then the color map will follow as 3*256
words, first the red map, then the green map, and finally the blue map.
Note: for an 8 bit color map, the bottom 8 bits of each word will be
significant, the top 8 bits can be ignored.
.PP 
Following the setup information is the Run Length Encoded image.  Each
instruction consists of a 4-bit opcode, a 12-bit datum and possibly one or more
following words (all words are 16 bits).  The instruction opcodes are:
.TP
.B SkipLines (1)
The bottom 10 bits are an unsigned number to be added to current Y position.
.TP
.B SetColor (2)
The datum indicates which color is to be loaded with the data described by the
following ByteData and RunData instructions.  0->red, 1->green, 2->blue.  The
operation also resets the X position to the initial X (i.e. a carriage return
operation is performed).
.TP
.B SkipPixels (3)
The bottom 10 bits are an unsigned number to be added to the current X
position.
.TP
.B ByteData (5)
The datum is one less than the number of bytes of color data following.  If the
number of bytes is odd, a filler byte will be appended to the end of the byte
string to make an integral number of 16-bit words.  The bytes are in PDP-11
order.  The X position is incremented to follow the last byte of data.
.TP
.B RunData (6)
The datum is one less than the run length.  The following word contains (in its
lower 8 bits) the color of the run.  The X position is incremented to follow
the last byte in the run.
.SH DISCUSSION
The only major assumption of the REL format is that a pixel contains 8 bits
(24 bit images are represented by saving the three primaries
separately).  It is a scanline oriented ``protocol'', with each scanline
represented as a set of runs and pixels.  A run is a sequence (3 or
more) pixels with the same color, if several adjacent pixels are
different colors, they are stored as a pixel sequence.  In the limit
(every pixel is a different color), it is only slightly larger than a
file containing nothing but pixel data.  For images with large
mono-colored areas, it is very much more efficient.  We typically see
space savings of 70 or 80 percent (i.e., a 750KByte image is saved as a
100-200 Kbyte file).
.SH AUTHOR
.PP 
Spencer W. Thomas
.SH SEE ALSO
.PP 
.I svfb(1)
\&, 
.I getfb(1)
\&
.SH BUGS
The only ``wierd'' thing about the format is that it assumes that the
origin is in the lower left corner.  This seemed reasonable to us at the
time, but most frame buffers seem to put it in the upper left.