[CinePaint-dev] Open File Format for Raster/Bitmaps Graphics
rower at movieeditor.com
Tue Mar 21 05:25:33 CET 2006
Your invitation was cross-posted to the GIMP developers list. Please
note our list has a published policy against cross-posting there.
> Firstly, I invite developers of The Gimp, Cinepaint, Krita and
> any other projects interested in talking about an Open File
> Format for Raster/Bitmaps Graphics....
Thank you for your invitation. Unfortunately, I can't give much time to
participate because I need to focus on Glasgow and img_img.
You may not be aware that the topic of an open image file format has
already been discussed on public lists at length after I posted our spec
for a new open format called CPX:
When I wrote that I'd been thinking about the need for an open image
file format for some time.
The reasons to move CinePaint away from XCF became apparent to everyone
when Sven at GIMP objected to changes made to GIMP's XCF format that
enabled CinePaint to store 16-bit images, but that GIMP could not read.
(That fork actually predated CinePaint, had been made in gimp.org CVS
when Film Gimp development was hosted there.) The XCF format was
deliberately undocumented by GIMP, a proprietary format despite being
open source. As such, it's hard to do anything with it.
After my announcement of the CPX draft spec, Sven said that GIMP had an
unannounced format of XCF2. That caused a stir in the GIMP community
because it was the first they had ever heard of it. It's in the 2003
archives of the CinePaint and GIMP developers lists if you want to
research the CPX and XCF2 discussion yourself. In brief, the GIMP camp
thought the format should be XML compliant no matter what, while I said
no way would we be uuencoding rasters.
I have not built CPX yet. Our focus shifted to building our next
generation architecture Glasgow. However, CPX is delayed, not abandoned.
I haven't touched the spec in a long time, but it's still pretty close
to what I have planned.
Key CPX design points are: as human readable as practical, easier to
parse than XML, inline blobs, raster and vector layers, and meta-data of
all kinds. It needs to be compatible with a superset of JPEG, PNG, DPX,
TIFF and OpenEXR format features, but no lossy compression.
More information about the kimageshop