Posts Tagged ‘CTL’

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:


OpenGTL 0.9.8/0.9.9, GTLDesigner 0.9.1, libQtGTL 0.9.0 and shiva-collections 1.0

Today, I made a bunch of releases related to the OpenGTL project. Ranging from the main library, to some utilities and wrapper for Qt applications.

The main library comes with two version one for llvm 2.4 (OpenGTL 0.9.8) and one from llvm 2.5 (OpenGTL 0.9.9), the two main improvements are:

  • a new memory management model, so far each time an object was created it was allocated in memory, and since most objects have a very short life time this was leading to excessive computational time, since putting all objects on the program stack was such a nightmare to manage correctly, I simply started to use a shadow stack with preallocated memory, this is less efficient than using the program stack, but gives massive speed improvement compared to allocating memory through the system
  • a new kernel collection system, the previous system for collection of kernels wasn’t practical to use and required compilation of all kernels at load time, which is very unefficient. The new one was written while doing at the same time integration in a real world application, aka Krita.

libQtGTL is a library that provides wrappers classes and configuration widgets for Kernel for use in Qt applications that want to use kernels, the screenshot below show an exemple of such use in Krita:

From now on, I also start to ship Shiva kernels in an external tarball, in shiva-collections, the goal is to update more often that tarball than I do update the library. It contains the examples that were available previously in OpenGTL tarball, and also some new effects, such as the calleidoscope:

All this is available at OpenGTL’s download page.

OpenGTL 0.9.6/0.9.7

30 November, 2008 2 comments

Since llvm 2.4 has been released a few weeks, and since I have made a lot of improvement in the libraries, it’s about time I make a release of OpenGTL. So a twin release, 0.9.6 for llvm 2.3 and 0.9.7 for llvm 2.4.

The main changes are:

  • Lot of bug fixes… too many for me to be not lazy to make a list that no one would read… But among other things the conversion between types is done in a much more nicer way.
  • Library support, and start the standard library in OpenShiva
  • Add examples of Shiva kernel
  • Not really a feature but the libraries are now licensed under LGPL version 2 or later (instead of just 2, I hope I won’t live to regret that decision…)

You can download it here or get OpenSuSE package (10.3 or 11.0)

OpenGTL 0.9.5 and Darkroom 1.3

2 September, 2008 1 comment

Today I am making a joint release of OpenGTL and Darkroom, for the main reason that I have made quiet a lot of bug fixes in OpenGTL that are needed to get a fully working Darkroom.

OpenGTL 0.9.5

Among the bug fixes, there are two major changes in this release

  • Start using llvm optimization, there is one thing that OpenGTL does very poorly, it is emitting assembly code, for instance, if you need to access three time a value, it will load it three time from memory… So enabling optimization give a significant boost in execution speed, unfortunately, I haven’t had the time to do some benchmarking, but I have noticed a siginificant improvement in applications (Krita and Darkroom) that use OpenGTL.
  • The second change, which took me longer to do correctly, is that conversion are now handled by the parser and inserted in the AST tree, instead of being assumed to be possible in the parser and triggering asserts in the code generation (previously MyStruct a; int b = 2 + a; would have aborted the program instead of reporting an error to the user). The other benefit of that change is that it makes possible to automatically convert from Shiva’s pixel structure to a vector.

    Before that change, the Blur kernel was looking like this:

    kernel Blur
    void evaluatePixel(image img, out pixel result)
    pixel v1 = img.sampleNearest( result.coord );
    pixel v2 = img.sampleNearest( result.coord - 1.0 );
    pixel v3 = img.sampleNearest( result.coord + 1.0 );
    for(int i = 0; i < 3; ++i)
    result[i] = (v1[i] + v2[i] + v3[i]) / 3;

    And now it is down to:

    kernel Blur
    void evaluatePixel(image img, out pixel result)
    result = ( img.sampleNearest( result.coord ) + img.sampleNearest( result.coord - 1.0 ) + img.sampleNearest( result.coord + 1.0 ) ) / 3.0;

Darkroom 1.3

The two main changes (yes I like to limit myself to the number 2) of Darkroom are:

  • This release introduce a levels widget, if you wonder how it is useful, I suggest reading Unai Garro’s Levels adjust tutorial.

  • Darkroom can now export to jpeg, when I first started Darkroom I considered that the only interesting export format would be Png, only to realize later that if one wants to export to a web gallery, jpeg is better suited
  • Bookmarks (yes that’s a third change, but I only remember about it when I did the screenshots for the levels widget), it’s now possible to save bookmarks of your favorite processing settings

OpenGTL 0.9.3 and 0.9.4 : first release with Shiva

A few days ago, I spoke about OpenShiva, since then I have added quiet a few features, since OpenShiva can now read images, and work with different bit depth than float 32bits, I have also found a lot of bugs that are now fixed (and are covered by automatic tests ! yay !).

Now, there are all the basic features to demonstrate the technology, so it’s about time to make a release. Especially that a new release of llvm has been made early June, and since they make a point to have weird API/ABI breakage at each release: before to create most instructions you would write “new InstructionName(params);” and now it is “InstructionsName::Create(params);” except for a few instructions were the old style is still in use… That said, without llvm, I would have been unable to achieve what I have achieve until now with OpenGTL.

So here comes two releases, 0.9.3 for llvm 2.2 and 0.9.4 for llvm 2.3, they have both the same feautres sets.

Beside a lot of bug fixes, and the early implementation of OpenShiva, OpenCTL has matured a lot, and now most of the standard library is implemented (it remains a very complex function that is underspecified 😦 and some color conversion functions). And there is also a nice debug system that allows to control output depending on library, file name and function name, which is nice, since OpenGTL, in debug mode, is very noisy (but it’s all needed when debugging).

If you want to have fun, you can download everything here.

OpenGTL 0.9.2 and linear RGB color space

29 April, 2008 1 comment

I finally made a new release of OpenGTL, with a nearly full support of the CTL (Color Transformation Language) syntax. While large part of the standard library is still unavailable, it has all the features currently needed for Krita’s color spaces.

This allows to bring color management to color spaces that didn’t have that, and most specifically our RGB HDR (High-Dynamic Range) color spaces. It is especially interesting, because we need to have both a linear color space (for most high dynamic range operations, and if you want to do gamma correct scaling) and a non linear (a sRGB color space, which is used for color conversion, mostly with the painterly framework). So we were in need to be able to have profiles on top of those color spaces, and that is exactly what CTL is giving to us.

Back to gamma correct scaling, some times ago someone mentioned to me this link, scaling with non-linear color space gives a wrong result. Before we started using CTL based RGB color space, our HDR color space were an hybrid of sRGB (non-linear) and scRGB (linear) (don’t try to understand how we got there, I don’t either), and curiously, the scaling was wrong half of the time (don’t try to understand it was possible, I don’t either), but now, using the linear RGB color space, we can have gamma correct scaling:

OpenGTL and QtCTL 0.9.1

3 March, 2008 1 comment

A new release of OpenGTL (or more like the first, as the previous release only contains OpenCTL), my Graphics Transformation Languages library, is available. This release contains a much improved CTL (Color Transformation Language) interpreter (if we can call this, as it is in fact a JIT thanks to the use of the llvm).

The main new features of this release is the possibility to manipulate a buffer of pixel. And to demonstrate the use I made a small application example. I would have loved to make a screencast (things are more lively that way, but I must second Aaron’s feeling xvidcap hangs on debian, and I couldn’t find out to make recordmydesktop records only a small part of a screen, and just the thought of post-editing scares me, yeah I am easily scared, but if you blink fast and can synchronize your blinking with the scrolling, you can see a short animation below !).

There is nothing extraordinary in those screen shots, except that you can dynamically change how the pixels of the image are transformed, and it’s fast.

Nothing to see in the first screen shot, except the original image which is a picture of the Cathedral of Amiens (according to the guide, the biggest, the greatest, the fastest build of all Cathedral… from France):

The first CTL program remove the green channel:

This one invert the color of the previous image:

This one invert the color of the original picture:

And this one swap channels:

You can download it from here OpenGTL.

And now, what remains is fixing the bugs, finishing the CTL Standard Library, fixing the bugs, write a real world usuage, fixing the bugs (didn’t I already said it ?).