There are a bunch of fractal programs with their own file formats for storing iteration data:

- MandelMachine has MMIT
- Kalles Fraktaler has KFB
etc

It would be cool to have a standard file format that fractal programs can use for interoperability.

I propose using OpenEXR 2.0 https://www.openexr.com/ as it is licensed permissively, and is widely used / tested already.  It is flexible (supports any number of float32 and uint32 channels), with multi-image files, and deep images with variable number of samples per pixel.  The main thing is to standardize on the channel names (which are strings).  I propose these to start with (all channels are optional):

uint32 N integer iteration count
  0xFFFFFFFF is non-escaped before header metadata field int Iterations (or string Iterations, it can exceed the range of int, sigh...)
  0x00000000 is uncalculated/glitch/no-data-available.  If actual iteration values can be zero or negative, add a bias constant to each count and store it in the header metadata field int IterationsBias (or string IterationsBias, it can exceed the range of int).  the bias could be negative, this might allow you to store high iteration counts without necessarily needing two channels if the actual min/max range is small enough)
for images with biased iteration counts above 0xFFFFFFFE, split into two channels:
uint32 N0 least significant 32 bits
uint32 N1 most significant 32 bits; 0xFFFFFFFF is interpreted as non-escaped, regardless of the value of N0 (but it should also be set to 0xFFFFFFFF)
for future supercomputers, this can be extended with N2 etc...

genType NF fractional iteration count, expected to be in [0.0 .. 1.0) for float32 and half (float16), and the full range normalized by dividing by 0x100000000 for uint32. The continuous iteration count (when escaped) is N+NF-IterationsBias.  This is stored separately to avoid losing precision at high iteration counts

floatType DE  signed distance estimate, normalized such that distance to a neighbouring boundary pixel is approximately 1.0 for exterior distance estimate and -1.0 for interior distance estimate.  If there are exterior de and no interior de available (or vice versa) the missing data can be written as 0.0, but readers should also handle NaN in this case.

floatType DEX, floatType DEY directional distance estimate in cartesian form, normalized such that distance to a neighbouring boundary pixel sqrt(DEX^2 + DEY^2) is approximately 1.0.  If some pixels have no direcitonal DE the missing data can be written as (0.0, 0.0), but readers should also handle NaNs in this case.  The vector should point away from the fractal boundary.

floatType ZX, floatType ZY coordinates at the first escaped iteration.  Image should have a header attribute floatType EscapeRadius.

Orbit traps can be handled as layers with TRAP somewhere in the path:

uint32 TRAP.N iteration number at which trap was hit, see above for large iteration counts

floatType TRAP.TD distance to trap (eg an x-axis trap would have |y-coordinate|) (normalized however you like, as deep images may have tiny values (perhaps?), but should be monotonic, it could eg be negative if you take logs for more range than float32)

floatType TRAP.ZX, floatType TRAP.ZY coordinates at the trap iteration, should be normalized so that the magnitude at the edge of the trap is 1.0  (can't use just X and Y because Y is already claimed in EXR for colour luminance).

Deep images could be used to accumulate all the orbit traps hit over the lifetime of the pixel's iteration.  More research needed on this.


Feedback very welcome!  There's not much point to this exercise if the only software implementing it is KF (it doesn't do it yet, but I will work on it soon).


EDITED 2019-09-09 to add notes about string attributes for Iterations and IterationsBias, as well as allowing negative bias; added DEX/DEY spec

Linkback: https://fractalforums.org/programming/11/towards-a-common-file-format-for-2d-escape-time-iteration-data/3017/

Can you think of a way to make the format extensible, all the way up to say storing the full orbit at each  pixel or say  color = standard deviation of orbit around mean (just making that up)? A comment section which describes what is being stored?

My local KF working branch can now save and reload EXR as described in the first post (only N / NF / (sometimes) DE as KF doesn't do orbit traps yet).

Note that I edited the first post with two things, storing maximum iteration count in the "int Iterations" field in the header, and also applying a bias to iteration counts as the channel is unsigned, but normalized iteration counts can go negative.

the problem is the metadata, either you engineer some extravagant system for describing everything precisely, or you start a bit ad-hoc and come to some standardization after seeing what works in practice

-
How about describe everything in a Doc (like phpDoc) system, where you define annoations in comments? I think this is the most straightforward and standard way of writing metadata to code.

0. KFB file format won't go away for a long time, I just won't add new features to it
1. EXR is extensible in a sane way - can add additonal channels and/or metadata very easily - adding this to KFB would make the files backward incompatible anyway, not much to lose by switching format entirely
2. there is a software library (openexr) under permissive license that can read and write it, which makes it easy to use (see https://mathr.co.uk/exrtact for a tiny example)
3. EXR supports higher bit depth colour images (float16, float32, uint32) - I think you(?) once asked for 16bit PNG but EXR covers that base also (though KF only does float16 (half) so far)
4. other software might be more inclined to support EXR than KFB
5. EXR is part of industry standards for video/films/etc (eg the SMPTE standard ACES uses a subset of EXR in an MXF container)

Okay. Yes, I suggested the high precision PNG.
If I understand it's a format that allows to save image color data in addition to various other information for each pixel like iterationcount and whether it was guessed.

What about  different file for each data type ?
Like pfm for floating point data:
https://en.wikibooks.org/wiki/Fractals/Computer_graphic_techniques/2D/gfile#pfm

Also:

https://en.wikipedia.org/wiki/Hierarchical_Data_Format

I've got this working in my own fractal program and they load up into KF great. One thing I found which might not be done yet is changing the compression algorithm that is used during saving. I changed this to PXR24, which apparently will reduce the precision of f32 to f24, however I believe that it should not touch the integer iteration data. This reduced the file size of a 4K output from around 64MB for (.kfb/no compression) to around 14MB, whilst taking around the same time to save.

Another thing which I might suggest is to try work towards a common location/details file format as well. Currently, there are quite a few different formats and they all have different ways that they are encoded. I think that using a common file format for configuration, such as TOML, would allow for this data to be much more transferable. Two different files could be used, one for the image properties (width, height, coloring (possibly palette), type ect.), and one for the location data (coordinates, maximum iteration, series approximation terms, zoom level, glitch correction).