Going to Libre Graphics Meeting 2014

LGM2014 will happen April 2-5th in Leipzig, Germany and this will be my fifth year attending. In fact LGM 2010 in Brussels was my first international conference ever, and convinced me that I wanted to make open source professionally.

I’m very excited about this years program, because once again we have managed to combine bleeding edge developments in open source software for graphics and visuals, with a wide range of connecting fields: open hardware, design, art activism, free cultural works, research and education.

Personally, I especially look forward to:

  • Richard Hughes: Building an OpenHardware Spectrograph for Color Profiling in Linux
  • Johannes Hanika: Wavelets for image processing
  • Manuel Quiñones: GEGL is not GIMP – creating graphic applications with GEGL (workshop)
  • Libre Graphics Magazine: Beating the drums, Why we made gender an issue

I am also hosting a BoF session on visual programming of libre graphics tools. Curious to see what comes out of that.

If you are interested in open source and graphics, don’t miss Libre Graphics Meeting.
Register now (it’s free and open for all)!

Can’t go to LGM, but would still like to contribute? Please consider donating to our travel fund.

I would like to thank the GIMP project for sponsoring my trip to LGM2014.

Libre Graphics Meeting 2013: We want you

Are you interested in the overlap between technology, art and design; and free, open, libre tools that join these domain? Do you use Libre Graphics software like GIMP, Blender, Krita, Inkscape, Scribus, MyPaint (and similar), and want to meet the people behind them?
Are you a developer of free and open source software in the areas of photography, graphics, page layout, design, publishing, typography, animation or video?

Come to the 8th annual Libre Graphics Meeting, from Wednesday 10th to Saturday 13th April in Madrid, Spain!

Registration is open (no attendance fee, sponsorship possible), and presentation & workshop proposals are accepted until 15th of February (2 weeks from today!).

Improved drawing performance in MyPaint brush engine

A first set of performance improvements for the brush engine has just landed in MyPaint master. The goals for this work for me were, in priority: a) Making sure that moving to a GEGL backend in MyPaint does not reduce performance, b) Improve performance when integrating the MyPaint brush engine in other applications, and lastly c) Improving the performance in MyPaint itself.

TL;DR: * Users of the soon-to-be-released MyPaint 1.1 should experience about 15% faster drawing of strokes for medium to big brushes. * Switching to the GEGL based backed for MyPaint 1.2 is now both feasible and highly desirable from a performance perspective.


Optimizations

The optimizations are implemented through three complimentary strategies:

1. Deferred data access to minimize fetching and updating of tiles

All dab drawing operations that happen as a result of a motion update event are queued up. When the brush engine has calculated where all dabs should go, tiles are fetched, all dabs drawn and the tiles updated. This in contrast to before where each dab drawing operation would fetch and update tiles.

2. Coarse grained parallelism using multi-threading via OpenMP directives

The tiles to be processed are divided evenly between processing threads (one per core). Each tile is processed completely independent of other tiles, so there is no locking or synchronization in the drawing code. The tile backing store must naturally be thread-safe and may ensure this using locks.

3. Fine grained parallelism using SSE via GCC auto-vectorization

Within each tile we attempt to make use of auto-vectorization to create the brush dab mask and do the composition of the dab onto the tile. Currently this is only implemented for a part of the mask calculation.

Results

Details of the results and how they can be reproduced is found in the original email thread.

Gains for MyPaint 1.1

Starting with the lowest priority goal, but the most relevant to users; performance impact on MyPaint right now.

Surface drawing results for existing Python-based backend

In terms of raw speed of drawing brushes to onto the underlying surface, speedups range from 20% to 50% for larger brushes (16 px+). This sets an upper boundary for the speedup perceived by the user.

Looking at the UI-enabled benchmarks of MyPaint, which is doing everything a normal application instance does, including layer compositing and rendering to screen, around 15% speedup was observed.  As the UI benchmark only tests a single brush at size=8.0px, it is possible that larger brushes will a higher speedup.

Users of the soon-to-be-released MyPaint 1.1 should experience about 15% faster drawing of strokes for medium to big brushes.

Note that the backend in use does not make use of the multi-threading introduced by (2) due to the tile store not being thread-safe and that it already had a cache to mitigate the problem fixed by (1).
Note

GEGL-based backend results, outlook for MyPaint 1.2

Surface drawing results, GEGL versus Python-based surface.
Test results by Till Hartmann on his Phenom II X6.

So in terms of raw surface rendering speed, the GEGL based backend is now significantly faster than the Python-based one. With 1 and 2 threads it is respectively up to 25% and 100% faster for big brush sizes. With 6 threads, it can be up to 4 times faster.

Switching to the GEGL based backed for MyPaint 1.2 is now both feasible and highly desirable from a performance perspective.

Note that to see UI performance increases approaching the raw surface drawing performance increase we may also need to do the layer compositing multi-threaded.

Gains in other applications

I’m trying to convince the Krita guys to update to the new version and to provide some feedback on the impact. Other consumers of the MyPaint brush engine do not tend to communicate much with us (some are proprietary).
I have strong hopes that (1) should increase their performance radically as their tile get/set cost is significantly higher than in the MyPaint case: They need to convert between the internal Krita and the MyPaint brush engine working colorspace each time. They may also be able to enable multi-threading and see speedups similar to the GEGL-based backend as a result.

Future Work

This is only lays the groundwork of better optimized MyPaint brush engine, many areas have room for improvement. For one only a small subset of the heavy code is vectorized. There may be inner loops that can be tweaked. It may be that, with a different tile access pattern compared to before, a different tile size would be more ideal. Perhaps doing the expensive calculation of the brush dab could be avoided some times by caching them… Thinking bigger, one could move all the drawing (and rendering) to the GPU.

More details on these ideas can be found here. If you are interested in working on any of it, get in touch and start hacking!

Piksels and Lines – Libre Graphics Research Unit seminar in Bergen

Last week I was so lucky as to attend the 3rd Libre Graphics Research Unit (LGRU) meeting in beautiful Bergen, Norway.

The meeting was titled Piksels and Lines and had “a particular focus on improvements, interoperability between and fringe use of F/LOSS graphic bitmap and vector software, as well as generative software used in performative contexts.”

The meeting was structured into three different areas: Seminar, Workshop and Performance.

Seminar

The attendants that were invited for the meeting each did a presentation of their choosing. They were recorded and are available in the online archive of the seminar. The video quality leaves something to be desired, but the audio is generally good.

The presentations I found particularly interesting were:

I gave a presentation titled MyPaint and cross-application workflows. It was an introduction to MyPaint as a creative tool, how it combines raster and vector (piksels and lines) concepts, and my perspective on interoperability between libre graphics applications.

 

 

Workshop

I had hoped to hack some code for one of my existing ideas during the workshops. That did not happen. Instead I ended up hacking specifications. Maybe that is just as good. Hacking one can always do later, hashing out and documenting ideas has to be done while it is fresh.

First the results of some discussions with Øyvind Kolås, the GEGL maintainer:

A journal for GEGL: transaction log over changes made to a GEGL graph. Specification. Discussion. This feature would allow for applications based on GEGL to:

  • Implement non-linear histories (undo/redo), and a timeline of the changes
  • Store the history in a document like OpenRaster
  • Share the history between different applications
  • Let multiple applications to work on the same document at the same time

A strategy for improved file format support in GEGL, and using this to improve  file support and interoperability in libre graphics applications. Proposed plan.

Executing this plan would move a lot of the existing file format support from GIMP (PSD, XCF, OpenRaster) down into GEGL so that it can be reused across applications. And would then let GEGL provide image support plugins for GdkPixbuf and QImage – so that at the very least – previews will work everywhere.

 

Chatting with Egil Möller, creator of Sketchspace, also resulted in:

A web based system supporting a continuous work-flow from free-hand
sketch to finished product. Concept and mockups

“Imagine starting from a freehand drawing or imported raster image and gradually refining this into a technical document with illustrations, UML-diagrams or even running code or a 3d model.”

Refining here means that the user guides the tool to transform freehand sketch into vector paths, then into vector shapes, then into something domain-specific and formal like UML – by adding additional data like annotations, strengthening of lines to “disambiguating” the transformation.

Needless to say, this is more a visionary thing. Realizing this would involve finding good solutions to a fair amount of computer vision problems.

Making GEGL available for use in web-based applications. Proposal.

More on the concrete side: allow GEGL to be used in interactive or batch-oriented web applications, or in native applications based on web technologies (Javascript, HTML5 user interfaces).

Some of the discussions also resulted in me writing down the strategy for GEGL integration in MyPaint and the related ideas/plans for how to improve the performance of the MyPaint brush engine.

Now we just need to implement all the stuff… Contributions welcomed!

 

Performance

Since Piksel, with a long history in generative performance arts, was the hosting organization it was not surprising a project in that area materialized.

A workshop session hosted by media artist Brendan Howell called Demonstrating the Unexpected came up with the idea of the Piksels & Lines Orchestra (PLO): think of the collaborative use of our traditional libre graphics software as an orchestra. The applications, from MyPaint to Scribus, are instruments; the people using them players; a performance the use of these instruments. Can we create an experience for an audience based on this framework? How would it sound? How would it look?

Architecture diagram - no need for them to be dull looking.

Having plenty of code-crafting people available, the next afternoon it was decided to spend a couple of hours realizing a prototype. The LGRU blog has the details. We recorded video of our initial performances with this prototype as well, but that has sadly not made it online yet…

 

Thanks!

Thanks a lot to Piksel and LGRU for sponsoring my attendance, and the EU Culture Programme and Bergen municipality for funding activities that support libre graphics and free culture!

MyPaint and goats at LGM2012

Already covered in the news from LGM was the release of GIMP 2.8, and that GIMP 2.10 will be fully GEGLified. The goat-invasion branch which has most of that work, the result of 3 weeks of pippin and mitch on a couch hacking together, has already landed in master. This means that GIMP now has support for high bit-depth workflows for most operations. Finally.

Putting the goat in MyPaint

During LGM I started working on using GEGL in MyPaint. I have already mentioned this idea several times, so it was time to stop talking and get hacking.

As a first step in making use of GEGL I wanted to replace the current surface implementation with one based on GeglBuffer. Since GeglBuffer already provides tiling, and can store any buffer data supported by Babl this turned out to be easy. Øyvind (pippin) added the semi-quirky pixel format we currently use* in MyPaint to Babl, and I was able to get a rough working GEGL based Surface implementation the first evening.

The MyPaint brush engine working on top of GeglBuffer

* RGBA premultiplied alpha, in 16 bit unsigned integers with  2^15 being the maximum value.

The next couple of days went to moving to the GeglBufferIterator API instead of gegl_buffer_{get,set} to have zero-copy access to improve performance, and improving GEGL and GEGL-GTK so that some of the hacks in the initial implementation could be removed.

Most of the work is in the gegl branch of MyPaint. A simple test application, mypaint-gegl.py, is included, and you can read README.gegl for how to try it out. Warning: only intended for curious developers at this stage.

A lots of work remains to be done for MyPaint to be able to fully use GEGL. The progress is tracked in two bugs, one for MyPaint work and one for GEGL issues. Because one cannot combine PyGObject with PyGTK, it will likely not be possible to fully integrate GEGL in MyPaint before porting to PyGI and GTK+ 3.

Oh, in case the goat references are lost on you – check the GEGL page on wikipedia.

MyPaint and OpenRaster talks

One of my goals for this year was to give a presentation at a conference. And I can now say that I have achieved that goal.

I gave a talk about MyPaint at Libre Graphics Meeting 2011 in Montreal, Canada: MyPaint – the past, the present and the future.

[hdplay id=1]

Download in Ogg/Theora

I will also be giving a lighting talk at the DesktopSummit in Berlin about OpenRaster. It looks like this will be on August 7th at 14.00, but you should of course come for the whole week. Just look at the awesome program!

 

MyPaint on Meego?

When I got back from the Meego conference, I tried building MyPaint on the Ideapad I got (which runs Meego Netbook 1.1).

I was pleasantly surprised to find pygtk in the core repositories.  numpy on the other hand was missing but that was easy to build from source. Buut, it seems that pygtk is built without numeric support, making MyPaint unusable; numeric support is used to get access to the pixels in pygtk pixbufs, which we need for several central things.
I have of course filed a bug for this so hopefully it will be resolved soon. If not I will have to provide alternative pygtk packages using the community OBS. In any case, expect it to be working soon.

I also hope to adapt MyPaint’s UI to the handset and netbook/tablet form factor, but this is only talk so far.

LGM2010 writeup

This weekend I attended Libre Graphics Meeting in Brussels, and got to meet a bunch of great people from lots of different projects. Got to meet people working on similar things (at least in the same ballpark) as MyPaint, like Krita, GIMP and Nathive. Also got to meet and hang out with some of the awesome people on the Durian Open Movie project. They were using, and were more fond of, MyPaint than I thought.  Also chatted with several other users, some of which were using MyPaint as a part of their workflow in a professional environment. Good stuff.

The entire conference was very professionally executed, no technical or organizational problems, yet they were able to maintain a nice cosy atmosphere. The only thing I didn’t quite like was the food, but thats mostly a matter of personal preference (they only served vegetarian, and I’m a quite dedicated carnivore).

There were plenty of good talks, and if you’re interested in them you should check out the video recordings done by River Valleys. I also attended some workshop/BoF sessions, here is my take on them:

OpenRaster BoF

The OpenRaster BoF turned out to be quite different from what I expected. I expected only a couple of people from Krita, GIMP and MyPaint to show up. But no, we had lots of people attending, even professional standards people from Adobe, w3c and Opera! I also somewhat suprised myself (ok, I know that I like to talk and am not afraid to do so, but still), by taking an active role. We did get useful things done, like consensus on that we want to define a minimal baseline standard, and to have fallbacks for things extending upon the baseline. The concrete specs have not been settled, but hopefully we (MyPaint+Krita people mainly) can take care of that pretty soon.

I hope to try out some implementation ideas for fallbacks soon, and to improve the GIMP implementation, but school is keeping me very busy now a days. In fact, the first evening in Brussels was spent finishing my bachelors thesis report, and sunday was spent on my final report in my english class. And its far from over yet…

A Libre Graphics Foundation?

There was a birds-of-a-feather session for a potential “foundation” to support and promote libre graphics projects. Apparently these ideas have come up before, but this year it seems to be gathering some traction so it might actually happen. Different people have different views on what exactly it should be about of course; some are looking in the direction of Blender Foundation/Institute, doing open projects, funding developers, and having official teaching; others are more interested in having common documentation about libre graphics software for users. In any case, a common resource and face for libre graphics projects would be good. But in the end it will boil down to what people step up and make happen, I suspect. Discussions are ongoing on the create @ freedesktop.org mailinglist, so jump in if this tickles your fancies.

LGM2011

In the discussion during the last day, Montreal and Vietnam were proposed as locations for the next LGM. I’d love to go either way, haven’t been to Asia nor North-America. Perhaps even do a talk of my own? Still, it’s much further away, so it might require a very interesting program, depending what I’m doing at that time and how busy I am. We’ll see. If if turns out to be more of an end-user conference, and less of a developer/contributor meeting I’d love to have David Revoy and/or Ramon Miranda do MyPaint workshops. That would be beyond awesome.

In the meantime, it looks like GUADEC will be my next conference, only 8 weeks away. I’m already excited!

Grapikslabor, MyPaint meetup, attending LGM2010

Very sorry about the wall-of-text-with-no-images. I’ll do better in the future, promise.

While on my trip to CERN I spent a couple of days in the area of Zürich. On Sunday 2th of May I traveled from Geneva to Zürich (coming directly from a night-shift, ugh). There I attended Grapiklabor, which is a series of workshops on graphics using free software held by Alessandro Rimoldi, a Scribus community member. On the schedule that day was vector based graphics with Inkscape. It was a very useful workshop for me, I now have at least a pretty good idea of how to use Inkscape to solve real problems.

MyPaint developer meetup

In Zürich I also meet up with Martin Renold, the creator of MyPaint. In addition to attending Grapiklabor with me, he was kind enough to let me stay in his home in Winterthur for a couple of days. On Monday we went for a longer hike in a nearby forest, an I got a tour of the city. Of course, with the two most active developers together, the meeting also involved some MyPaint hacking:

– We did some design for our oldest bug; adding some sort of fixed size image functionality. The challenge is doing that without compromising on MyPaints  infinite canvas feature, but still being intuitive and efficient for users, and being able to inter-operate with other applications in a good way.
– We also approached the usability issue with the current brush settings dialog, got a significant improvement committed, and a even better solution, in my opinion, sketched out.
– Also committed was support for layer visibility attributes in OpenRaster, both in MyPaint and in GIMP.

I’m going to LGM 2010!

I’ve now also confirmed that I’m going to Libre Graphics Meeting in Brussels, plane tickets have been ordered and everything. It will be my first LGM, heck, my first conference of any sort! There I will meet up with Martin, Alessandro and many other great people in the free software graphics community. Drafts of the program has been published on the create mailing list, and I’m really looking forward to both the social and technical aspects of the conference. Great things have come out of LGM before, I bet this year will also have some in store.

I might also have another, exciting trip abroad upcoming. If so, more on that later 😉