The GIMP’s XCF file format
June 19, 2006 2:59 pm gimpSo, it seems that Luis, Norman Walsh and Mark Pilgrim have all noticed that the GIMP’s XCF format is not encouraged for use with other applications.
I want to correct two mistakes here – first, the format is documented (and doesn’t source code count as the ultimate reference documentation?) and is used in other programs.
I would also like to point out that recently there has been some discussion about a general format raster file format – if there are problems with the XCF format, we would be derelict in our duty to advocate it as that future format – especially since there is already a proposal for a container-like format which is much better.
People should also take care to note the source of statements that the GIMP’s file format is deliberately undocumented. If anyone has a stake in giving the GIMP a bad name, it is Robin Rowe, who has consistently done his best to do so since taking over CinePaint (the artist formerly known as FilmGIMP) in 2002. Why he considers that the success of Cinepaint depends on giving the GIMP a bad name I don’t know, but perhaps actually releasing software regularly, and having a public and up-to-date source code repository might help your project succeed too, Robin?
For the record, I disagree (and have always done so) with the policy of discouraging other applications from using XCF. When something better comes along, we can abstract file load & save to a library, and everyone can use it. Until then, if someone wants to write a libxcf, why not? I’m all for interoperability where practical.
It is true that the XCF file format reflects some of the most difficult design issues which have been causing the GIMP problems, and which GEGL was supposed to fix – I have real hopes that a GEGL-based GIMP will release in 2007, by the way.
Update: I found Henning Makholm’s excellent xcftools – Henning took some of the XCF code from the GIMP, refactored it somewhat, and made some tools which allow you to extract a flattened png or pnm from an XCF, or to request the contents of a given layer.
June 20th, 2006 at 12:21 am
David!
Please don’t even suggest that the idea for an OpenRaster format originates with Robin Rowe. It’s my and Cyrille Berger’s idea and project and it has nothing to do with Robin Rowe. He is not the source; we are.
We would like everyone to cooperate on an OpenRaster document specification — a specification for a file format that is compatible with OpenDocument and flexible enough to work for Gimp, Krita and any other layered raster image application. Everyone, including the Gimp people, the Cinepaint people and everyone else who’s interested. This is not an attempt to
I’m working on a document that describes our plans, and we discuss our ideas pretty regularly with Oyvind Kolas and are grateful for his expert help and input.
June 20th, 2006 at 12:34 am
Hi Boudewijn,
That wasn’t my intention – my inte,ntion was to show that the idea that the GIMP’s file format is deliberately undocumented comes from Robin Rowe.
Dave.
June 20th, 2006 at 12:49 am
Ambiguity removed.
June 20th, 2006 at 12:54 am
Oops — something went wrong here. I wanted to say in the second paragraph “This is not an attempt to blacken XCF — but an attempt to come to a concensus about a real layered raster image interchange file format.”
June 20th, 2006 at 12:54 am
Thanks!
June 20th, 2006 at 1:34 am
Um, Dave… did you ask anyone from the GIMP team before you wrote this blog entry? IMO this attempt of clearing things up does more harm than good.
June 20th, 2006 at 1:41 am
FWIW, I really, really like the basic approach of using ODF is a container for the raster file format. I’m on the ODF TC, and want to also point out another bit that would have relevance, which is that we are planning greatly enhanced metadata support for ODF 1.2. It *may* use XMP, or be a richer subset.
June 20th, 2006 at 2:17 am
The problem with libxcf is that it would have to include large parts of the GIMP core. Simply because the XCF file format is so tightly bound to GIMP internals; internals that noone wants to see exposed. That’s the reason why XCF is the wrong format for exchanging image data between applications.
June 20th, 2006 at 2:31 am
Hi Sven,
I agree – libxcf would be mostly inappropriate as a solution to data interchange, but it might have made things easlier for (say) seashore or krita (or even Cinepaint) to use the format, and keep up to date with version changes – knowing that their internal image structures are going to mostly mirror ours. Plus, it would be a nice facility for someone writing an xcf2psd converter or something like that. Also, ideally, you could choose to have a handle to the native structure, or a pre-flattened bitmap from the load routine, like in ImageMagick.
June 20th, 2006 at 2:36 am
A spartan 3 page text file is an acceptable format documentation? come on…
June 20th, 2006 at 2:41 am
Matt: Yes, it’s underdocumented, I agree. But it’s a distortion of the truth to say that it’s deliberately undocumented, and that was my point.
June 20th, 2006 at 4:57 am
“and doesn’t source code count as the ultimate reference documentation?”
Only according to Microsoft…:)
June 20th, 2006 at 8:56 am
Boudewijn
I’m working on a document that describes our plans, and we discuss our ideas pretty regularly with Oyvind Kolas and are grateful for his expert help and input.
How come you don’t discuss it in create@ mailing list? 🙂
June 20th, 2006 at 6:34 pm
Alexandre,
I didn’t want to post a flimsy little nothing to the create mailing list. It’s just an initial discussion piece but I didn’t manage to finish it as fast as I’d wanted.
Actually, it’s nearly done now, and when Cyrille has taken a look at it, it’ll go to the Create mailing list — where this discussion indeed belongs.
June 21st, 2006 at 4:44 am
Brian, could you please mail me at boud@valdyas.org? I’ve finished a draft discussion document for OpenRaster I wanted to share with you, but I cannot google a working email address for you.
June 21st, 2006 at 7:37 am
It seems, as perhaps I should have guessed, that there’s more to this issue than my short post suggested. I’m happy to see evidence that the GIMP community is working to address the issue.
That said, I’d like to point out that I most emphatically do not consider source code to be sufficient or even useful documentation. To understand the source, one would need not only to understand the more than 4,000 lines of apparently XCF-related .c sources in gimp 2.3.9 but also all of the data strutures created and probably something about the abstractions behind those data structures.
What’s more, I’m skeptical that the 150 or so lines of documentation that does exist does any more than scratch the surface.
June 21st, 2006 at 11:19 pm
I acknowledge my complete ignorance of the people involved and their particular biases, but…
1. That documentation is obviously crap, or people wouldn’t need to pick apart the GIMP source code in order to write compatible libraries and converter tools.
2. Statements like “and doesn’t source code count as the ultimate reference documentation” are the complete opposite of the truth. Go read http://archive.salon.com/21st/feature/1998/05/13feature.html
Source code is THE ABSOLUTE WORST form of documentation. To think otherwise is incredibly dangerous and impedes real interoperability.
June 22nd, 2006 at 1:45 am
I have to agree with Mark. A file format specification should be completely abstracted from any actual source code. It should answer the question “how are these files made up?” and not “how would i write a program that can read this type of file?”. The source code might be useful for developers looking for guidance as to how to implement their own software, but that’s where the usefulness should end. Actually, if XCF is so intricately related to the GIMP, it’s clearly a bad format and raster image editor developers should try to agree on transitioning to a new, agnostic format a la OpenDocument.