Archive

Posts Tagged ‘Graphics’

Crazy Lightning

9 December, 2009 Leave a comment

Advertisements

Discussing Krita, digital painting with David Revoy

6 December, 2009 9 comments

For the next releases of Krita, we decided to pick up a specific artist, with a specific work flow, and to implement and fix the issue that he needs. For 2.2 (and probably 2.3), we have chosen David Revoy who has come recently to fame for his involvement in the durian project of the Blender project. Since he lives in Toulouse, and since I still live in Toulouse for the next two weeks, we felt it was a good opportunity to met and to talk about what is Krita, and to get a feel of what he needs.

On Tuesday, after work, I went to his apartment. First he showed me a bit what he needs, especially in a patch to the Gimp that brings much needed feature for him, like the brush that mix its current colour with the content of the layer, or the flow setting (that is similar to krita’s “wash” and “build up” modes, except with a fuzzy settings, while Krita is binary). We also discussed the performance issue, especially comparing to Photoshop. Most digital artist would draw their image at a higher resolution than needed, for instance, if you need an image of 1000×1000, then you will draw it at 2000×2000 or even more, which means that you also scale the brush you use, which means that the brush engine needs to be efficient. While more polishing, like more clever shortcuts and easier setting of painting parameters is a must, efficiency is clearly the biggest issue we are facing in Krita, and the one that will need the most work, the good thing is that we already many solutions that will help us to improve that.

Then I installed Krita on his computer (using the ubuntu KOffice backport, I do not know if I missed something, but I found it extremely hard to add the backport to Ubuntu’s software installer). And I showed him the different paint engine of Krita, especially the new one from Lukas, and I talk to him about the goal of Krita, which is clearly focused on digital painting, and image creation. This is where we can have a clear separation between the different 2D graphics application in the open source world, with Gimp having a focus on image manipulation, mypaint being a scratchpad for quickly drawing, and Krita being focused on digital painting. This does not mean there should not be any features overlap, like Krita having a set of filters for image enhancement. It is just that the focus of the user interface and of the development is different.

This led us to discuss on what he can do to help use make Krita the application he would want to use for his artwork. What we need most (a part from more developers 😉 ) is testing. While 2.1 is a nice release, it is still far from bugs free, but what is also important is testing of the user interface and of the features, we need to know what is lacking. As a developer, when I draw I tend to bend myself to what Krita can do, while it should be the opposite, it is up to the application to fit the work flow. We already have two artists running the development version of Krita, but more is always welcome to get more diverse opinions.

We also talked on funding development of open source software, one area where the Blender Foundation is very successful is to make movies with Blender, this is very good for advertising the product, since you can show awesome end-results. But it is also very good since developers and artists are working together on the movie, the developers fixing bugs and adding needed features, while the artists provide feedback. The Krita pledgie is one step in that direction. David was thinking that targeting windows users could boost the fundraiser campaign, as apparently many artists are having remorse on pirating proprietary software and might be interested in helping a cheaper alternative, but it is clearly not the primary focus of Lukas work, first we have to make Krita ready on Unix, then other platforms will come.

Categories: Krita, Open Source Tags: , , ,

Blue Cloudy Sky

5 December, 2009 2 comments

Desert

4 December, 2009 Leave a comment

About Krita and Gimp, in default installation

26 November, 2009 16 comments

The removal of GIMP from the default installation of Ubuntu has raised quiet a stir. And as drawn quiet a bit of advertisement for Krita, as some people suggested the use of Krita instead, but for no good reasons, since Krita is not a good replacement for GIMP as a default installation.

You have to consider the use case of the default installation, since the Ubuntu people are trying to make is a distribution that is usefull for the average users, the default installation need to cover the need of the many. And what most people want to do with their picture is to classify them, do light weight retouching (for instance, adjust the brightness, remove red eyes) and then print the image or send it on the Internet. Surely, both Krita and GIMP can do it, but they have way more features than what is needed for most users. As Sven Neumann, one of the core GIMP developer, said GIMP is a high-end application for professionals, and so is Krita. Some might think that Krita has a GUI that is more friendly to the beginner, but that is not the problem, it is still packed with features that are of no interest to most users. And there are tools that are better suited to accomplish the task of those users, this is why a pictures collection management tool, such as F-Spot or Digikam is a much better choice, it covers the main usage of the majority of users. Even if Digikam is designed for professional photographer, I still think it scale nicely to average users. And when the user want to do more with images, he can just go to his favorite package manager, and install GIMP or Krita.

OpenGTL 0.9.12 and Shiva noise

20 November, 2009 Leave a comment

OpenGTL 0.9.12

Earlier today I made a new release of OpenGTL (download page), version 0.9.12, for that release 23 tasks were completed, the main changes are:

  • Fixing thread safety issues at run time.
  • Progress report.
  • Many new mathematical functions for the Shiva standard library.
  • Replacement of the Shiva kernels random functions.
  • OpenGTL is now compiling and running on Mac OS X.

The first two points are important changes for krita, since the first one meant that with the previous releases we had to use mutex while executing Kernels, preventing to benefit from multi-core. The second one means the user can see something is happening in Krita when a filter is processed.

Random functions in Shiva

This new release also break the Shiva language compared to previous release, I try to prevent that, but since the language is still very young it was bound to happen. In previous releases I quickly introduced a rand() function, because I wanted to write a perlin noise generator. The problem with rand() is that it does not take a seed parameter, meaning that the function use the global seed, meaning that two consecutive call to ther perlin noise generator kernel gives two different results, without any kind of control. For graphics, we need to make sure that the result are reproductible, so now in 0.9.12, the function rand() has been replace by one that takes a seed parameter rand(output int seed).

Such a function is usefull at init time, to construct random structures, like those needed by the perlin noise. But this is not sufficient, we also need a random function that can be used while processing a pixel, and one that would always return the same value for a given pixel and a given seed, for instance to write a salt and pepper noise generator.

The problem of the rand(output int seed) function is that it works by incrementing the seed parameter, so that next time you call it, it gives a different result, so as long as the call are made sequentially it would work fine. But in case of Shiva (or Krita, for that matter), we cannot guarantee that those call will be made sequentially, and it is not possible to keep a value between the computation of two different pixels. Because we might just be interested in generating part of the image, or we might be executing the kernel in a multi-threaded environment. To solve this problem, about six monthes ago, in Krita, we developed an algorithm that takes the pixel coordinate and the seed, and return a pseudo-random number. For 0.9.12, I copied that algorithm in Shiva, giving birth to the second new function for random number generation, which is rand(int x, int y, int seed).

The code for the salt and pepper noise generator is:

kernel Noise
{
  void evaluatePixel(out pixel4 result)
  {
    int x = result.coord.x;
    int y = result.coord.y;
    for(int i = 0; i < 3; ++i)
    {
      result[i] = frand(x, y, 32);
    }
    result.setAlpha( 1.0);
  }
}

The code for the perlin noise generator is slightly more complicated and can be watch in the opengtl mercurial repository.

And the resulting images, salt and pepper noise on the left, and perlin noise on the right:

 

Shiva generator, krita and metaball

24 September, 2009 1 comment

One of the new thing of the upcoming 2.1 release for Krita (among improved stability) is that the OpenGTL library is now even more integrated, which makes it even easier to write cool filters or generators for Krita.

Today, I will speak about generators. Since Krita 2.0, there is a special kind of layers in Krita: generators, it’s like a normal layer, except that the pixel are generated automatically. In 2.0, the only generator available was a plain color generator. In 2.1, you can write your generator using the Shiva language.


kernel Singleball
{
const float radius = 0.1;
const float ringradius = 0.05;
const float ycenter = 0.5;
const float ycenter = 0.5;
const float2 center = { IMAGE_WIDTH * xcenter, IMAGE_HEIGHT * ycenter };
dependent float pxradius, pxringradius;
void evaluateDependents()
{
int image_size = min(IMAGE_WIDTH, IMAGE_HEIGHT);
pxradius = radius * image_size;
pxringradius = ringradius * image_size;
}
void evaluatePixel(out pixel4 result)
{
float2 vec = result.coord - center;
float angle = atan2( vec.x, vec.y);
float r = length(vec);
if(r (pxradius + pxringradius))
{
result = outsidecolor;
} else {
float v = (r - pxradius) / pxringradius;
result = (1.0 - v) * ballcolor + v * outsidecolor;
}
}
region generated()
{
region reg = { 0, 0, IMAGE_WIDTH, IMAGE_HEIGHT};
return reg;
}
}

The value of the input pixel is computed in evaluatePixel, while evaluateDependents is used to initialize some constants.

The actual version of this kernel can be found here, the full version contains configurable options for the center and radius.

Then to use your generator in krita you just need to copy it to ~/.kde/share/apps/krita/shiva/kernels. As you can see, I have made a metaball generators, integrated in krita, with its option widget: