Darktable is pretty much modularized, so creating new stuff is rather easy. We’ve seen a number of contributors who come up with a complete new darkroom plug-in in practically no time. Most recently it was Rostyslav Pidgornyi with his “low light” plug-in that reuses our spiffy curve widget to provide simple UI for simulating human vision adapting to various lighting conditions.

If you like the idea of doing a GSoC project for us, you have nearly three weeks (till April 8th) to think about a project, introduce yourself, get accustomed, prepare an application, discuss it with your mentor and submit it.

I’m very happy my good friends are playing gigs again. There are two albums in production, hopefully to be out soon (under CC as usual).

Do we have to care, if Luminance HDR compiles and runs? Yes and no. Here is why.

As a photographic technology, HDR imaging has a mixed group of users: from point-and-shoot people who want their photos to look cool (mostly they want overprocessed look) to hardcore professional photographers who know what a response curve is and probably had a drink with Debevec back in 1980s.

The problem with Luminance HDR is that it doesn’t work very well for all possible groups of users. Beginners want a no-brainer UI without any of the currently existing cryptic options that are mostly undocumented and don’t even have tooltips. Advanced users want some things to get out of the way and more reliable processing (larger-than-RAM images handling is still not available).

Even with Enfuse being available there still is and will be a demand for “true” HDR. The solution as I see it is to start from scratch. The tools?

Back-end. GEGL is a clear winner. Danny Robson ported pfstools and three pfstmo tonemapping operators to GEGL this summer as part of his Google Summer of Code project. He implemented saving and loading RGBE images (.hdr) too. GEGL can also handle larger than RAM images, has code for GPU-side rendering and support for multithreading (albeit buggy at the moment).

Toolkit. I don’t care. I really don’t, as long as building installation packages for Windows and Mac users is simple and takes no more than 30 minutes of anyone’s time (because it’s boring even for contributors). I’m neither Windows nor Mac user, but they tend to be quite vocal (noisy, sometimes), so it’s best to keep them happy to spare time in the long run.

Usability. The most tricky part. In short, you can’t make everyone happy, and attempting to do so is likely to make everyone hate the result instead of loving it. In my opinion it’s best to target at advanced users, while making UI simple enough for beginners to get started with the tool. Worst thing in Luminance HDR is literal implementation of scientific papers. Nobody really needs that.

Interoperability. Apart from supporting various file formats there should be a way to submit a rendering job to the tool and get the output in managed manner (think of render farms, photo management software etc.).

Extensibility. There are all sorts of things you would want to do with an HDR image or its tonemapped version in-place. Some of the well-known tricks are merging outputs from different tonemapping operators as layers in various blending modes. Being able to reprocess one of the “layers” in the stack with different options sounds like a sensible idea to me. Or cropping in a non-destructive manner. Again, GEGL can come to aid here, so some features could be plug-in based and implemented as GEGL ops.

Such a project would need a real team of several contributors. I’m not asking for any takers, I merely “possess the greatest of all treasures which is Hope” But if somebody wants to work on this, I’d be glad to stick around, do some PR, docs or whatever boring non-coding work you might need to have done.

Most important things that demand attention:

• fix what was broken after upgrading to newer pfstools
• fix broken cropping (yes, SVN trunk has rectangular selections and cropping)
• find out what went wrong with reinhard’05
• fix the broken result size combo
• bring batch tone mapping back to life

There is bunch of ideas how to make Qtpfsgui easier to use (make it not expect PhD from users, for instance ), so anyone who would like to go even further than just bugfixing is surely welcome Please contact me for details.

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!

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!

• saving options moved to a separate tab of a main window;
• Exif is embedded into TIFF files (you need Exiv2 0.18-pre1 and newer);
• improved greyscale conversion (using a color mixer too);
• experimental LensFun support;
• experimental linear contrast slider;
• color temperature can go up to 15000°K.

And two weeks before that LensFun 0.2.3 was released. I think both Udi and Andrew deserve a really big hug! It’s too easy to forget saying a thank you, when people invest time into work which results we often take for granted.