Open Formats, Open Development

It’s a specific goal of mine to make fr0st as open and accessible as possible. For instance, I want to make it easy for scriptwriters to build things that experiment and explore in new directions, and to incorporate the evolutionary result of this activity back into the core program, rather than leaving them trapped in the script editor forever, treated as second rate citizens.

With this kind of goal, it’s important that the file format of the flames themselves remains open and accessible to be extended by anyone. This is done by remaining as agnostic as possible about the meaning of each particular element in the parameter set. it’s up to the underlying renderer (flam3) to decide what to do with each of them, so if a particular script wants to incorporate additional data into the flame files, it can easily do so.

I’ve always believed that data should be kept packed together as closely as possible. I can’t stand the thought of storing a piece of data that needs specific information outside it to be interpreted properly.

Let’s look at some examples:

If you were to make an animated sequence of flames with a script such as apophymator in apophysis (both of which are good pieces of code, don’t get me wrong), you have no way to store information about keyframe lenght in the frames themselves. This is not a big problem when the intervals are regularly spaced, but can soon become burdensome if you’re trying to create something more elaborate. Why not store this data in the flame file, through a special attribute that can be safely ignored by any code that doesn’t know what it means.

Take the case of post-processed flames. It’s a headache that you can’t keep just the flame file, but also need the finished image and an exact sequence of steps that were applied during post processing. Otherwise, you can’t reliably produce the same output from the bare parameter file. What if there was a script that programmatically invoked image processing routines from a graphical library after your flame has finisehd rendering, based on data you can specify within the parameters? I’m not about to implement such functionality, but the door for this kind of thing is open.

You can also store info such as what renderer a particular flame was designed for, what script version produced it, etc. In a world where different fractal flame implementations are drifting apart and introducing small incompatibilities in how they handle coloring, xaos, etc, this kind of thing might unfortunately be needed. In the end, a format where the most useful and popular features win, represents the true spirit of open source much better than any closed, top-down desing I (or anyone else for that matter) could come up with.

These ideas are larger than any individual people working on them. Keeping fractal programs open (truly open, not just GPL’ed), is in the interest of us all.

Advertisements

5 Responses to Open Formats, Open Development

  1. David Marso says:

    I might explore this idea of replicable Postprocessing.
    I am an ImageJ devotee!!! Awesome aspect is that it has a Macro Recorder so one would simply turn on the recorder prior to post processing the fractal. Do whatever code cleaning and documentation and then embed the fractal flame and the ImageJ macro in the Image. ImageJ is a free extensible Image processing library written in Java. It might be an excellent framework for pursuing this sort of concept!

  2. xcopfly says:

    Hi,

    Just found your program tonight. Are *images* generated by Fr0st forced to be GPL or copylefted CC? Would I be able use CC0, a permissive license, or keep the full copyright on a Fr0st-generated image file? (I try to keep my Web site as CC0 as possible.)

    Thank you, Dan

    • xcopfly says:

      “(I try to keep my Web site as CC0 as possible.)”

      and one of the main purposes of my site (www.xcopfly.com) is the creation of CC0 content.

    • Vitor says:

      The copyright of images you generate with fr0st is yours to do with as you please 🙂 The terms of the GPL only apply to programs derived from fr0st’s source code, not the images produced under normal use of the program.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: