What does GEGL (web) bring to the table that makes it so desirable? Basically, GEGL takes in any image (bitmap) and then applies operations to the image. Think curves operation, a bit of dodge or burn here and there and an unsharp mask (to keep things simple). Now the goodness of GEGL is that:

1. all these operations are internally processed by GEGL in 32bit float (the highest precision level available to mere mortals). So that means high bitdepth at last. Let’s just remember that our human eye cannot see nuances finer than 8bits/channel (which was the standard defined when memory and processing power was scarce). However, color modification (or even moreso black and white) when done in this limited bitdepth end up with very noticeable artifacts. So for serious photo retouching, you need high-bitdepth (and GEGL).
2. since GEGL gobbles in a bitmap and applies operations to it, you can save the bitmap (doh) and all the operations (and parameters) you applied to it. And you have access to all of your previous operations and modify them anytime (years later if saved in an adequate file format). To speak in Photoshop’s term, everything is an effect layer. And more: you can apply a series of operations to a bitmap and then copy and paste these operations to another one. And if you want to modify these operations you can decide if your modification will be applied to both objects or just one. Pretty nifty? YOU BET.
3. Lastly, GEGL allows its operations to be executed by the CPU (slowly) or by the GPU (fast). Some operations are already accelerated via OpenCL and the 2011 Google Summer of Code students got temporarily hired by AMD to further work on his project.

The long story of GIMP GEGL integration

The only problem is that it has been 10 years (or so) that we have been waiting for GEGL to materialize. This is now done for several years, thanks mainly to Øyvind ”Pippin” Kolås. And then some more (years) for GIMP to start using GEGL – and start delivering all the GEGLified goodness to its belated users. The recently released 2.8 version of GIMP has been dragging and although it started using GEGL for some of its operation, has been mainly about updating the user interface – to offer the single-window interface that is lovely, by the way. But still, for real photography work, we need higher bitdepth.

This spring, however (just before the release of 2.8) Øyvind Kolås and Mike “Mitch” Natterer gathered for a week to test the feasability of the approach they had in minde for the port of GIMP core to GEGL. As it happened, the approach worked so well, that the one week test, turned out to a 3 weeks hackaton were 90% of the GIMP core was ported to GEGL. It is worth reading Mitch’s blog on the subject – picked by Slashdot where the whole discussion was about the hackers “inadvertently” porting GIMP’s core to GEGL. No, the story doesn’t tell how much beer and pizza were consumed during these 3 weeks.

But what came out of it was a branch called “goats invasion” which has since been rebased to master and is now where the current GIMP developement is happening and which will be release as GIMP 2.10 – and the incubation time for this release should be much shorter than for 2.8.

What do we get (or not)?

So what do we get from this goats invasion? Well, GEGL is now used inside the main GIMP processing pipeline and we can now load and work on images with higher bitdepth (YEAH!). Most of the GIMP interface is the same, except for one submenu: precision. Saving files as xcf allows for high bit depth and 16bits PNG is supported but not tiff (yet).

What do we NOT get (yet)? Well, most plugins aren’t ported to GEGL yet, so if you need to oilify an image in 16bits depth, you are out of luck. As with any software being under active development, expect crashes – sometimes with an Eeeek and how many GEGL buffers where leaked to memory.

Note that accelerating GEGL via OpenCL/GPU is a GEGL-only project that can get going independently of GIMP development.

How to get this goats goodness? You basically need the git version of GIMP (as well as gegl-git and babl-git). Be warned though that GIMP is big and takes a long time to compile. But you will be rewarded by a precision submenu and quite a few crashes Of course, if you find a repository with gimp-git for your distro, you’re all set.

What is next?

So with the goats invading GIMP, we have the first goodie of GEGL nearing: high bitdepth “for free” (as in part of GEGL’s standard mode of operations). What about the other one – unlimited history and “everything as effect layers”? Well, that is for later versions, since this requires quite a bit of UI design (for which Peter Sikking has a plan – or a least a blog post). So 2.8 has been released recently, 2.10 will be about GEGL and high-bitdepth. GIMP 3.0 will be about porting GIMP to GTK3 and then will come the UI revamp for GEGL operations. Although release times should be shorter, there is still quite a long way to go to fully profit GEGL goodness.

But what is maybe the most encouraging of all is that GIMP is finding back an enthusiastic community. No longer is it fashionable to grumble about the GIMP (like I have done so much in this blog), no longer are whining users met by disgruntled developers. If you look for GIMP on Google+ (almost) every new post is met by positives comments – it looks like enthusiasm is back to the GIMP camp: good to see more and more GIMP fanboys (and girls) raise their voice and cheer the vailiant developpers.

And of course…

Here is my first image processed entirely in 16 bits / channel: developped twice with Rawstudio (once for the sky and once for the ground) in 16bpc PNG, opened and mixed with GIMP. Let’s say that this pic has more technical than artistic value (notice the polarizer vignetting at the bottom )

This is a truly unix-philosophy tool: one tool for one purpose, but do it well. So Rapid Photo Downloader will allow you to:

• download your images to a defined directory
• rename them in the process
• create a backup copy at the same time

and the beauty of it is that it is very simple to configure: a few clicks and you define where the photos will be downloaded, how they will be renamed, where the backup will be and if you want RPD to start doing its job automatically when a new device is inserted.

Here is what the preference windows looks like (for my work habits, obviously):

and here is Rapid Photo Downloader in action:

Interested? You should! Have a look at Rapid Photo Downloader’s website, including installation instructions for major distros.

And just to keep a tradition alive, here is an “autumn in Montreal” image:

Michael Reichmann – The Leica M9, a field review

Joe McNally – a photographer’s best piece of equipment (youtube video)

Comment anyone?

We are making pretty good progress towards GIMP 2.8 which has turned into an “everything but GEGL” release. I think it would make sense to also go for a single-window mode in 2.8 and not 2.10 as originally planned.

[...]

I intend to start working on this asap, and peter will work on a UI spec as soon as he gets time. If you have objections, please speak up.

/ Martin

Obviously, quite a few people spoke up (read the thread).

This also prompted Peter Sikking (GIMP’s UI designer) to blog about the issue: why this is desirable, what are the advantages and problems, etc. Peter also introduces the “image parade” to see the currently open and recently used images. Very interesting stuff (ie: read the blog post).

While it is always good to see progress in open source software, my personal taste would have been to get 16 bits support so that GIMP gets actually *usable* for photographic work. Still, kudos to the GIMP’s team for their work and best of luck with GIMP 2.8.

(But hey, based on how constant I am at updating this blog, who am I to lecture others??)

Now during the recent Libre Graphics Meeting, there was a short talk (I don’t remember the speaker) about “What’s new in GIMP 2.6?” and one of the hotness is the very explicitly named c2g feature, conveniently buried in the GEGL operations (sub-)menu.

And guess what? c2g is a black and white converter… maybe the ultimate one.

The other good thing about conferences is that you get to actually meet people, so I had a chance to listen to some more explanations from Øyvind Kolås (aka Pippin), c2g’s author. I say listen since I was the least technical guy around the table so there was not much talking on my side; which is also why I hope this blog post is accurate – please correct me if someone knows better.

The idea behind c2g is to convert each pixel to B&W using an optimal white balance: the black and white points are calculated for each pixel according to its surrounding, giving the closer pixels more weight (and following a gaussian curve). And basically this mimics the way our human eye perceives the image – how we perceive a color (or grey nuance) depends not only on its value, but on its environment.

You probably came across this optical illusion: both greys in the middle are of the same density (value) but one is perceived clearer than the other because it is surrounded by a darker tone than the other one.Now if I process the image with c2g, here is what I get:See the idea? The absolute value of the greys in the center are “corrected” to “fit” our perception. By the way, this is with every c2g value left as default, except samples set to 10 – resulting in a longer processing time, but less noise.

The best way I would describe what c2g does is masking done automagically right for maximum contrast. For the purpose of illustration (rather than for artistic purpose) take this photo:

And this is what you get with c2g – default parameters except a radius set to 280 for a more dramatic effect on a small image:

Just for comparison’s sake here is the Luminosity (from HSL):

Øyvind has a comparison between several more B&W conversion methods (including c2g, obviously).

What do you think? If c2g is not the ultimate B&W converter, it is darn close to it, if you ask me. By the way, here is the comparison’s image processed with c2g:

Basically, Phraymd is an image collection management tool: it allows you to work on your images metadata – tags, titles, copyright, etc which is stored inside the image itself. You can then search through your image collection, modify metadata in batch, etc.

This is what Phraymd does. Just as interesting is what it does not: image editing. Don’t look for a red-eyes removal tool,  brightness and saturation cursors or black & white conversion. However, Phraymd makes it very easy to open your images in an external editing program (GIMP, gThumb and others).

Phraymd is coded in Python – it uses wrapper around standard libraries. To quote from the webpage:

• Emphasis on a snappy interface. All the heavy lifting is done on background threads or external processes to ensure the UI never blocks. User is informed of what is going on in the background with progress notifications etc.
• Keep metadata in the images where it belongs. To the extent possible, databases/indexes are temporary files that can be deleted without losing useful data.
• Simple notion of a photo collection: all of the images (jpeg, png, raw etc) in a directory including its subfolders. A database to speed up image lookup is maintained in the users home folder.
• Database keeps track of image metadata for speedy search and sort of images (the database can be recreated from the underlying images)
• Support collections with 10,000+ images (currently, the program should run ok with 100,000 images but may use a lot of memory — that can be tweaked)

On the UI side, Phraymd uses onmouseover overlays to present you with basic information about the current image.

Sounds interesting? Here is what Phraymd looks like after you have chosen your image directory:

Here it is when you are working on a particular image – note in the above toolbar that I am working on the subset of images tagged for Montreal.

And here is the metadata entering dialog:

Lastly, a few more notes from Damien:

• “phraymd” is just a working title — I’ll hopefully find a better name by the time its ready for mainstream consumption (branding seems to matter).
• phraymd is in its very early stages (I started coding in about January), a part time project with a team of 1 (and even he isn’t a programmer by trade).
• feedback is especially welcome: I set up a google group, or people can use Launchpad to create bugs or ask questions.
• volunteers are welcome to join the project (code, docs, art etc)

Have a look at launchpad and google group, test Phraymd and let Damien know about your experience, suggestions or help. I have this feeling that Phraymd could well be filling a much necessary need in the Linux for Photography eco system. My only wish would be to be presented with a list of tags to tick rather than typing them each time (with typos which make subsequent searches impossible).

Dear Joel,

We stumbled upon your “Linux Photography” blog a few months ago and have been following your posts for some time. While your attempts are valiant, they are also somewhat pathetic – or so we feel.

We at Apple, don’t sit around criticizing others. Rather we deliver solutions. Therefore, we have shipped to your place a brand new MacBook Pro with the latest Mac OS X. It comes loaded with Apple Aperture and (as a special treat from our partner Adobe) Photoshop CS4. This will show you what state of the art operating system / photographic software can do for photographic work.

We hope you will appreciate this gift and look forward to your next blog entries.

Best regards,

XXX, Apple Marketing

Now today (and to my complete astonishment), the UPS man rang at my door and brought me a huge box shipped from Cupertino… after unpacking and plugging in, all I can say is “Wow!” – the hardware, the OS and the photography functionalities just look stunning.

At that stage, I am not too sure when I’ll reboot one of my Linux computers…

The idea

ArgyllCMS (blog 1, 2) is a Linux / Windows / Mac OS X set of command line utilities for color management – including but not limited to monitor calibration. So dispcalGUI is a make-your-life-easier frontend to Argyll which allows monitor calibration. This is especially handy since creating a profile with Argyll involves several steps with quite a few command line options – “dispcal -v -q l -y c samsung” anyone?

Installation

dispcalGUI comes blundled in a very “windows-like” installation package (and indeed, it works on MS-Windows, MacOS X and Linux). Just download the package, extract it and go through the installation process. You will need to point it to your Argyll installation, click a few “next” buttons and you are done.

Using it

Before srtarting using dispcalGUI, you need to plug your calibrating device and make it user writable (just like with Argyll). Type lsusb in a terminal to find your device busid and deviceid and then type:

sudo chmod 777 /proc/bus/usb/busid/deviceid

That will be it for the command line.

You can now load dispcalGUI. This is how it looks:

Functionalities are the same as Argyll’s – ie quite complex. DispcalGUI has a manual well written and quoting relevant part of Argyll’s – so RTFM. Otherwise, you can just check that the right monitor / instrument are picked. Chose your monitor type (LCD or CRT) and the calibration and profile quality. Leave the rest to default. Click on calibrate and profile.

After a (relatively long) time and a couple “y” or “any key” in the terminal, you will get an icc profile which you can load with dispwin or xcalib (for screen calibration) as well as your graphic application (for profiling – if the application supports it). Check this entry if you need to know more about color management.

And that, ladies and gentlemen, means one less item on the Linux & Photography todo list.