Summer of Code 2009

Three weeks since the end of GSOC 2009 and I still haven’t managed to blog about it. Shame on me! This summer I worked on RAW handling and processing for F-Spot. In the long term, F-Spot should become a capable image processing tool, like e.g. Adobe Lightroom. The purpose of this GSOC was to get a step closer towards that goal.

There are three big issues that need to be solved to get there:

  • RAW decoding and loading
  • RAW processing
  • Repeatable (non-destructive) editing

RAW decoding and loading
RAW files are generally stored in an undocumented, proprietary format, which often varies per camera model. Decoding these files was something F-Spot did not attempt to do yet. During this summer, I refactored the image loading facilities in F-Spot towards a unified loading model, into which I hooked up a new RAW loader, based on LibRaw.

This means that F-Spot can load and display any RAW file supported by dcraw (upon which LibRaw is based). That basically means all RAW files.

RAW processing
A big task in handling RAW files is processing: transforming the raw sensor data into RGB pixels, applying white-balance and gamma corrections, noise reduction etc. All of this needs to happen in a high bitdepth (10, 12 or 14 bit) for optimal quality. I investigated three paths here: reusing the dcraw processing routines, GEGL and hacking it up myself.

Trying to reuse the processing routines from dcraw was a nice way to learn how much of a horror the dcraw code is. Certainly the most bizarre code I’ve seen to date. Also, these routines were not reusable for e.g. JPEG, which would have meant that we needed to implement things like white balance adjustment twice.

Plan B was to use GEGL, the great image pipeline that will power The GIMP. While promising, it was still way too slow to be usable (minutes of time needed to load one RAW file).

Plan C involved hacking it up myself. This would have meant changing GdkPixbuf to support higher bitdepths and write a ton of very complex computation algorithms.

In the end, I made the wise decision not to try to build a high bitdepth pipeline and focus on the other tasks. For now, I let LibRaw do the initial processing, up to the point where we have an RGB image, which is then handed over to F-Spot for further processing.

Repeatable (non-destructive) editing
The third task was repeatable editing. To go for the Lightroom experience, with all the knobs and wheels to adjust, we needed a repeatable editing framework. Those familiar with F-Spot know that all editing is currently destructive: each operation creates a new JPEG, with the quality loss that goes along with it. I wrote the first version of a non-destructive image processing framework and converted all color operations to it.

It means that we go from:
original --> editA --> editB --> editC

to:
original + adjustment settings --> result

This is a good thing, every arrow means potential quality loss.

Fish!
Purple fish? Green fish? Experimentation allowed!

So, what’s next? Where are we at?
This code is not merged yet, as there are still some things that need to be worked out. Those who want to try it (make backups, your database will be changed!) can find it in the libfspotraw branch on Gitorious. Alert readers will have noticed that we are not there yet, which is true, but given the size of the task, that was to be expected. We are however a lot closer in the right direction. More information and details can be found in my final report email.

In the meantime, I have started hacking on another important issue related to F-Spot. But you will have to wait until I have returned from my trip to Lisbon (leaving tomorrow, coming back Sep 18) for more details.

September 9, 2009 17:34 #summerofcode #mono #gnome #f-spot

Related

Comments