Wavefront RLA: Summary from the Encyclopedia of Graphics File Formats

Wavefront RLA File Format Summary

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.

Vendor specifications are available for this format.

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:

  • Graphics images

  • Field-rendered images captured from live video

  • Three-dimensionally rendered image 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.

File Organization

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:

  • Header

  • Scan-line offset table

  • Image data

File Details

This section contains information about each of the components in an RLA or RLB file.

Header

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.

Scan-Line Offset Table

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.

Image Data

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.

Field-Rendered Images

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.

3D Image Data

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.

Run-Length Encoding

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

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.


This page is taken from the Encyclopedia of Graphics File Formats and is licensed by O'Reilly under the Creative Common/Attribution license.

More Resources