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.
The first 16 bytes of every .rli file must contain the following ASCII-encoded text:
RWLayeredImage_1The header is followed by arbitrary number of data chunks. Each chunk is aligned on a 4-byte boundary and contains:
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)
}Here is a list of currently known chunks.
The FRMI chunk only appears in animated files and precedes each frame.
Length: 4 bytes
Content:
duration - floating point number - frame duration in secondsThe 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 integerResolution is specified by a rational number. 100 DPI would be saved as 100/254. 100 [points per millimeter] would be saved as 100/10.
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 integerResolution has the same meaning as in the CNVS 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 byteLAER is a composed chunk representing a layer in the layered image and it may contain 0 or more other chunks.
Length: variable
Name of the layer. Optional - if missing, layer has no name.
Length: variable (even)
Content:
name - UCS16 encoded name - number of characters = length/2Introduced 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 integerThis 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 integerIn 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.
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.
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.
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 dataInitially, 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.
If you are an author of an image editor and want to export to .rli, follow these guidelines to reach maximum compatibility:
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.
Anonymous
on May 15th 2014
Hi,Ijust started a painting with your program, I saved it in RLI format and when I tried to open it again I get the name of the file in the window border, but nothing is displayed, it says I have a 0x0 pixel image. Is my file lost forever or what? I can't seem to recover it even if I try to open it as just a separate layer... please help.
Something definitely went wrong, but it is hard to say what from this info. If you still have the file and can send it to infor@rw-designer.com I may be able to tell you more.
Wow, this page is beautiful! Has the file format taken inspiration from RIFF files and stuff like that?
Also please mention whether the integers are unsigned or signed! 
Or do they not matter actually? Since I am not too well-versed on the whole two's complement thingy
Anonymous
