brian@sdcsvax.UUCP (Brian Kantor) (07/09/85)
I was recently given some image files that have a filename ending in ``.rle''. They appear to be encoded in some dense way. What is the format of this encoding? I assume it is some sort of run-length-encoding, about which I would like to learn more, so some pointers to references on RLE would also be appreciated. Brian Kantor UC San Diego Computer Graphics Lab decvax\ brian@ucsd.arpa akgua >--- sdcsvax --- brian ucbvax/ Kantor@Nosc
rivero@kovacs.UUCP (Michael Foster Rivero) (07/10/85)
In article <964@sdcsvax.UUCP> brian@sdcsvax.UUCP (Brian Kantor) writes: >I was recently given some image files that have a filename ending in ``.rle''. >They appear to be encoded in some dense way. > >What is the format of this encoding? I assume it is some sort of >run-length-encoding, about which I would like to learn more, so some >pointers to references on RLE would also be appreciated. > > Brian Kantor UC San Diego Computer Graphics Lab > > decvax\ brian@ucsd.arpa > akgua >--- sdcsvax --- brian > ucbvax/ Kantor@Nosc Run length encoding uses two bytes to store long runs of identical pixels. The idea is "plot BYTE1 pixels of BYTE2 color". For very graphic images with lots of white space, black space, or large areas of the same color, the compression results in a lot of saved file space. But, since there is no standard RLE format, the best place to find out about your file is with the original programmer / system. Michael Rivero
nitin@ur-laser.uucp (Nitin Sampat) (07/11/85)
Run length coding (RLC) is a data compression technique, used
to reduce the data in large image file, like the ones from LANDSAT.
It is called "error-free" encoding in that the original can be replicated
exactly from the encoded form.
In one-dimensional RLC, the following is done :
Lets take a row of a digital image. As we go along the row, the
sequence of pixels is mapped into a sequence of pairs ( g1, l1 ),
(g2, l2 )...etc where g is the gray level and l the run length. For example,
if we take a row of a digital image with the following gray levels
2 2 2 3 3 4 4 4
If this is the first row, we may reduce the data by mapping it into a
sequence of integer pairs. In this case, it would be
(2,3) (3,2) (4,3)
This is then repeated for all the rows. As is obvious, the
process is completely reversible and hence "error-free".
There is also something called two-dimensional RLC which takes vertical
direction also into consideration.
A good explanation of image coding may be found in :
"Digital Image Processing", Gonzales and Wintz, Addison Wesley Pub. Co.,
1977. Mass.
nitin@ur-laser.uucp
{seismo,allegra}!rochester!ur-laser!nitinron@brl-tgr.ARPA (Ron Natalie <ron>) (07/12/85)
> 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.