[weekly report] week 9: Raw processing in F-Spot

[Ruben Vermeersch <ruben savanne be>]

Time for a big status update and a bit of recap on how the GSoC
progressed. There's good and bad news in here.

My project is related to the handling and processing of RAW files. In
the current F-Spot, RAW files are a bit odd creatures. You can view them
(if they have an embedded preview), but you can't edit them, can't
export them, can't do anything with them actually. My goal was to change
this.

The first thing I noticed when I started out was that the way images are
loaded in F-Spot doesn't make it exactly suitable: everything happens
synchronously and is pretty much aimed at loading big JPEG files (which
load reasonably fast). There was one bit where images were loaded
asynchronously: image displaying. I've spent the first couple of weeks
on working out a loader infrastructure that might solve our problems and
make it possible to load RAW files (which might take 20 seconds to
process), without hanging F-Spot [1].

Around GCDS, I started hooking in a RAW loader based on libraw, which in
turn is based on dcraw, probably the most complete RAW processing
program out there. To do this, I wrote a GObject-based wrapper library
and C# bindings for this wrapper library. Some hacking later, we now
have a pretty smooth RAW displaying behavior: when you click on a RAW
file, it instantly displays the embedded thumbnail, no waiting. It then
starts loading the RAW file in the background, such that after a while,
a user gets to see the full 100% quality version [2]. As this processing
can take quite some time, I modified the view such that it replaces this
image without resetting the view. This way it doesn't interrupt the user
workflow, when the RAW is processed, the quality improves, but no other
strangeness happens [3].

With this work done, I can fix most of the problems related to RAW
handling: exporting and the basic editing (e.g. crop) are things I can
add fairly quickly. This will make RAW a first class citizen in F-Spot.

Now that was the good news. On to the bad news.

I can already hear the true RAW users thinking: what about RAW
processing, sliders to adjust my white balance and see the result in
real-time (somewhat like ufraw or lightroom)?

Well, the outlook is looking less happy there. To add GUI-style
interactive processing, we need a processing framework that will quickly
give a preview, preferably rendered progressively, such that we can
start displaying the partial results when they are ready.

There are a number of options to use here, but none of them are ideal:

         * (1) Libraw: libraw, which I use to load RAW images exposes
        the post-processing options of dcraw. I contacted the libraw
        authors about this: you're either stuck with the very slow
        non-progressive processing with dcraw, or you'll have to roll
        your own (see 2). Using the processing exposed in libraw means
        that a user will have to wait about 15 seconds to see the
        results. Not exactly smooth at all. Since we can't directly call
        these post-processing methods on a downscaled sample, it's also
        not possible to make a quick preview. The dcraw code base is
        written to be unreadable and non-reusable.
        
         * (2) Rolling your own postprocessing: In this scenario, libraw
        is just used to decode the file, after which I will have to
        write all the processing code myself. Not very convenient
        either, as RAW files differ massively, which means that this is
        a ton of work to get a viewable result. What makes this even
        harder is that GdkPixbuf only supports 8bit images, so I'll even
        have to reimplement that. A good option if I had a whole year of
        time.
        
         * (3) Using GEGL [4]: On paper, GEGL provides the ideal
        processing framework: it does most of the operations I need and
        it handles high bit depths. As such I implemented a loader based
        on that [5]. This would give a nice progressively rendering
        pipeline. Unfortunately, simply demosaicing a file (the very
        first step of processing) already takes 2 minutes using GEGL. So
        that's not an option either.
        
         * (4) Use whatever ufraw does: Turns out ufraw is a very
        extreme refactoring of dcraw, which in turn is as messy as dcraw
        itself. If you need a good horror story, this is code to read.

As you can see, the options are quite limited. As such I'm less
convinced that proper post-processing like ufraw will not be feasable in
the coming month (or months for that matter). I had not anticipated the
state of things to be this bad when starting the GSoC.

So where does it leave the project? Should I smack together an unusable
hack to have something (but will never be merged to master anyway)? Or
should I focus on the other RAW handling, leaving post-processing for
ufraw for now, such that I can come up with a clean smooth experience
that can be merged almost immediately.

I'd prefer the second option, there's still a ton of work to do in the
F-Spot codebase to make image loading smooth and clean, so I'm expecting
more problems to surface once this gets stressed. So no knobs and levers
just yet, but for the rest, RAW handling would become nice and smooth in
F-Spot. But I'm not sure if that's ok for the GSoC.

Ponder ponder. Going to hack on RAW handling a bit more, this mail is
already longer than it needs to be anyway.

   Ruben

Note: the dates are off in the gitorious summary due to rebasing :-(
[1]:
http://gitorious.org/+f-spot-developers/f-spot/rubenvs-clone/commits/unified-loading
[2]:
http://gitorious.org/+f-spot-developers/f-spot/rubenvs-clone/commits/libfspotraw
[3]:
http://gitorious.org/+f-spot-developers/f-spot/rubenvs-clone/commits/preserve-offsets-zoom
[4]: http://gegl.org/
[5]:
http://gitorious.org/+f-spot-developers/f-spot/rubenvs-clone/commits/libfspotraw-gegl


--
Ruben Vermeersch (rubenv)
http://www.savanne.be/