Krita and XCF

Last week, I blogged about the removal of the graphics magick file format filter in Krita, and that it would mean that we need to write directly our own support for many file formats, using low-levels library when relevant and available. And by forcing us to do this work, the support for file formats in 2.2 will rock.

Among the three mostly usefull file formats that were delivered by the gmagick file format filter, there is XCF, the file format of the Gimp. After my blog, pusling (Sune Vuorela of the debian KDE team) reminded me about xcftools, a tool written by Henning Makholm that extract information from XCF files. Despite not being a library, the code to parse XCF files is well seperated from the command line logic, and I imported it in Krita (might be a good idea to turn it into a real library ?).

As mentioned, the previous filter was not really good, we were only able to get the layers, but no masks or no composite information, or opacity, as reported in this bug 106730. And with the xcftools based filter, we can read all that information, making XCF a first class citizen in Krita. There might be some issues with composite ops that behaves differently on some cases between application, but that something that we would need to fix as well.

For the other way around, to import from Krita into the Gimp, the OpenRaster Archiving format would be the way to go.

About other file formats, Boudewijn is already working on PSD support. The last important one is GIF support, which will probably be done using libgif.

The last bit of *magick dependency is now gone from Krita

Since its birth, Krita has been depending on ImageMagick (or the GraphicsMagick fork). The original idea was to build Krita as a GUI on top of ImageMagick. When the current team (or at least its veterans) started to work on Krita, ImageMagick was only used for exporting and importing files.

But using an abstraction of file formats did not give us enough control on how the files are loaded and saved, so four years ago, we decided to have our own implementation of the most used file formats: png, jpeg and tiff. Then later, tired of having to adjust our code for each releases of ImageMagick, we turned to GraphicsMagick, a fork that claim to have API stability. But the long term plan has always being to remove the dependency, and to have our own implementation of the file formats (or to use libraries when relevant).

Things have been accelerated recently, when we discovered that recent version of GraphicsMagick crashes Krita in a very weird way, so we decide to remove the GraphicsMagick files filter, and to finish implementing the format ourselves. This has started with the PPM filter that was finished yesterday, and now I am taking care of the JPEG 2000 format using the OpenJpeg library. But this might mean that in the near future, some important file format such as Photoshop‘s PSD or Gimp‘s XCF will not be available (but there is a Gimp plug-in to export to ORA which can then be imported in Krita).