| Home | Press | Mailing Lists | Documentation | Screenshots | People | SourceForge | Downloads |
CinePaint has some unique internal file formats not supported by any other program
None of these formats are documented by CinePaint, and we don't know much about them because they predated the current development team. These seem to be modified (incompatible) versions of GIMP file formats, enhanced to support 16-bit color depth.
Note that CinePaint and GIMP files are incompatible with each other -- despite the identical file name extensions. CinePaint can't presently read GIMP files, and GIMP can't handle CinePaint files.
Our approach to fixing this mess is not to try to update these formats, but to replace them with a new file format that is easier to code, self-documenting, more extensible, and has better performance. CPX (CinePaint XML-tagged format) will replace all these different file types with a single file type (.cpx).
The CPX format was inspired by the beautiful simplicity of PPM format P6, but with the enhancement of embedded XML-like tags. Like PPM P6, all CPX tags are text and the raster data is binary. The CPX format was conceived by Robin Rowe and improved by the input of others.
<CPX
version=0.1
cinepaint=0.18>
<IMG
type=layer
width=1828
height=1102
depth=16u
raster=RGB
compress=none
bytes=12086736
blob=XXXXXXXXXXXXX...[12,086,736 raw bytes]...XXXXXXXXXXXX>
The above file is made up of two objects: CPX and IMG. Each object is made up of attributes. Object names are always upper case. Attributes are always lower case. Each attribute has a name and a value. A whitespace token after the last attribute value in a object is legal.
Only blobs (rasters) can be compressed -- not the whole file. The metadata is kept as plain text. In other words, CPX always writes the header text as is, but (optionally) compresses the body.For typical movie image rasters a few extra bytes of size due to uncompressed text tags will be insignificant, but make it possible to quickly read a file's internal metadata without decompressing the file first. It also means an application that doesn't have a suitable decompressor can at least report the image attributes.
No, standard XML isn't a practical format for a raster image format. XML wasn't designed for that. CPX embeds raw rasters. Doing that is a non-standard with XML. CPX is in a sense inside-out XML. It embeds XML tags inside a binary image file, not the other way round. CPX is inspired by XML, not a slave to it.
Using CPX will be a very different experience for production programmers than what we have now with XCF, a file format created elsewhere with a deliberately undocumented internal structure. XCF requires production programmers (e.g., Python/Perl scripters) to read our C source code before being able to write any scripts to manipulate XCF images directly (that is, without CinePaint). That's hard, and nobody does it.
Writing a CPX file from a script will be almost as simple as spewing a PPM P6, but with a much richer feature set and no need to study a spec somewhere in order to understand how to write a valid file. Simply create a sample image in CinePaint with the sort of attributes you need, save it, pop it open in an editor such as vi to view the internal field layout, then reuse the tags to code your own series of similar image files (that is, movie frames) from scratch in your favorite language. This will enable scripters to do tasks such as write a series of color wedges to do testing in filmout.
In response to our announcement of CPX, GIMP says that they have been working (secretly) on an XML-like image file format of their own for three years. No details have been released, although it reportedly has a different design approach. CPX was announced on June 7, 2003, in a post from Robin Rowe to the cinepaint-developers list, not long after the fundamental design was conceived. That post gave an example of the file format design. A preliminary spec (this web page) soon followed. Implementation is getting underway. We have a very different schedule than GIMP and different design goals.
CinePaint will offer a command line tool something like ImageMagick's 'convert'. Our new tool (still in development) is named 'raster'. It will support all the file types that CinePaint does by using the same file handler plug-ins. Raster is a small separate utility, not CinePaint running in (the currently broken) non-interactive mode. Raster will just convert, not support the full CinePaint feature set.
No, CPX does not contain ASCII-based rasters. In other words, CPX is not like the PPM P3 format.
In the interest of efficiency, and in recognition of the fact that x86 has become the predominant renderfarm platform, CPX rasters are stored by default as Intel byte-order, not network byte-order. CPX rasters break the convention that data be kept in network-byte order.
Yes, multiple layers no problemo.
'<CPX' could serve that role. It isn't clear yet what other attributes may go there. Perhaps attributes relating to provenance.
Closer tags aren't that great. With HTML parsers some implementations drop the closer tag, and all sorts of ugliness has been introduced into browsers as a consequence. If a parser doesn't find a closer tag, what should it do but ignore it and press on? If they can be ignored then closer tags might as well be dispensed with entirely.
Unlikely happens pretty soon when handling 12MB images and data sets in the terabytes. To be reliable, data in blobs would have to be escaped to prevent misinterpretation of an unintended closer tag. That would make a mess in the parser and kill performance reading and writing blobs. Blobs should not have to be pre/post parsed by the parser.
No closer tags.
A blob could be anything binary. What other things may be blobs is undecided.
It is the tags leading up to a blob that give context. A blob all by itself is meaningless.
A blob must always be immediately proceeded by a bytes field. Failing that is a serious error and the parser should be expected to return with a warning it can't proceed, and not to press on. There may be an optional "repair broken file" mode where the parser continues as best it can.
The order of most attributes is not constrained. That is, width or height may come first. However, the type attribute always comes first after IMG so the parser knows which IMG attribute dictionary to load. A blob (if any) is always the last object in an IMG.
By default all attributes are zero (or blank for strings). In the case of the width attribute a zero would mean an error -- and most likely be detected in the image opener, not the parser itself. Other attributes being zero might not cause complaint. If an attribute is missing, but zero is a valid setting, there may be no warning.
Attributes that the parser doesn't know (and has no matching internal structure C variable to assign it to) are skipped, but that should warn.
Currently, no. Likewise no to multiple blobs in one IMG.
Something like this:
<IMG
type=mask
.... >
CPX is not, and can not be, a spec for a true text file. CPX
is as much a true binary file as a PPM P6. What's interesting
about CPX is it has a
self-documenting XML-like internal field structure. Simple parsers
can read or write it. And, humans can (mostly) understand it.
The last character as > requirement is a sanity check -- a warning, not a fatal error.
Yes, that seems about right. Thanks for the suggestion from Lutz Latta.
Probably not for layer, but it begs a harder question about text strings. If we allow attribute data strings as UTF-8, how are they best delimited?
Yes, on the theory that the CinePaint parser will map them to C variables of the same name (e.g., from "width=1828" to 'int width=1828;') Attributes are case sensitive and may use underbars since they aren't allowed spaces.
Spaces preceeding or trailing the = are illegal. For example, "width = 1828" is an error.
Yes, thanks again to Lutz Latta.
First release of CinePaint CPX plug-in anticipated summer 2003.
Rapid design methods have certain advantages, but expect some changes. CPX is still evolving.