To give you a better idea why LGM matters I finally finished the article I promised long time ago. Read it here.

If you are willing to support LGM, no matter how little money you can give, please use the Pledgie:

If you are a potential corporate sponsor, it’s best to contact GNOME Foundation, who help us with processing of incoming payments, by writing to lgm(at)gnome.org. Thank you!

I can’t stop myself from quoting one of the users who commented on the Russian version of the review: “Yeah, great application! I’m painting again!!! PS: my girlfriend just can’t stop using MyPaint, that’s how much she likes it! I’m getting jealous ”

The raising popularity of MyPaint clearly has a lot to do with David Revoy’s famous time-lapse video. This is how a lot of people discovered the application. Here is one of the new MyPaint artists: http://tissia.livejournal.com/ (warning: cyrillic letters )

Hopefully at least some of the developers will make it to Libre Graphics Meeting in May. We’ve been having more or less same projects every year at the conference, it’s time to see more people

The first of them shoots now: Libre Graphics World. We intend to make this website THE host for news, articles, interviews and so on. We tried to cover most questions about LGW in the FAQ. Feel free to ask more

Most technical work was done by sK1 team (kudos, guys!).

We start with all interviews I did over the years, a review of Fontmatrix 0.6.0 (released a month ago) and a couple of Inkscape tutorials. The website is by no means complete, but I was so tired of keeping the project to myself, that here it is My own short-term goals are:

• fill the gaps in the Web Links section
• finish FAQs for main products
• finish translation of Photoshop-to-GIMP migration guide
• translate Illustrator-to-Inkscape migration guide
• translate and publish my own GIMP and Inkscape tutorials
• finish and publish the bloody LGM’09 report

A number of reviews (Inkscape 0.47, Scribus 1.3.5, GIMP 2.7.0) are already written and just wait for actual software releases to happen.

There is a lot of work on wiki to be done, and we actually are missing the logo. I have a preliminary version which I’m not quite happy with and I’d be grateful for help on that.

Last, but not least. One of the points of this project is collecting information about libre graphics related activities. So we have a shared Google calendar. There is an open thread in forum where you can comment to tell us about events that are related to libre graphics software, and then we’ll add them. I’m talking about conferences, workshops, courses etc.

And, like I said, this is just one of the planned projects. Expect something else soon

I’m currently busy writing reports and sorting photos, but for now just few things:

• lightning talks are great and should be used further, but in some cases we still need long talks
• all talks in one room is good — everything is recorded
• more time for BoFs is good, we need even more of that
• BoFs should probably be recorded as well, at least audio
• we need all the attention of local designers and content producers we can get — publish articles in local thematic magazines perhaps?
• if we get this attention, we should better organize selling of books on using GIMP, Inkscape, Scribus and Blender (Blender movie DVDs too?) for little to no income, but publicity
• we probably need some handouts for free software — something in the lines of LGM’07 newspaper, but smaller
• we need a better academic track by all means

For the latter I think we should track scientific papers that relate to libre graphics tools.

Ay, and a small photo teaser for our LGM Flickr group

I want to once again thank all of our sponsors, especially our dear community. You are amazing!

You can still register to attend the conference.

LensFun as idea — a library to provide means to fix distortions and aberrations that lenses apply to captured photos — and a set of requirements was born two years ago at Libre Graphics Meeting in Montreal. As a real code it was born a bit later — you can read interview with Andrew Zabolotny by Joel Cornuz for details.

At this point we have a sophisticated implementation of LensFun in UFRaw, a quite simplistic yet working implementation in digiKam and somewhat forgotten test implementation in Rawstudio which hasn’t made its way to users yet — last thing I heard is Anders K. will probably do it soon now that Rawstudio has plug-in architecture. (And if he doesn’t, I will feel justified to renew my torturing skills that I got during my KGB secret agent course years ago )

Currently LensFun suffers from lack of a very much up to date lens/camera database. New lenses pop up every few months, but most of its data is coming from the last available open ptlens database (before it went proprietary). So I have an idea. If you happen to have lenses unsupported by LensFun and you are planning to come to LGM, bring them, and we’ll do a calibration session. The walls of École Polytechnique — our old/new venue — have pretty straight lines to rely on, and at least one pano head with leveller will be available

By the way, you can start registering for the conference now! And if you would love to do a talk on free graphics software, do get in touch — the program is still in the works

• Dave Coffin, creator of DCRaw
• Udi Fuchs, creator of UFraw
• 3×Anders, creators of Rawstudio
• Gilles Caulier, creator of digiKam

We were missing only Hubert Figuiere of libopenraw/exempi/niepce and Alex Tutubalin/Ilia Borgh of LibRaw. But the spirit of Tutubalin flew across the top of the waters of Oder for four days, so naturally Gilles couldn’t resist embracing the heavenly emanation and just few weeks later introduced LibRaw based libkdcraw Jokes aside, this library is now used across KDE4 graphics applications: digiKam, kphotalbum, DarkRoom and Krita. This is because Gilles heard about it at LGM in Wrocław.

You might as well ask, what is LibRaw and why it is better than the original DCRaw from which it is recreated. Alex’s “Goals and objectives” article pretty much covers covers this question, but you probably would like to hear from developers who use LibRaw. So I asked Gilles to write a short explanation.

And here it is:

— begin of quote —

1/ Introduction.
—————–

libkdcraw is a C++ wrapper to decode RAW images in different case and using a lots of demosaicing settings. It can also extract some metadata.

The first implementation of libkdcraw used an embedded dcraw binary program installed at the same time than library. This version of DCRaw was tested and valided to run properly with libkdcraw interface ad all options available from API for clients program. Why not to use the DCRaw binary version provided by a Linux distro? Because DCRaw options compatibility wasn’t preserved between main versions, and libkdcraw workflow could be broken with some combinations of settings.

DCRaw program is executed in a separated process and not threaded. A complex interface have been designed into libkdcraw to be able to observe progression of demosaicing and stop Raw decoding if necessary.

As more than one version of libkdcraw can be installed at the same time, a complex control of DCRaw install path must be done for each libkdcraw version to prevent conflict.

2/ Problems with dcraw. Why we need a low level library ?
———————————————————————

Using dcraw program in a wrapper library is a wrong solution to trying to have an homogeneous C++ interface:

• Performance: running DCRaw as a separated process is long to init by the system (more than to use children treads.)
• multithreading lock: a complex mechanism need to be done if more than one threads from client applications query libkdcraw at the same time. QProcess used to run DCRaw is not re-entrant, and application needed to wait than first query is done to ask another one.
• the DCRaw options interface is not homogenous and sometimes even obscure. For example, you cannot use all options available with 8 bits color depth demosaicing in 16 bits.
• There is no auto gamma adjustment in 16 bits color dept (a black image in 16 bits against a fine adjusted image in 8 bits). You cannot automate this workflow without big puzzle. Of course, it’s better to use customized settings to import Raw, and you can do it in digiKam, but some users want a fast way to open Raw images, as LightZone does.
• libkdcraw packaging is the hell, especially with DCRaw program install path, customized for each library release.
• Binary compatibility: if something changes in DCRaw option interface, it can be difficult to follow these changes without breaking binary compatibility.
• Metadata extraction is very limited and complex/slow to handle. DCRaw talks to libkdcraw true strings written/read from/to a command line pipe. It’s a hell to maintain and test.
• Due to using a pipe mechanism, following demosacing progress or stopping it is really complex to do.
• Due to using a pipe mechanism, memory allocation is not optimum.
• Last, but not least: DCRaw’s author has always refused to make a library and did not want to hear all recommendation from users, especially regarding improvements for worflow/interface (e.g. improving Raw decoding performance using parallelization of code).

3/ Using low level library : the ultimate solution
——————————————————-

Using a low level library as libraw instead dcraw, fix a lots of points:

• LibRaw is re-entrant. There is no lock mechanism to use anymore. We can use multithreading everywhere and query more than one demosaicing a the same time. Client application is faster.
• The interface have been reviewed with LibRaw developpers. Demosaicing settings are now homogeneous everywhere, especially in 8 and 16 bits mode. Users cannot see any difference between these modes.
• Demosaicing options compatibility will be preserved. Its more easy to maintain libkdcraw.
• All options are available directly by a C interface. Bye Bye pipe mechanism. It’s simple, fast and easy to maintain.
• Same with all metadata extracted. All are available thrue C interface.
• More metadata are extracted, as white balance, ICC color profile, photograph informations, color matrix (used with DNG converter), etc.
• Libraw is now parallelized using openmp library. Not all demosaicing sections are optimized in this way yet, but it’s in progress…
• libkdcraw packaging is really simple now. We don’t use an external libraw for the moment, until Libraw 1.0 will be published (current version is libraw 0.7.0). To update Due to use a pipe mechanism, libraw in libkdcraw, some C source code file need to be copied in an internal and private section. BC is preserved…
• New demosaicing algorithm have been introduced with libraw 0.7.0. It’s not only dcraw algorithms backported in a library, but a collection of code taken from another projects, as Rawtherapee for ex.
• Memory footprint from libkdcraw is very small as pipe mechanism disappears.
• Progress info is fully implemented in Libraw. We can provide a details of each operations processed (which can be long).
• Stopping demosaicing is easy to do, and very fast.
• LibRaw team is very open to discussions, so our work became very productive.

The migration from DCRaw to LibRaw was done just after LGM2008, where we spoke about LibRaw project. Rewriting libkdcraw code was done in a month, and optimization that to users feedback was done 2/3 month later. Now we have a powerful wrapper to play with Raw files. libdcraw is now included in KDE core and used by others KDE projects.

— end of quote —

DigiKam 0.10 was released earlier this week. Check it out and put it to a good use! They say that some of 0.11 features would be a new sophisticated batch manager and copy/pasting Raw development settings

By the way, some obviously mysterious winds have blown Hub’s libopenraw source code to Klaus Post who created RawSpeed library that is making its way to the next version of Rawstudio which will feature internal revamp, modularization and some great new stuff.

Who is going to win the Raw workflow battle — digiKam or Rawstudio? Or will Niepce Digital rise and take over? Support Libre Graphics Meeting and be the first to find out!

Fontmatrix, as Peter Linnell says, is THE application for Scribus users: it is a new yet versatile font management application. This was the first application in C++ that Pierre Marchand, its principal developer, ever wrote, and it’s amazing how far it’s gone so far.

I don’t think that it would be an exaggeration to call Pierre the next Franz Schmid. Just like Franz studied DTP by reading PDF specifications and created Scribus, Pierre studied OpenType and Unicode reading respective specs and created Fontmatrix. His attitude to variety of scripts is crystal clear: when you go to “Sample text” tab and click “Display options”, you see that the group of controls that defines inline and block progression, is called “World is wide”.

As he states in his unique humorous way, “People ask me about Devanagari support, but I don’t know Devanagari. I read Unicode specs, I fall asleep”

And this is what Pierre says about LGM:

“As you know, Fm is mostly my thing, so i would note at first what it did for myself. LGM has been the place where I’ve met LG people for the first time, from Scribus team to OSP gang and so much other type enthusiasts. It is important to compensate all this time spent alone developing a piece of
software with friendly relationships. It keeps up the motivation to go on. Secondly, Fm was rather unknown at that moment and it has been fantastic (well, it could have been even better with more sleeping time ) to present it to an assembly of type hackers. Time was a bit short to carefully harvest all ideas which have been exposed, but some have found their way in Fm.”

Since then Fontmatrix has undergone a lot of changes in SVN repository. First, version 0.4 was released in June, then the version 0.5 was silently released as an SVN branch, because Pierre didn’t consider it good enough for the public, and the work goes on.

The list of changes since 0.4.2 currently includes extracting fonts from PDF for issue investigation purposes, editing Panose data (changes are stored only in the database), HEX view of TrueType/OpenType tables, new classification (Panose) widget for fonts search which is, again, due to major redesign, new templates system, glyph comparison view (screenshot below), new help system shaping up and more.

But notably the next version will also feature Python scripting which will eventually open the door to all kinds of extensions. For instance, using FontTools.

So if you care about seing Fontmatrix progress further, please consider supporting the conference