I've been working on a drawing app (Gradien Studio, working title) for a while now, similar to ibisPaint, Krita, and Clip Studio Paint. One of the things that's important with such an app is the way projects are stored, especially with a social drawing app that Gradien aims to be (in the future). It might not be important to you, but it defines the way layer and other metadata is stored and how capable the app can be with the given data.

Part 1: Examining the current formats

The first things that come to (my) mind when thinking of a creative app's file format are:

  • PSD (Photoshop Document)

  • IPV (ibisPaint Vector)

  • KRA (KDE Krita)

  • ORA (OpenRaster)

These are quite capable formats, some better than the others depending on the tasks. In fact I think that it shouldn't be an issue sticking to ones that already exist, but if we keep sticking with what already exists it's much more difficult to implement something that can't be defined in an existing file format.

Photoshop Document

The format of the beast. Created by Adobe in 1990 with the release of Photoshop, it is one of the oldest file formats that can hold layered data with up to 30k² Pixels and is designed to be interoperable with the rest of Adobe's creative suite. Although it's a proprietary format, its been used reliably in countless other apps, for example ibisPaint uses psd.c for its exporting of psd files.1

ibisPaint Vector

The format, Optimized for efficiency. Created by ibis inc. in 2011 with the release of ibisPaint, it's a format that can not only hold layered data but also keeps a log to enable creation of replays.2 It's highly proprietary and, although, I've been working on reverse engineering this format, It isn't something that can be extended and interoperable, even with the benifits of a somewhat well structured binary format.

KDE Krita

The format for the open studio. This format is loosely based on OpenRaster, which is why i'm not going into deep detail here, since it will be explained in the next format and has similar capabilities.

OpenRaster

The format for open exchange. Proposed by Boudewijn Rempt and Cyrille Berger in 2006, it's a format similar to the OpenDocument specification: "a zip file with an xml document describing the layer structure and a png image for each raster layer or an svg image for each vector layer.". The key thing about this format is that it's extensible, which makes the main challenge of implementation as mentioned before this list a bit easier. But undocumented extensions have the problem of possibly breaking interoperability, or breaking baseline.

Part 2: Interoperability

While OpenRaster seems to fit this word, its a loose definition when no longer being "Full Baseline" which extensions might easily do. So why not modify this format to our specifications:

  • Easily readable by applications and humans.

  • Interoperable with any application, even if its not the same creative type.0

  • Reasonable implementation without reinventing the wheel.

  • Precise specifications and app defined functionality.

  • Keeping an edit log for replayability.

With these modifications, this is what this new format should be:

  1. 1.

    Replace XML with JSON. This enables using ATProto lexicons/schemas and makes it interoperable in a network.

  2. 2.

    Anything can be stored. Instead of just storing raster or vector layers, enable storing anything like a blob, reducing collision potential.

  3. 3.

    Have a common set of lexicons. Similar to how standard.site defines blogs, a definition for common behavior by every app should be part of this format.

  4. 4.

    Editing logs as sessions. By using app defined sessions, the app is free to implement its replay logic however it wants while optionally implementing app defined behavior from other apps. It must provide a free public renderer.

Part 3: The Garden

This is just an idea for now, that I am still working on, and I may share more about this format's specification that i call "Garden", or internally "GRDN", in a future blog post. While I could just implement file saving in my own way its not what I want to do. I am building "Art software for the rest of us." and it requires a file format for the rest of us.