Why OpenRaster is needed ?

I want to answer to people who people (like for instance in comments in the last blog entry of Boudewijn or a comment in a nice article on the subjet from newsforge or from various people with whom I have talked about the issue) think that with OpenRaster we are reinventing the wheel, and that we could use an existant file format and extend it for our own use.

Why not PNG ?

Well PNG is a really nice format. But, it only support a few colorspaces (if my memory serves me well it doesn’t support CMYK, but only Gray, RGB and index in 8bit and 16bit), it doesn’t have layer (thought we could use MNG for that). It’s a format with few features, which means that is very easy to support it.

Why not TIFF ?

TIFF would be a better candidat than PNG. It support more colorspaces, and you can add more of them. You can have layers (somehow, even if it’s not clear in the specification if it’s is allowed). It’s extensible, in fact TIFF is some sort of filesystem, so you can add new type of files inside the TIFF. But a lot of his extensions are undocumented, for instance, when you export a TIFF from photoshop

But, we also want something clean and documented, and who will be lead by an independent and free organisation (unlike TIFF for instance).

Why not anyother lossless binary format ?

I must confess, I am not a firm believer of open (or free software for that matter) source software, I care about software that works. But when it comes for file format, I want them to be open, fully documentend and extensible, for the obvious reason than no one should be forced. And no binary format allow that.

Why are there so many image file format available ?

The answer is, because it’s really easy to create a bitmap file format.

(byte 0 -> 3) width
(byte 4 -> 7) height
(byte 8 -> 8 + width *height *4 *2) data stored as CMYK 16bits

Et voila, there you have a file format for 16bits CMYK images. So this is the very reason why there are so many image file format. But that doesn’t mean that there is one that fits well our purpose.

So, we are not completely reinventing the wheel

Each image file format have a purpose, and few of them are successfull, PNG and JPEG are the two good example, the first one is very efficient if you want to share high-quality graphics, and the second one if you want to share pictures as you can find a balance between quality and size. But none of them can achieve interoperability between bitmap applications.

Plus, OpenRaster will be based on OpenDocument which means we will benefit from its infrastructure. And we will use our own experience with the current file format of krita which share a lot of common points with our proposition for OpenRaster. But we need some reliable standard to be able to interoperate with other application wether it is the gimp, cinepaint, scribus or inkscape.

And we really hope the Gimp people and the Cinepaint and any other open or close imaging software will join us in our effort for a format allowing interoperrability, it’s the only way to make that fileformat successfull. Dave Neary in a recent blog entry.

I invite you to join the discution about the format on the create mailing lists.

Annoucement of krita-plugins 1.5-2

Here is the secound release of krita-plugins, it includes bug fix for the blur and unsharp mask filters. And I have also remove the red-eye tool considering the many problems some of you had with it.

You can download it from the kde ftp servers or access to the kde-apps page.

The Kross scripting bridge

While we have been trying to advertise kross, we have been from being successfull so far. But I think we are making some progress lately, so I will speak once again about kross.

What is it ?

The Kross scripting bridge to embed scripting functionality into an application.
abstract API to access the scripting functionality. Here are some of it’s key feature:

• kross is independent of the interpreter, it currently supports python and ruby, but kjs/kjsembedded is planned and maybe java too

• Qt/KDE based, so use the extended techs both spends. It’s a very important poin, kross is not dependent on libkoffice, from discution I had on irc, it seems that among the few people aware of it, they believe that it can only be used in a koffice application.

• integrate nicely and easily as powerfull scripting system into any kpart application (it’s less easily and nicely if your apps is not kpart based)

How to use it ?

It’s easier, if you are appplication is kpart based, as in this case, you can use the kpart plugin mechanism and follow the tutorial here. The hardest part is to define the API you want to expose to your users, but it is common to all scripting engines.

Where to find more information about it ?

It’s funny that while we fail to make the KDE and KOffice developers community to be aware of what kross is, its fame has spread outside the boundaries of KDE, with a post in python’s mailing list.

But the current best source of information is kross.dipe.org.