This page describes what we’re currently working on or what we’d like to have in OCA one day or the other.
Features are ordered from closer and more likely to be implemented to further or optional.
Everything which is described here is still subject to change before it makes its way to OCA.
An 8-bit sRGB PNG file could be included in the OCA format as a thumbnail for the document.
thumbnail attribute would be added to the Root Object.
It would be a new Thumbnail Object with:
|The relative path to the thumbnail (which should be at the root of the folder and named after the OCA file).
What should be the aspect ratio and default resolution of the thumbnail?
Proposed default sizes:
How useful would it be to add thumbnails to layers?
It would be easy and useful to add some info about the color space. To be used at least for
F32 color depth with EXR files, but we may also support Rec-2020 with PNG files.
OCAZ, Zipped OCA, and/or OpenDocument
For now, OCA is just a folder; it could also be a zipped archive (using only the most common compression algorithms, Store and Deflate), with the new
.ocaz extension. Encryption, Digital signatures, and segmented/multiple volumes archives would be prohibited, following the OpenDocument format.
We could also allow for a format completely following the OpenDocument specifications, and use XML files instead of JSON.
This can be an issue though, as parsing XML in Adobe apps is notoriously more difficult than JSON; JSON is also easier to read and understand by humans than XML, and this is an important matter for adoption amongst the animation community where there are a lot of amateur developers. It’s also an easy way for humans to understand the content of the file, or even modify it manually.
We could separate the content, styles, metadata, and application settings into four separate files like OpenDocument formats though. For now, only content (and very few metadata) is stored by OCA, but we may add more metadata and application settings too for example.
It does make sense to store the metadata associated with specific objects next to them though; separating the metadata would concern only the general metadata, like the existing
originAppVersion of the Root Object.
Layer and Frame Time values
frameNumber makes it explicit it’s the number used in the filename too.
duration makes more sense when moving the frame in time, and just changing the
Maybe the layer should use
duration? (see below)
Are times relative to the container or absolute?
They should probably be relative to make it easier to move a whole layer in time. The
duration of the frames is less ambiguous than
endTime and makes it easier to offset objects in time.
New Layer type: ocalayer
We’re going to add a new
ocalayer layer type. This is a way to nest a complete OCA document into another one, as a layer. It would be similar to a
A new attribute would be added to the Layer Object:
ocaSource: string, the path to the other OCA document.
Some attributes in the Root Object of the nested OCA document are to be ignored and replaced by the values of the current document:
backgroundColorare completely ignored.
heightshould be the same as of the
ocalayerrepresenting the nested document. If they’re different, they’re to be ignored and replaced by those of the
endTimeare added the
timeOffsetvalue of the OCA Source Object.
Instead of storing the list of all the frames, we could add a new Frame Sequence Object to be used when all the frames have the same position, size and opacity, which would describe how the frames are named, or use and
.ifl file as source.
It would make the file smaller and easier/quicker to read (both for humans and APIs), in the case where all frames have the same size, position and opacity.
A new attribute would be added to the Layer Object:
frameSequence: FrameSequenceObject, the frame sequence. Default:
It would replace the
frames attribute of the Layer Object, kept for backward compatibility, which would be ignored if the
frameSequence is set.
New Frame Sequence Object
The Frame Sequence Object would look like this:
|The name of the frame sequence, which is the base name for all frames.
|How the frames are named, using these tokens:
|string or FrameObject
[layer.width / 2, layer.height/2]
|The coordinates of the center of the frame, in pixels [X,Y] in the containing (Layer Object) coordinates; the origin
[0,0] is the top left corner of the containing layer.
|The opacity of the frame sequence in the range
[0.0 - 1.0]. It must be multiplied by the containing layer opacity during the rendering process.
|The width, in pixels.
|The height, in pixels.
|The duration of the frame sequence, in frames.
* An IFL (Image File List) file is a text file used by Autodesk 3DS Max that constructs an animation by listing single-frame bitmap files to be used for each rendered frame.
.ifl file lists the bitmap files to be used with each frame. You can append an optional numeric argument to each file name to specify the number of frames of rendered animation on which it is used. For example:
; Anything after a semicolon is a comment, and is ignored.
The bitmap files must be in the same folder as the
In addition to the specifications set by Autodesk,
.ifl files used by OCA can include frames named
The advantage of the IFL file is that you can ignore the
frameNameSchema to sequence any bitmap file, and set a specific duration for each frame.
If the duration of the frame is not defined (if you don’t use an
.ifl file, or if the duration is not set in the
.ifl file), each frame lasts until the next frame (or the duration of the sequence if it’s the last frame).
Masks (and selections) could be stored as grayscale bitmaps, and associated to other layers. They could even be animated too.
That would be a new layer type,
masklayer, and the Layer Object would get two new attributes:
selection, both represented by a masklayer.
Adjustment layers (layers with effects changing all layers under them in the stack) could be a new layer type,
The Layer Object would have a new attribute:
effects, an array of EffectObject.
The new Effect Object would store the effect data, which would look like this:
|The name of the effect.
|The settings of the effect, which depend on the effect itself.
We’d officially support only the most common effects, to ensure compatibility and simplicity across applications, but custom implementations could add their own effects.
This is a possible list of effects which could be officially supported:
levels, curve, hsv, contrast, exposure, invert, balance, posterize, gaussianblur, directionalblur, radialblur, gradientmap, 2dlut, 3dlut
Effect settings could be animated (see below)
We’d like to add position, pivot coordinates, rotation and scale to the Layer Object.
When layer transform’s been added, it would be nice to have the ability to add keyframes to the position, pivot, rotation, scale and opacity values.
This raises more complicated questions about interpolation and how to store this info, but we’re also working on an OKA Open Keyframe Animation format and API which should help that!
It would be nice to be able to extrapolate frames and transform animations, with several modes:
pingpong, both before and after the animation, with the ability to choose the number of keyframes or frames as the basis of the extrapolation…
This question is related to the interpolation and keyframes format, and will be handled by the OKA Open Keyframe Animation format we’re working on.
outExtrapoplation values (OKAExtrapolationObject) would be added to the hypothetical Frame Sequence Object.