The legacy FIF format

In the 1990s, fractal images were stored in the file formats of Iterated Systems, Inc. The formats were never published. This page describes what they contained and why files in these formats are hard to use today.

FIF Legacy Tools & SDK

For more Information about FIF Legacy, free converting Tools and a C Library visit:
FIFlegacy & libbFIFlegacy project

One name, several formats

The files had the extension .fif, for Fractal Image Format. The name covered a family of related formats that changed with each generation of the software. Two main lines can be told apart by the first bytes of a file:

Signature	Line	Main features
`FTC`	Fractal transform container	Fixed 4 × 4 pixel blocks. Several versions, from a simple fixed layout to region-based files with arithmetic coding. Also used for early fractal video.
`FIF` + version 1	Progressive FIF	Picture divided into tiles; five levels of detail, each readable on its own; block sizes from 16 pixels down to single pixels.

Within each line, a file declared its exact profile in its header, and a decoder had to support that profile precisely. A file of one generation could not be read by software written for another.

How the pictures were coded

The basic method was the block-based one described on the previous pages. The picture was divided into small range blocks, and each block was described as a shrunk, turned and adjusted copy of a larger block elsewhere in the picture. In addition, the formats used these techniques:

Shared transformations: Where a whole group of 2 × 2 or 4 × 4 neighbouring blocks could be copied from one larger region, the file stored one transformation for the group instead of one per block. The positions of the individual copies followed from the group's orientation.
Reconstruction at half size first: The decoder carried out the iteration on a picture of half the final width and height, where each round costs a quarter of the work. Only after that picture had stopped changing did it expand the result to full size, in one final pass.
Separate colour planes: Colour pictures were coded as brightness plus two colour-difference planes at reduced resolution, as in JPEG. A later variant used a colour space of its own.
Progressive levels: The FIF line stored five levels of increasing detail, with a directory of starting points for each tile and level. A viewer could stop after any level and show a complete picture.

What else a file could contain

An encoder identification stamp and a quality setting, recorded for information.
A colour palette for display on screens with 256 colours.
A sound recording, attached to the picture as a complete WAVE file.
A reference to an external template file. Some files copied blocks not only from their own picture but also from a separate library of image material. Such a file could not be decoded without the template, and the file contained only the template's name, not its content.

Why these files are hard to use today

Several properties of the formats make them difficult to use today:

No published specification. Iterated Systems never released a description of the formats. They could only be read with the company's own software, and that software has not been maintained since the early 2000s. The description on this page is based on a technical reconstruction of the formats from the original software.
Tied to fixed parameters. Block size, domain grid and many constants were fixed per profile. The format could not grow; each improvement required a new, incompatible profile.
Not always self-contained. Files that depend on an external template cannot be decoded when the template is lost.
No protection against damage. The FTC formats contain no checksums. A damaged file either fails completely or decodes to a wrong picture without warning.
Limited metadata. There was no general place for information such as author, copyright or the original file name.

The next page describes how FIF2 solves these problems and which techniques of the old formats it keeps.