coding gems and personal insights in the electronic age, by nic werneck

Inkscape gradients dithering hack

Last sunday at 22:00 I finished a cool weekend hacking project! This post tells how I tweaked the Inkscape source code to enhance its gradients with a dithering technique, to make them look better and avoid the so-called “banding” effect. It all started when I created a logo for my school department, rendered it in high resolution and was disappointed with how the gradient looked. So I challenged myself to implement a basic dithering into Inkscape’s gradient during the weekend. It seems to be working fine, I’ll show here some demonstration pictures and also provide a patch.

Dithering is a technique to reduce the number of color levels of an image, or its bit depth. It is based on the fact that if you smooth out a pattern with two different color tones you get an intermediary tone. There are different ways to create this pattern, the one I used is based on the Bayer matrix.

When you have an image with large depth, such as in floating point, the normal way to convert it to e.g. 8-bit depth is to simply round the value. To make a dithering you sum a certain signal to the image before rounding. You can sum a random uniform white noise for example. Or you can create patterns such as lines and circles. The Bayer matrix creates a pattern that looks like cross-stitches, and should look familiar to you if you like low-tech stuff.

To create a gradient, a program such as Inkscape has first to make a floating-point calculation that yields a floating-point representation of the color levels in all channels. It then rounds the value to the 8-bit palette. And if the colors from the beginning and end of the gradient are too close to each other compared to the length of the gradient, there will be regions of pixels that will be rounded to the same value. To implement dithering in this gradient rendering to prevent that, all we needed was to add that pattern matrix before the rounding.

Well, that is the theory, but there is a problem in practice. The way Inkscape and other similar programs work prevents us from doing that. Before calculating the pixel colors they first define a large vector where the colors from the gradient are calculated beforehand. That makes it faster and also easier to deal with all the stop point coordinates and stuff like that. But because this vector is created with colors in the final bit depth, the rounding has already been done by the time we are rendering the pixels, and know their coordinates to sum the proper value from the dithering matrix.

This is where the “hacking” part enters. If I wanted to make the program right, I would have to change a lot of things. I would probably make it work with floating point in all parts of the processing, and only convert to 8-bit or whatever in the last steps. But what I wanted was just a quick and dirty way to make it work. Really just hack”the code to make the dithering.

The key to make it work was to be able to store in the vector that is used in the rendering the same colors, but with more depth. I could have tried to change the whole code to use floating point instead of unsigned chars, but that is a lot of work. What I did instead was extending the vector size from 1024 to 2048 quadruplets of unsigned chars. On the first half of the extended vector I stored just the exact same numbers that were originally being written. On the second half I stored the next 8 most significant bits, 8 extra “binary places”, just like you would with decimal places. This is a fixed-point approach, different from floating-point.

So after I changed the procedure that initializes the color vector, I just modified the rendering part to read the color into a floating point quadruplet, and then performed the dithering normally. The next figures show the results. The first images show what happens with the original code. The image created on Inkscape is just a rectangle with a tilted gradient with just a few levels, varying from red to blue using just the levels from 124 to 132.

The first image looks just purple, because it is really hard to notice the bands in this case. Sometimes you can see it on LCD monitors when you look to it with an angle. The second and third images had their contrasts increased by different amounts to better show what happens. The third shows very clearly one of the bands in the middle, with a few pixels wide. Now compare these to the following three pictures, which are the corresponding ones with the dithering.

The second image still looks like a nice gradient if you smooth or reduce the picture, unlike the one without dithering that shows a staircase. The third image here also shows how the otherwise straight and solid band become something more diffuse, with fuzzy edges.

The next picture shows a part of the logo I had made. The right half is the original version, and the left is the corresponding segment with dithering, mirrored. The middle region is blown up in the box. It is interesting to notice that although the dithering is working fine, and does blur the edges between the bands, there is still some quantization visible. I believe this is because of the restricted number of colors in the gradient vector. While the dithering reduces the quantization noise by rendering the colors more precisely, the number of colors is still restricted, and a very high resolution will still have regions with the same color, even though this color is now dithered. I am still checking if that is the case, or if my implementation has any bugs.

That is it for today. At the end of the article I pasted a patch for the Inkscape 0.48.0 release that implements my changes. But before I conclude this article I just wanted to tell a few statistics, because whenever I see an article like this I wonder about the author… So here is some personal details of me.

Age? 29.75
Been coding since: forever
Time working on the project specifically: only started to work on the code in saturday, after I wrote a comment on “this page”:https://blueprints.launchpad.net/inkscape/+spec/dithered-gradients. My code finally worked on sunday 22:00, but in the meantime I did sleep, eat and even went to the mall with my girlfriend.
And last but most important, probability of having done this if Inkscape was not open source: zero.

I think to apply the patch you have to “patch -p0 < filename.patch" at Inkscape's source root.