Specification of the RLI file format

RLI (RealWorld Layered Image) is a proprietary image format used by RW software. The file format is evolving together with the software. Since 2011, .rli can store animations. In 2012, support for out-of-canvas content and vector layers was added.

RLI is not 100% forwards compatible. This means that files saved in a newer version of a software may not work in earlier version of the software.

Structure of a .rli file

The first 16 bytes of every .rli file must contain the following ASCII-encoded text:

RWLayeredImage_1

The header is followed by arbitrary number of data chunks. Each chunk is aligned on a 4-byte boundary and contains:

• chunk identifier (4 bytes)
• chunk length (4 bytes)
• actual data

Integral numbers are always stored in little-endian order. Floating point numbers are stored as IEEE 754-1985 single or double precision formats. Text values are using ASCII, UTF8 or UCS16 (little-endian) encoding.

Chunk identifier usually consists of 4 uppercase ASCII letters. For example 'SIZE'.

Chunk length determines the length of the following data. The length does not include the length of the chunk identifier or the chunk length fields. Since chunks are aligned on 4 byte boundaries, padding bytes may need to be inserted after the data. For example, if chunk length is 6, 2 padding (zero) bytes must be present (if the current chunk is not the last one).

If a decoder encounters an unknown chunk, it should simply skip it. Here is a simplified code:

BYTE const* pData = ...; // pointer to first chunk
while (!end_of_file)
{
    // on little-endian machine
    if (chunk_is_known(*reinterpret_cast<DWORD const*>(pData)))
         process_chunk...;
    pData += 8+((*reinterpret_cast<DWORD const*>(pData+4)+3)&0xfffffffc)
}

Known chunks

Here is a list of currently known chunks.

FRMI - frame info chunk

The FRMI chunk only appears in animated files and precedes each frame.

Length: 4 bytes
Content:

duration - floating point number - frame duration in seconds

CNVS - canvas info chunk

The CNVS chunk was introduced in version 2012.1 and specifies the size of the canvas in pixels and the physical resolution. This chunk is optional. If it is missing, the file is using default canvas size and resolution (256x256 pixels, 100 DPI).

Length: 24 bytes
Content:

horizontal canvas size - 32-bit integer - pixels
vertical canvas size - 32-bit integer - pixels
horizontal resolution numerator - 32-bit integer
horizontal resolution denominator - 32-bit integer
vertical resolution numerator - 32-bit integer
vertical resolution denominator - 32-bit integer

Resolution is specified by a rational number. 100 DPI would be saved as 100/254. 100 [points per millimeter] would be saved as 100/10.

RSLT - resolution chunk

This is a deprecated chunk that was replaced by the CNVS chunk in version 2012.1.

Length: 32 bytes
Content:

numerator X - 32-bit integer
denominator X - 32-bit integer
numerator Y - 32-bit integer
denominator Y - 32-bit integer
numerator Z - 32-bit integer
denominator Z - 32-bit integer
numerator W - 32-bit integer
denominator W - 32-bit integer

Resolution has the same meaning as in the CNVS chunk.

CHDF - channel default chunk

This chunk holds the default background color of the image (if no layers are present) and gamma correction value for the whole image. This is an optional chunk. If it is missing, transparent is the default background and 2.2 is the default gamma value.

Length: 8 bytes
Content:

gamma - floating point number
blue - 1 byte (using the above gamma)
green - 1 byte (using the above gamma)
red - 1 byte (using the above gamma)
alpha - 1 byte

LAER - layer chunk

LAER is a composed chunk representing a layer in the layered image and it may contain 0 or more other chunks.

Length: variable

NAME - name sub-chunk

Name of the layer. Optional - if missing, layer has no name.

Length: variable (even)
Content:

name - UCS16 encoded name - number of characters = length/2

BLND - blending sub-chunk

Introduced in version 2012.1. Specifies layer blending mode and opacity. Optional - if missing, layer is 100% visible and uses default blending mode.

Length: 12 bytes
Content:

visiblity - 32-bit integer - 1=visible, 0=hidden
opacity - floating point number - 1=100% opacity
blending_mode - 32-bit integer

PRPS - properties sub-chunk

This is an obsolete chunk that is not read by version 2012.1 (BLND chunk is used instead), but is still written to increase compatibility.

Length: 60 bytes
Content:

visiblity - same as in BLND
opacity - same as in BLND
blending_mode - same as in BLND
position X - floating point number
position Y - floating point number
position Z - floating point number
position W - floating point number
margin X prev - 32-bit integer
margin X next - 32-bit integer
margin Y prev - 32-bit integer
margin Y next - 32-bit integer
margin Z prev - 32-bit integer
margin Z next - 32-bit integer
margin W prev - 32-bit integer
margin W next - 32-bit integer

In versions prior to 2012.1, individual layers were positioned using the above structure. First, margins were added to the image size. Then the position parameter was used to compute actual placement of the layer. If position is 0, layer is centered, -1 means left or top alignment, 1 means right or bottom alignment. Fractional values were possible. When writing legacy .rli files it is recommended to set all positions and margins to 0 and use layers of the same size.

EFCT - effect sub-chunk

This chunk holds the configurations for layer styles. Since interpretation of the layer style requires access to processing plug-ins, the details are not discussed here. Please treat the content of the EFCT chunk as opaque data.

This chunk is optional.

DOCU - document sub-chunk

This chunk holds the data of the sub-document in the layer. Typically, this will be an embedded PNG file, but it may be any other supported file type. In version 2012.1, the embedded file type will be in the RRI format if the layer contains out-of-canvas data or in RVI format if the saved layer is a vector layer.

This chunk is optional in version 2012.1, but mandatory in the older format.

META - metadata chunk

This chunk may be present in the file multiple times. The chunk may hold arbitrary data, for example EXIF block or a color profile.

Length: variable
Content:

name - UCS16 encoded, zero-terminated name of the block
data - block data

Various kinds of .rli files

Initially, size of layered images was not explicitly set. Instead, it was computed from the individual sizes of the layers it contained. In version 2012.1, layered image has an explicit size and, as a consequence, some of the chunk became obsolete (RSLT, PRPS) and were replaced with updated versions (CNVS, CHDF, BLND).

Since all of the new chunks are optional and the PRPS chunk is still written for compatibility reasons, here is a guide how to recognize whether the file uses the old or the new format: If the file contains a PRPS chunk and does not contain a BLND chunk, the file is in old format. Otherwise it will be considered to be in the new format.

The FRMI chunk introduced in 2011.1 separates individual frames of an animation. If an animated file is opened in earlier versions, all frames will appear as layers instead.

How to export to RLI format?

If you are an author of an image editor and want to export to .rli, follow these guidelines to reach maximum compatibility:

• Write the CNVS chunk.
• If possible, use PNG format to write individual layer data and make all layers the same size.
• If you need to write the BLND chunk, also write the PRPS chunk with zeros in the extra values.

How to import from RLI format?

First, accept the fact that you may not be able to import every .rli file in full. The format is variable and some files may use different formats than PNG for individual layers. Another difficult aspect is the EFCT chunk. The layer style may contain any image operation available, including operations installed as plug-ins. If you need to read the EFCT chunk, please contact Vlasta for more info.