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.