Multithreading in GIMP, Learning to write GEGL operations

As some of you have seen, GIMP is being ported to a new graph-based image core, called GEGL. Those of you who have experimented with GIMP 2.6.X and later, have possibly found the GEGL tool (Under the tools menu) which allows you to see on-canvas preview of some operations such as blur, perlin noise (which some of you know as clouds), and more.

Thanks to the very generous help of Øyvind Kolås (aka pippin), I have started to write a GEGL operation for GIMP. Too practice I decided to write a Pixelize operation (not too complex, but also works on a neighborhood of pixels and not on a single pixel).
This is the first time which I implement an image processing algorithm which is not based on samplings for distortion (like the waves filter), and although I know the theory for a lot of time, it still has some bugs with wrong indexes :P

When I finish this, I'm going to post it here along with a log of my chat with pippin on the IRC (on irc://irc.gimp.org/#gegl) to clear out some of the common questions about GEGL. Hopefully I'll be able to post a mini-guide (or more correctly, what I have learned, since I still have a lot to learn to write a full GEGL guide) to introduce other people to writing GEGL operations.

The discussion originally started because I was disappointed that libgimp (the library for interactions between plugins and GIMP) is not thread-safe, meaning that you can't have two threads modifying the same drawable concurrently (unless of course you want to "Create Modern Random Art" as someone called it). And it's impossible not practical to fix it (due to the amount of time it would take).

Apparently, GEGL is multi-threaded (more on this later, in my next post) and it usually works (but sometimes the threads reach a dead-lock, a situation in which both threads are blocking one another from progress since they are waiting for shared resources/memory). It still requires a bit of fixing (Cheer up for pippin! He needs some more motivation to fix this! ;-) )

So, for those of you who want to try "bleeding edge" and unstable GEGL, set the environment variable GEGL_THREADS to 2 (or whatever amount of threads you want GEGL to use) and expect up to 200% speedup (in ideal world. Practically some parts of the code which are executed sequentially, added to the limitation of the memory access speed, both will cause it to run slower depending on the operation and your system) with GEGL (or 0% if you reach a deadlock).
Be warned: this is supposed to be buggy. Please do not report bugs with this, unless you strictly know what you are doing.

Edit: Made the post more correct about the possible speedup. 200% speedup is a naive optimistic view, which is ain't true (and I forgot to mention this)

GIMP 2.6.10 [bugfix] is out

GIMP 2.6.10 is out and it's a bugfix release. The time between this release and the previous one was a bit short because of an annoying bug that was discovered...

Overview of Changes from GIMP 2.6.9 to GIMP 2.6.10
==================================================

* Bugs fixed:

 613328 - TGA files saved with incorrect header yOrigin data
 623290 - Save As... does not save Windows Bitmap as default in dialog
 621363 - CMYK decompose broken
 595170 - brush - color from gradient works wrong in greyscale
 613838 - Error in gimp-hue-saturation PDB call
 622608 - GIMP crashes when clicking any scroll bar from combo boxes
 565459 - newly opened images are put into the background

* Updated translations:

 German (de)
 Italian (it)
 Romanian (ro)
 Portuguese (pt)

So, what are you waiting for? and grab the update ;-)

Updates

I'm back - Finished all the university tests finally!
Some updates:

• I got myself a working windows computer again on which I can test the compilation of GIMP - and this time it much faster (last time it was a computer with a disk access throught the network and the connection speed made the compilation 24 hours long...). I'll try to get this fixed as quickly as possible (and the IT at the university are trying to find me an even better windows computer).
• I missed the 2.7.1 release with my PDF plugin - I had too many tests...
• Decided to be a bit artistic - I submitted the new icon for the cage transform tool - you can take a look at it here.
• After finishing my course in Multicore Programming, I decided to try to do something practical with it. I'll be experimenting with multicore plugins for GIMP over the next week and I'll see what's possible (if any).

GIMP 2.6.9 + Hebrew Translation Update

Hello everybody =)

For those who haven't seen yet - GIMP 2.6.9 is out!
Go get it! The release notes are here.

Also, I commited my first Hebrew translation update. About 1/6 of GIMP's main gui is translated.
Want to help translating? Have comments about the translation? Comment here (or leave a bug report if it's a translation bug).

Gimp Updates: Multi-Colored Text, PDF Export, Hebrew Translation and more...

Here are some quick updates from the last several days:

• First announcement: GIMP is currently being translated to Hebrew!
  As a Hebrew speaker, I was very disappointed from the state of the Hebrew translation of GIMP. So, I decided to start and translate it, and I already fixed several bugs to make the translation to Hebrew easier.
  The translation is going on well, and I'll start updating the main git repository with the translations soon.
• I have some progress on the PDF export from GIMP. Hopefully it will be committed this week - all the blocking issues were resolved and basically all I need to do is to connect the GUI.
• I did try to implement multicolored text support in GIMP (several colors in the same layer) and it failed for the most annoying reason - text in gimp was rendered as an alpha mask for a color layer.
  Mitch fixed it recently, so this means that I'll be able to retry my patch somewhere soon.

And finally, I have to say that I'm quitting (at least for now) the attempt to save single window mode layout in GIMP. It's not so practical right now, since the object which hold the data (GimpDockWindow in swm and GimpColumn in mwm) are being destroyed when switching between modes.
After discussing it with Martin, I understood fixing this is not trivial, so I'm not going to do it anywhere soon...

Updates and Flies

First of all, before I forget, many thanks to Alexandre Prokoudine who added this blog to GraphicsPlanet. Go check this site - it lists blogs of many open source projects and their developers.

There is more progess on the single window mode - saving it partially works now (or more correctly, loading it works). The post about the single window mode is updated as I make progress in that direction.

The blog is now printer friendly, at least for firefox users - please notify me if you see anything which doesn't look well in printing.

And finally, this blog is also about art and photography. Here is a picture I took today, which I like (click to go to the page with the fullsize view)

2fly by ~LightningIsMyName on deviantART

Script of the week - Creating HTML documentation for the GIMP PDB

Someone asked on IRC for this, so here it is: http://www.pasteall.org/13829/scheme
This script generates HTML documentation from all the GIMP PDB.

To use it, simply call (db-to-html-file FILE) in the script-fu console (replace FILE with the path for the file you want to create).

Progress - Saving Single Window Mode settings in GIMP

Two days ago, I promised to try and work on the single window mode in GIMP. Well, I have worked on it, and I know basically know what needs to be done.

Note: This post is mainly for people interested in the GIMP's source. For others, just take my word that there is some progress =)

So, how is single window mode implemented in GIMP?
The heirarchy is the following:

The heirarchy of the user interface containers inside GIMP
GimpDockable's inside GimpDockbook's inside GimpDock's

GimpDock - which is very similar to a GtkVBox
  |-- GimpDockbook - this is a small area which allows tabbing of several GimpDockable's
     |--GimpDockable - This holds the actual content and user interface elements

Single window mode, introduced two new containers - left and right. In each of these 2 new containers, we can store several GimpDock's in a row (see the image from my previous post, to see how this looks).

Here is a typical part of the sessionrc file, a file in GIMP which holds your session preferences:

(session-info "toplevel"
    (factory-entry "gimp-dock-window")
    (position 0 25)
    (size 200 523)
    (open-on-exit)
    (aux-info
        (show-image-menu "false")
        (follow-active-image "true"))
    (gimp-dock
        (book
            (current-page 0)
            (dockable "gimp-layer-list"
                (tab-style icon)
                (preview-size 32))
            (dockable "gimp-channel-list"
                (tab-style icon)
                (preview-size 32)))
        (book
            (position 236)
            (current-page 0)
            (dockable "gimp-color-editor"
                (tab-style preview)
                (aux-info
                    (current-page "GimpColorSelect")))
            (dockable "gimp-brush-grid"
                (tab-style preview))
            (dockable "gimp-pattern-grid"
                (tab-style preview)))))

So, here is a short analysis of what's going on:
(session-info "toplevel"...) - means we are talking about a top-level window
(factory-entry "gimp-dock-window") - means we are talking on a dock window (other windows are also saved, for example the location of the save dialog)
(current-page 0) - means that the current open tab is the first one
The rest is pretty self explanatory...

So, how am I supposed to implement saving a single window mode?
"Simply", add two parameters directly after (factory-entry "gimp-dock-window"). This entries are single-window-mode-position which can be one of "left", "right" and "floating" (since you can still have floating docks in single window mode). And, for docks which have one of either "left" or "right" value, I'll have to add a "dock-index" property which indicates their index in that side (left/right).

Here is the bad part - I'll need to add these configuration properties to the docks themselves, and to the configuration file. Then, I'll also have to support parsing these parameters when activating single window mode. This is going to be long, and annoying but it also has a bright side - I know how to do this =)

And with this somehow optimistic summary of what needs to be done - I'll go to sleep (I should really find times to update this blog during the day instead of writing at midnight :P).

Edited - Jun 16, 3:59 AM:
1. fixed a wrong class name inside the image of the gui
2. Got thumbs up about this way of implementation from martin (aka enselic) - the guru behind the single window mode.

Edited - Jun 18, 12:22 PM:
Loading the settings of single window mode works! BUT, saving them doesn't :-( The problem is that if we are currently in single window mode, dock windows are not saved at all (even the fact that they exist is not saved).
I believe they (the dock windows) are being destroyed during the switch to single window mode, after the dockables inside them were attached to the "uber" image window (that's how it's called in the code, I haven't chosen uber myself).
If I'm true, this will also explain why when I quit after switching to single window mode, the settings that were loaded for single window mode, are lost (since they were associated with the dock windows and these were destroyed).
There is no easy way out of this - I am starting to understand why mitch said this problem is so evil...

Single window mode - wonderful for the user, horrible for the developer

Some of you may have seen the single window mode introduced in 2.7. It's wonderful to use (no need to suffer anymore from the huge amount of floating docks!). You can dock all the dialogs on the sides and customize the location and size of every one of them. All, inside the main window!

New features in this screenshot are layer groups, resource tagging, on-canvas text editing and on canvas dialogs, single window mode and paint-dynamics dialog (you can configure each dynamics settings in more way than you can imagine :D)

But, here is the catch - you can't save this layout! Every time you start Gimp, you will have to go to Windows->Single-Window Mode to enable this, and the location of the docks won't be saved. In other words, you have to rearrange the window layout every time, when using single window mode.
And to make it worse, when trying to fix this mitch warned me:

you actually picked the most evil current problem ;-)

Having to set your layout again every time IS VERY ANNOYING.  I'll try to fix this, but after looking at it I'm sure it's not going to be easy. Oh well, someone has to do this =) Starting this at the middle of the night (an hour ago) wasn't so smart - I'll go to sleep and do this (or at least try to) sometime during this week...

Made my first commit to GIMP - and haven't ruined anything :D

I just made my first commit to the GIMP git repository, and luckily I haven't ruined anything (it's pretty easy to ruin things with git).

Many thanks to Michael Natterer (aka Mitch) for helping me with this, and generally with helping me with diving into the GIMP internals.
If you are reading this - I owe you so many thanks ;-)

Got my Git Commit Acces!

I got my commit acces to gnome git! :D
This means a lot to me =)

GIMP is alive, even if it doesn't look so

Recently, there was a mail to the gimp mailing list, that suggested selling some gimp stuff in an online shop in the gimp website (gimp stickers, mugs, T-shirts, etc.). I like the eidea, but this isn't what I came to discuss todau. Here are 2 quotes from the responses that the suggestion got:

On Wed, Jun 9, 2010 at 8:27 PM, Alexandre Prokoudine wrote:

One of the things discussed at LGM was moving all project's domain and subdomains to a single dedicated server. We have a person willing to do the migration and a person to create a new website.

On Wed, Jun 9, 2010 at 8:50 PM, Michael Schumacher wrote:

We're currently unable to update the website (if you have a look at the index page, even the release announcements aren't up to date).

Until this is resolved, we won't be able to add, edit or remove anything to, on or from http://www.gimp.org/.

Some of you are probably going to respond like this: "WTF?! You have a website and you can't update it?!". My response was also something of that style. As developers of open source projects, we don't need the main website to know it's alive. However, the gimp user community probably think that this project is dead (6+ months without a single update of the site, not even about a call for students for Google Summer of Code!).

So, after some discussions yesterday, in a thread that I started (and you can see the conversation here) several things happened:

• The maintainer of the server was contacted - the site is going to be fixed soon (Thanks to Alexia Death that started working on it recently, even before this mailing session). Although the actual length of "soon" may vary, it's on the TODO list.
• The idea of some sort of developer blogs was raised, and several people volunteered to update them (including me). We'll have to see how does updating the site goes, and maybe we will create these blog(s).
• There was a recent discussion about weekly/daily builds. These builds will serve us by allowing other people to find bugs, and it will serve the community by showing them the latest developments (and that the gimp project is still alive). It wasn't decided yet if there will be such builds - some developers object (since this can generate many useless bug reports if people who don't understand gimp will try the betta) and some support this (since people are already using such builds, so let's make it controlled so we get reports from builds in controlled enviroments).
• New builds will hopefully be released soon:
  
  • A new stable version release 2.6.X with some more bugfixes 
  •  A new unstable build, 2.7.X to replace the old one. This will allow users to see the new features and report bugs so we can fix them. Hopefully, there will be more frequent unstable builds.
  Again, keep in mind that the definition of soon is very flexible...
• I'm going to post an offical guide on compiling gimp on windows, on the main gimp developer website. This will probably help the people out there who want to try the latest versions, but are using windows (like me) where it's almost impossible to compile gimp :P

And now for some personal updates:

• Still waiting for my commit acces to the gimp git - I applied a week ago.
• The PDF export plugin, which I'm working on, will take a bit more time due to the exam period from the unversity.

That's all for today =)

public class Test
{
    public static void main (String[] args)
    {
        System.out.println ("Hello World");
    }
}

Site updated!

Finally - a template which I like =) (customized one of the predefined templates)

Some updates:

• Had a talk with Peter Sikking today (aka guiguru at gimp IRC) about the UI of the pdf plugin (I'm writing a PDF export plugin for GIMP). Expect to see it in GIMP's trunk(!) later this week.
• I'm working on a translation of GIMP to hebrew - this will take some time but I hope to find some users for it
• I'll have this blog posts available both in hebrew and in english, when I start posting tutorials

Hello World

Hopefully this will be my new website =)
I'm a student for computer science at Tel-Aviv University and my interests are

• Computer Graphics
• Digital Art
• Photography
• Music
• Programming

I try to contribute to the open source project GIMP, an advanced image-manipiulation and image authoring program. (some see it simply as a free alternative to photoshop)

Hope this time I'll keep the site maintained :P