Archive for June, 2007

Early in Glasgow

So I arrived today in Glasgow, a little bit in advance for the Akademy, but there was two reasons for that, a less expensive ticket and that leave me sometime to visit the city. So here is a first glance:

Ok I am a bit unfair, but that factory stroked me the first time I saw it, I was looking at a nice view, some trees in the background, a brick house in the foreground, and then I walked further, and among the trees there was that factory. And somehow I like that picture, and it’s possibly a good summary of Glasgow, a mix of traditionalism and industrialism.

But to be fair, the city center, or at least what I have seen today, looks more like this:

That’s the city hall, and around it, you can see a lot of similarly looking building. And one last picture, a view from the Euro Youth Hostel where the most of us will be sleeping, and with an extra bonus the only ray of sun I got during the day:

And unfortunately looking at the weather forecast, it’s going to be rainy ! And good travel to you !


Drawing and Expansion, a new usefull filter when coloring

23 June, 2007 3 comments

Troy asked us in a general questionnaire about Krita if we had any good image made with Krita, which reminds me that I haven’t taken the time to do any real playing with Krita since so long that I can’t remember when. So, instead of doing more usefull work (like a summary for an article, cleaning my apartment, and walking outside in the sun). I took one of the last comic I bought (Orbital for the french among you, very good stuff, the background of the universe is a little bit cliché, but the story is quiet good) with really gorgeous drawing. In other word, really good stuff if I want a decent end result.

The first part is to draw the draft, for that one I did proceed in three steps, first with the line tool, I did draw the general shape of the space ship. Then using a second layer, and the free hand tool, I draw the main lines, then for the last draft, I put the position of the details.

Then the outlines is very close to the last draft, but with much more nicer lines, and with some reworked details.

Then comes the coloring and new filter for Krita.

When coloring an image, I usually change the color of the background to a color that I know I won’t use, it’s very handy to quicly see where you haven’t colorize, even if in this case the red background hurts the eyes.

To colorize this image I made an extensive use of the fill tool, the problem is that as you can see on the left image, there is a void between the outline and the color. It’s very annoying to fill by hand, you can spend a lot of time. So the solution would be to have the color expand on the transparent part of the image, it’s very similar to dilate, but instead of having lightness replacing darkness, it’s opaque replacing transparency. That’s why the filter is called “Expansion” and not “Dilate”, to avoid confusion. You can see the end result on the right image, only small retouch are needed to finalize the coloring.

One of the main characteristic of the image I used as source of inspiration was the use of small lines (I call them claws) to give the feeling of depth, I made a poor attempt to mimic them on a last layer.

The background was done by filling with a near black color and the stars are done by clicking randomly on the layer (now that I think of it, it would be a nice candidate for a script).

XMP vs RDF or RDF vs XMP

22 June, 2007 9 comments

This is an answer to a comment from Bruce on my previous post, and the reason why I favor more XMP than RDF; at least at the moment. I will start by saying no decision have been taken on whether Krita should be “limited” to XMP (or RDF), or whether OpenRaster will be using XMP instead of RDF.

XMP is subset of RDF

So XMP is a subset of RDF and doesn’t support all the features of RDF, and it’s using an older version of RDF. I can understand that it makes it harder to use a RDF parser to manipulates XMP data, but from my point of view it’s hardly a problem, as long as XMP allows to do everything I want to do in metadata in Krita. Then, I would add that supporting XMP is important because it’s quiet well established in the graphic world.

XMP is not fully opened

That said I shared the same wish as Bruce that Adobe would open up more the XMP specification. But the real reason behind the current “embrace” of the Open Source world for XMP is that Adobe made the first step. While until very recently the XMP Spec was only available with a package that only Adobe could distribute, meaning they could shut down the access to XMP at any moment. But with their recent change of licensing policy, it makes XMP attractive to open source application. While adding support to XMP is unlikely to change their mind on opening more the specification, not supporting it is clearly showing Adobe that we don’t care, and then why should they care ?

I also have serious doubts that if I found something lacking in a W3C specification which is as likely to happen than in XMP, they would even bother to listen to me 🙂 So for a miserable ant like me it doesn’t make a real difference.

So why, even with that bad point, I still prefer XMP over RDF ?

The first reason is that I still don’t understand the full extend of RDF (after having spending quiet some times digging on the w3c or in the web), which either mean I am completely stupid or that it covers too much. While XMP is designed specifically for multimedia documents, and it has everything needed for handling the associated metadata. And I much more favor simplicity, and having more specifications instead of one that suppose to rules all the other.

I am also missing something from the Exif and IPTC schemas I found for RDF (unless I didn’t see something), they don’t defines the types of each fields.

XMP is vastly used in the graphics world

To finish, the main reason why I consider it is important to support XMP is that there is an increasing number of files which includes XMP metadata.

Krita and Metadata

21 June, 2007 4 comments

Images are not pixels alone, they include metadata. Whether they are automatically generated by a system, for instance every digital camera saves information about the condition under which a picture has been taken, some other metadata are created by the user, including, for instance, a description of the content of the image so that it is then easy to find it again in a search engine (think about Strigi or/and Nepomuk).

It might sounds like I am telling banalities, but today one of my fellow Krita developer asked me what I was doing those days, and then after I answered that I was, among other things, working on KisMetaData, he was a little bit puzzled by what the use case could be, the second thing is that metadata in Krita has always been less than suboptimal, we were more or less trying our best to not lose them, but even at that we were failing (for instance IPTC tags in Jpeg, and most metadata information in PNG or TIFF, sometimes because of lack of real standardization and/or lack of support in the files libraries). And an other problem of metadata in 1.6 is that the engine was closely related to Exif, even if it was extensible beyond what Exif supports.

And thanks to the recent release of XMP under BSD by Adobe, the possibility to use XMP in an open source application has become a near future reality. So I recently rewrote the metadata engine of Krita to more or less follow the capabilities of XMP.

And I also worked on a metadata editor. The goal was to have something extensible and customizable (like shown in Step 4 of Adobe’s XMP presentation), so this is done by using one possibility of Qt : load ui files created by the Designer at run time without the need to build it. Associated with an XML file which associates tags to widget of the ui file, and you have what I call “a metadata editor skin”.

So currently, the new metadata framework in Krita goes beyond what was offered in the 1.x series, as it supports Exif and IPTC in Jpeg, it comes with an editor, and is a great base for the future.

A lot of work still need to be done, for instance to save and load metadata in other fileformat (PNG, TIFF, OpenEXR) and also finally saving and loading to XMP (but for that I intend to wait a little bit, as no solution is mature enough for now and next Krita release is still far away). And in the editor, I am a little bit annoyed by how some of the Exif value are displayed, like for instance in the above screenshot for the “Max aperture” tag which should appears as “f / 2.8” and not “280 / 100”. And it’s currently unable to edit list of tags, like a list of authors. Currently, metadata is associated to a layer, and it raises two questions whether image should also have their metadata (and if for instance the author field should be automatically edited when adding a new layer with an author metadata tag) and their is also the problem of merging two layers, what should happen to the metadata tags ?

KOffice 1.6.3

I am pleased to announce that the latest bug fix release of KOffice 1.6.3 is out. You can read the full announcement here. For Krita, this release includes, hopefully, a completely fixed transform tool, and some improvements in the filter dialog (that I plan to remove for 2.0, who likes to preview the result on a 100 by 100 image while owning a 1280 by 1024 screen, or even more for some of the lucky guys around).

Dynamic paintop : introduction

6 June, 2007 1 comment

Since I saw dynamic brush in Corel Painter, I have been willing to get something similar to Krita. Basically, it’s a paint op which gives the user control over all the parameters (size, orientation, colors etc) of the brush, depending on the input (pressure, time…), the information used for controlling those parameters are what I call “programs”. More simple paint op as you can find in current stable version of Krita offers a much more limited selection of parameters.

There is something else I want to provide with the dynamic paintop, until now, Krita’s paint op are using what we call potatoes stamps, for each stroke, some sort of mask is put on front of the canvas, and the color is updated according to the transparency, that works pretty well to simulate a pen, or a single bristle, but not a realistic paintbrush. So something, I am playing with in the dynamic paintop is simulation of bristles.

The screenshot bellow show the result of using two types of bristles (with big spacing to see clearly the bristles, and with small spacing to see something closer to reality) with two different programs ( one which rotate the bristles around the center of the paintbrush while the hand move on the canvas and one which rotate the bristles in the direction of the drawing). And each bristle have a randomly affected color.

While the above drawing was done with the mouse, the dynamic paint op is aimed at using the full power of your tablet.

But I have still quiet a few problems to solve:

  • performance, even when using the more simple shape (potatoes based), the dynamic paint op can’t be as optimized as an hard coded paint op, but it’s even worse with bristles shape, who are drawn by painting multiple potatoes on the canvas
  • user interface, the user interface is divided in two parts, one is visible on the screenshot above and it’s about selecting “programs”, the most annoying problem is to find good short names for the programs shipped by default in Krita, the second problem is designing an user interface for editing those programs
  • color, I have yet to see how color should be affected by the programs

Filters as script in Ruby/Python/Whatever for Krita

4 June, 2007 2 comments

Krita support scripts (in python and ruby) since 1.5 thanks to kross, but one things that was really missing (beside performance) was tighter integration with Krita, I mean, in 1.5/1.6, there is a docker with a list of scripts, and you click and it does ‘something’, but what I want is the ability to write filters, tools or anything else like in C++ but in Ruby (or in python if you really have to). The anything else part is mostly done if you use some Qt4 bindings, for instance it’s already possible to write a new docker in Ruby/Python and it will behave like a C++ plugin (I should try to write a color selector in ruby just for the fun of it). And now, it’s possible to write a filter which will appear like any other filter in Krita’s filter menu.

require 'Krita'
require 'KritaFilter'

def scriptProcess( src, srcTopLeft, dst, dstTopLeft, size, config )
 for i in 0...size[1]
  itSrc = src.createHLineConstIterator( srcTopLeft[0], srcTopLeft[1] + i, size[0] )
  itDst = dst.createHLineIterator( dstTopLeft[0], dstTopLeft[1] + i, size[0] )
  while (not itDst.isDone())

The only real drawback of this is the speed :/ But I am know we still have some room for improvements in the bindings, so not everything is lost, and if Krita provides enough high level primitives it shouldn’t be much of a problem, and then if someone likes to apply first a blur then a sharpness filter (in fact, that’s already possible since 1.5/1.6 but in a less cool way), he could create a filter script, and he wouldn’t notice the speed difference.

Now I need to do some polishing, and also to allow to get script tools.