Also Known As: RLA, RLB, Run-length Encoded Version A, Run-length Encoded Version B
Type | 3D bitmap |
Colors | 16 million |
Compression | RLE |
Maximum Image Size | 64Kx64K pixels |
Multiple Images Per File | Yes |
Numerical Format | Big-endian |
Originator | Wavefront |
Platform | UNIX |
Supporting Applications | Wavefront Advanced Visualizer |
See Also | None |
Usage
Storage of 3D output data.
Comments
Proprietary, but associated with a well-known application, so likely to be important in the future.
Sample images are available for this format.
The Wavefront RLA (Run-Length Encoded Version A) image file format is used to store three types of data:
Contents:
File Organization
File Details
For Further Information
RLA is used primarily by the Wavefront Advanced Visualizer animation package to store output data and to exchange graphical data with other software applications. There are actually three variations of the RLA image file format.
Prior to 1990, the original RLA format was in use. In this format, RLA was capable of storing only standard graphics images, such as those found in many other bitmap file formats.
In 1990, the capabilities of RLA expanded to include the storage of field-rendered images. Rather than revising RLA (and upsetting many customers in the process), Wavefront created the RLB (Run-Length Encoded Version B) image file format to incorporate these new features. RLB is essentially the original RLA format with a few extra fields added to the header.
Some time later, Wavefront released version 3.0 of the Advanced Visualizer animation package and updated the original RLA format to include all of the new fields found in the RLB format. Wavefront also added and expanded several fields in the header to include the capability of storing multichannel rendered image data--a feature not supported by the RLB format. Thus, the new RLA image file format was born.
Today, the new RLA image file format is the standard format for Wavefront software applications. Both RLB and the original RLA format are considered to be outdated, and future support of these two older formats by Wavefront is questionable.
Both RLA formats and the RLB format are always stored using the big-endian byte order. Floating-point data is always stored as ASCII strings to avoid problems with machine-dependent representations of floating-point data. String data stored in the header is composed entirely of ASCII data and is always NULL-terminated. Blank character fields contain all NULL (ASCII 00h) values.
All three formats contain three major sections:
This section contains information about each of the components in an RLA or RLB file.
The RLA header is 740 bytes in length and has the following format:
typedef struct _WavefrontHeader { SHORT WindowLeft; /* Left side of the full image */ SHORT WindowRight; /* Right side of the full image */ SHORT WindowBottom; /* Bottom of the full image */ SHORT WindowTop; /* Top of the full image */ SHORT ActiveLeft; /* Left side of the viewable image */ SHORT ActiveRight; /* Right side of viewable image */ SHORT ActiveBottom; /* Bottom of the viewable image */ SHORT ActiveTop; /* Top of the viewable image */ SHORT FrameNumber; /* Frame sequence number */ SHORT ColorChannelType; /* Data format of the image channels */ SHORT NumOfColorChannels; /* Number of color channels in image */ SHORT NumOfMatteChannels; /* Number of matte channels in image */ SHORT NumOfAuxChannels; /* Number of auxiliary channels in image */ SHORT Revision; /* File format revision number */ CHAR Gamma[16]; /* Gamma setting of image */ CHAR RedChroma[24]; /* Red chromaticity */ CHAR GreenChroma[24]; /* Green chromaticity */ CHAR BlueChroma[24]; /* Blue chromaticity */ CHAR WhitePoint[24]; /* White point chromaticity*/ LONG JobNumber; /* Job number ID of the file */ CHAR FileName[128]; /* Image file name */ CHAR Description[128]; /* Description of the file contents */ CHAR ProgramName[64]; /* Name of the program that created the file */ CHAR MachineName[32]; /* Name of machine used to create the file */ CHAR UserName[32]; /* Name of user who created the file */ CHAR DateCreated[20]; /* Date the file was created */ CHAR Aspect[24]; /* Aspect format of the image */ CHAR AspectRatio[8]; /* Aspect ratio of the image */ CHAR ColorChannel[32]; /* Format of color channel data */ SHORT Field; /* Image contains field-rendered data */ CHAR Time[12]; /* Length of time used to create the image file */ CHAR Filter[32]; /* Name of post-processing filter */ SHORT NumOfChannelBits; /* Number of bits in each color channel pixel */ SHORT MatteChannelType; /* Data format of the matte channels */ SHORT NumOfMatteBits; /* Number of bits in each matte channel pixel */ SHORT AuxChannelType; /* Data format of the auxiliary channels */ SHORT NumOfAuxBits; /* Number of bits in each auxiliary channel pixel */ CHAR AuxData[32]; /* Auxiliary channel data description */ CHAR Reserved[36]; /* Unused */ LONG NextOffset; /* Location of the next image header in the file */ } WAVEFRONT;
WindowLeft, WindowRight, WindowBottom, and WindowTop specify the absolute size of the image in pixels. The home position of the window is normally the bottom-left corner of the display. An image displayed starting from this position has WindowLeft and WindowBottom values of 0.
ActiveLeft, ActiveRight, ActiveBottom, and ActiveTop define the part of the image that is actually stored in the file. Normally, these values are the same as the WindowLeft, WindowRight, WindowBottom, and WindowTop values. However, if the stored image is a clip from a larger image, these values indicate the position of the stored image on the original image. Only the clipped portion of the original image is stored in the file.
The size of the image may be determined using the following calculations:
ImageHeight = (ActiveBottom - ActiveTop) + 1; ImageWidth = (ActiveRight - ActiveLeft) + 1;
FrameNumber is the image number if the image is one frame in a sequence. Values for this field start at 01h.
ColorChannelType indicates the format of the color-channel data. A value of 0 indicates that the data is stored as 8-bit BYTEs. A value of 1 indicates that the data is stored as 16-bit WORDs. A value of 2 indicates that the data is stored as 32-bit DWORDs. And a value of 3 indicates that 32-bit IEEE floats are used to store the data.
NumOfColorChannels specifies the number of color channels in the file. There are typically three color channels (red, green, and blue) in an image.
NumOfMatteChannels specifies the number of matte information channels in the file. There is typically only one matte channel, or possibly one matte channel per color channel.
NumOfAuxChannels specifies the number of auxiliary information channels in the file. There are normally no auxiliary channels (unless the file contains 3D image data), and this field is set to 00h.
Revision holds the current revision identifier for the image format. This value is always FFFEh. This field holds an auxiliary data-mask value in original RLA format images.
Gamma contains an ASCII floating-point number representing the gamma correction factor applied to the image before it was stored. A value of 2.2 is considered typical. A value of 0.0 indicates no gamma setting.
RedChroma, GreenChroma, BlueChroma, and WhitePoint specify the X and Y chromaticity values for the red, green, and blue primary colors and the white-point reference value. These values are written as ASCII floating-point numbers and have the standard NTSC chromaticity values as their default:
| X | Y |
---|---|---|
Red |
0.670 |
0.330 |
Green |
0.210 |
0.710 |
Blue |
0.140 |
0.080 |
White |
0.310 |
0.316 |
JobNumber is a user-defined number that identifies the project or task of which the image is part.
FileName is the name of the image file which stores the data. A maximum of 128 characters may be stored in this field.
Description is a string describing the contents of the image file. A maximum of 128 characters may be stored in this field.
ProgramName is the name of the software program that created the file. A maximum of 64 characters may be stored in this field.
MachineName is the name of the computer system that created the image file. A maximum of 32 characters may be stored in this field.
UserName is the name of the user or system account that created the image file. A maximum of 32 characters may be stored in this field.
DateCreated is the date that the image file was created. A maximum of 20 characters may be stored in this field. Wavefront images typically use the date format MMM DD hh:mm yyyy (e.g., SEP 17 16:30 1994).
Aspect is a user-defined string describing the aspect ratio of the image. This string is used to locate size and aspect ratio information stored in a table. A maximum of 24 characters may be stored in this field. Following is a list of aspect description strings defined by Wavefront:
Description | Width | Height | Aspect |
---|---|---|---|
1k_square |
1024 |
1024 |
1.00 |
2k_square |
2048 |
2048 |
1.00 |
3k_square |
3072 |
3072 |
1.00 |
4k_square |
4096 |
4096 |
1.00 |
5k_square |
5120 |
5120 |
1.00 |
6k_square |
6144 |
6144 |
1.00 |
7k_square |
7168 |
7168 |
1.00 |
8k_square |
8192 |
8192 |
1.00 |
Creator |
640 |
484 |
1.33 |
ImageNode |
512 |
486 |
1.33 |
Iris-8-10 |
3000 |
2400 |
1.25 |
Abekas |
720 |
486 |
1.33 |
ccir_pal |
720 |
576 |
1.33 |
full_1024 |
1024 |
768 |
1.33 |
full_1280 |
1280 |
1024 |
1.33 |
iris_1400 |
1022 |
768 |
1.33 |
iris_2400 |
1024 |
768 |
1.33 |
iris_ntsc |
636 |
484 |
1.33 |
iris_pal |
768 |
576 |
1.33 |
matrix_2k |
2048 |
1366 |
1.50 |
matrix_2k_ntsc |
1821 |
1366 |
1.33 |
matrix_4k |
4096 |
2732 |
1.50 |
matrix_4k_ntsc |
3642 |
2732 |
1.33 |
ntsc_4d |
646 |
485 |
1.33 |
ntsc_512 |
512 |
484 |
1.33 |
ntsc_512_fld |
512 |
242 |
1.33 |
ntsc_636 |
636 |
484 |
1.33 |
ntsc_636_fld |
636 |
242 |
1.33 |
ntsc_640 |
640 |
486 |
1.33 |
ntsc_640_fld |
640 |
243 |
1.33 |
pal_768 |
768 |
576 |
1.33 |
pal_780 |
780 |
576 |
1.33 |
pixar |
1024 |
768 |
1.33 |
pixar_ntsc |
640 |
486 |
1.33 |
pv_2k |
2048 |
1638 |
1.25 |
pv_3k |
3072 |
2457 |
1.25 |
pv_ntsc |
646 |
486 |
1.33 |
pv_pal |
768 |
576 |
1.33 |
qnt_pal |
720 |
576 |
1.33 |
qtl_ntsc |
720 |
486 |
1.33 |
screen |
1280 |
1024 |
1.25 |
shiba_soku |
1600 |
1045 |
1.33 |
sony_hdtv |
1920 |
1035 |
1.855 |
tek_ntsc |
720 |
486 |
1.33 |
tek_pal |
720 |
576 |
1.33 |
texture_512 |
512 |
512 |
1.00 |
tga_486 |
512 |
486 |
1.33 |
tga_ntsc |
512 |
482 |
1.33 |
vc_ntsc |
640 |
486 |
1.33 |
vfr_comp |
768 |
486 |
1.33 |
vfr_rgb |
720 |
486 |
1.33 |
vst_hires |
1024 |
768 |
1.33 |
vst_ntsc |
756 |
486 |
1.33 |
vst_pal |
738 |
576 |
1.33 |
vst_pal2 |
740 |
578 |
1.33 |
vst_targa |
512 |
486 |
1.33 |
vtc_mvbhm |
1440 |
1200 |
1.33 |
vte_720 |
720 |
576 |
1.33 |
window |
1024 |
820 |
1.25 |
AspectRatio is an ASCII floating-point number used to determine the pixel aspect ratio of the image. This number is the display width divided by the display height.
ColorChannel is an ASCII string identifying the color space model used to represent the image data. Values for this field may be rgb, xyz, or sampled.
Field is set to 01h if the file contains a field-rendered image. Otherwise, the value of this field is 00h.
Time is a string storing the amount of CPU time in seconds that was required to create the image. A maximum of 12 characters may be stored in this field.
Filter is the name of the filter used to post-process the image data before storage. A maximum of 32 characters may be stored in this field.
NumOfChannelBits specifies the number of bits per pixel in each color channel. The value for this field may be in the range of 1 to 32.
MatteChannelType indicates the format of the matte channel data. A value of 0 indicates that the data is stored as 8-bit BYTEs. A value of 1 indicates that the data is stored as 16-bit WORDs. A value of 2 indicates that the data is stored as 32-bit DWORDs. And a value of 3 indicates that the data is stored as 32-bit IEEE floats.
NumOfMatteBits specifies the number of bits per pixel in each matte channel. The value for this field may be in the range of 1 to 32.
AuxChannelType indicates the format of the auxiliary channel data. A value of 0 indicates that the data is stored as 8-bit BYTEs. A value of 1 indicates that the data is stored as 16-bit WORDs. A value of 2 indicates that the data is stored as 32-bit DWORDs. And a value of 3 that indicates that the data is stored as 32-bit IEEE floats.
NumOfAuxBits specifies the number of bits per pixel in the auxiliary channel. The value for this field may be in the range 1 to 32.
AuxData indicates the format of the auxiliary channel data. Valid strings for this field are range and depth.
Reserved is unused space that is reserved for future header fields. All bytes in this field are always set to 00h.
NextOffset is the offset value to the header of the next image stored in the file. The value of this field is 00h if no other images appear in the file.
Immediately following the header is a scan-line offset table. This table is a 1D array of 4-byte integers indicating the starting position of each scan line in the image data.
Each scan line in an RLA and RLB image file is run-length encoded. Because of the variable lengths of the RLE records and packets, it is impossible to detect easily where any scan line begins unless the image is decoded from the beginning.
To locate easily any scan line in the image data, store the offsets to the beginning of each encoded scan line in the scan-line offset table. Each entry in the offset table is four bytes in size, and there is one entry per scan line in the image. All offsets are calculated from the beginning of the image file, even if a file contains multiple images.
The image data in RLA and RLB files is separated into one or more color channels (also called color planes) and one or more matte channels (also called alpha channels). An image using the RGB color model contains three color channels, one each for red, green, and blue color information.
Typically, there is only one matte channel per image, although one matte channel per color channel is possible. The matte channel contains information on the visual appearance of each pixel in the image and indicates the degree of transparency or opaqueness of each pixel when the image is displayed.
The channel information is organized into scan lines. Each scan line of image data therefore contains four (or more) channels of information in the order of red, green, blue, and matte. When a scan line is read, all of the red information is read first, followed by the green information, then blue, and so on.
Multiple images may be stored in a single disk file by simply appending them together. The NextOffset value in the header of one image should contain the offset value of the first byte of the header of the next image. The last image in a file will have a NextOffset value of 00h. This is common way to store a full-sized image and a postage-stamp image (called a swatch in Wavefront lingo) in the same file.
The RLB and the newer RLA format have the capability of storing field-rendered image data. Normally, an image bitmap contains both odd- and even-numbered scan lines. Interlaced video signals, such as those used by television, display frames of video data as alternating fields of odd- and even-numbered scan lines. There are always two fields per frame.
When an interlaced video field is captured and stored as an image, only half of the scan lines in the frame are present in the field. It is therefore possible to store a captured video frame as two separate fields by using two RLA or RLB image files. Odd-numbered scan lines are stored in one file, and even-numbered scan lines are stored in the other. Images stored in this way usually have file names with odd and even numbers to indicate frame and field designations.
Note that in field-rendered images, the header values ActiveBottom and ActiveTop indicates the full size of the frame image. The actual number of scan lines stored in each field-image file is half the difference between these values. For example, a 640-line frame creates two 320-line field-image files.
New RLA images normally contain four channels of information in the form of red, green, blue, and matte data. If a 3-dimensional scene has been rendered to an image, a fifth channel, known as the auxiliary channel, is present and contains information on the depth of each pixel relative to the camera's, or viewer's, location. Auxiliary channel information is stored as floating-point data in the range 0.00 to 1.00 inclusive.
Each channel of image data in RLA and RLB image files is always run-length encoded (RLE). Each channel within a scan line is encoded into a separate RLE record. Each record begins with a 2-byte value indicating the number of bytes of encoded data in the record. This count byte is followed by the encoded channel data itself. There may be a maximum of 65,535 bytes of encoded data in any record.
Image data with a pixel depth of one byte (one to eight bits) is encoded into packets containing a run-count byte and a run-value byte. If the run-count value is a positive value, then the run value is repeated "run count + 1" times. If the run-count value is negative, the following "run count" bytes are repeated literally. Only runs of three or more pixels are encoded into repeated runs.
Image data with a pixel depth of two bytes (nine to 16 bits) is encoded using a similar algorithm, but the actual bytes of pixel data are read in an interleaved fashion. Two separate passes are made over the pixel data in each channel. The first pass run-length encodes the least significant byte of each pixel in the channel; the second pass encodes the most significant byte of each pixel in the channel.
With image data that contains four bytes (17 to 32 bits) per pixel, a 4-pass process is used, encoding from the least to most significant byte in each pixel. The same algorithm is used for encoding each pass of 2- and 4-byte pixel data as is used for 1-byte pixel data.
For further information about the Wavefront RLA and RLB formats, see the specification included on the CD-ROM.
The specification for the RLA and RLB file formats is also available in Appendix B of the Wavefront Advanced Visualizer User Manuals available from Wavefront:
Wavefront Technologies
530 East Montecito Street
Santa Barbara, CA 93103
Voice: 805-962-8117
FAX: 805-963-0410
WWW: http://www.aw.sgi.com/
Wavefront also maintains a toll-free support number and a BBS for its customers. Many Wavefront users' groups exist to support customers.
Copyright © 1996, 1994 O'Reilly & Associates, Inc. All Rights Reserved.