Together with Mike Gemünde (tigger), I am happy to announce that we are working on adding image support to Taglib#, which is the metadata library used by Banshee and currently only supports audio and video files. So why is this important? Because we will be able to vastly improve the metadata handling inside F-Spot. Furthermore, should Banshee ever decide to add photo support. it'll be ready for them to use.

The aim is to have a usable, complete and solid metadata library. This includes extensive unit testing (to the extreme). If we will handle your files, we want to guarantee that it will be done correctly.

All of this can be found on Gitorious. The code is in the photo-support branch of the mainline repository, master is a copy of the SVN repository for upstream Taglib#. Currently we support JPEG and TIFF, with Exif and XMP (see the wiki for more details). We plan to expand this to every other format out there. More instructions on how to get the code and test it can be found here.

So what's the plan here? First, we will improve the git version as is. When it is ready, we will then start embedding it into the F-Spot tree (while keeping the main repository synced in gitorious), to let it mature. Over time, we'll be working with upstream to have it merged back. I have already talked with Gabriel Burt about this, so this "fork" won't stay around forever.

We are looking for people that want to help us out. By testing it (to make sure we handle your files correctly) and off-course by hacking on it. Much to my surprise, I noticed that writing a metadata library isn't all that hard, so you don't have to be a superhero hacker to be able to do something useful.

Want to help out? Hop onto IRC and join #f-spot (on irc.gnome.org), come and talk to me (rubenv) or Mike (tigger).

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.



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.

As Stephane mentioned in his blog, F-Spot 0.6.0 is out.

Some of the highlights of this release (in no particular order):

• This release contains the folder bar, which I previously blogged about.
• This is the first release where we all used Git and it has massively paid off. Contributions are flowing in at a massive rate, from lots of people. See for yourself on Gitorious. Now that the release is out, it's time to go over merge requests. It's hard to keep up with them.
• F-Spot is getting ready for GNOME 3, with the introduction of GIO/GVFS and GtkBuilder. There are still parts of the code using the old stuff, but we're gradually replacing it.
• Bugs fixed! Over 120 bugs have been closed between the previous and the current release. This number does not include duplicates.
• And perhaps the most important: we're retooling things, refactoring and cleaning, which was much needed and will allow us to make it better faster, make it easier to add stuff and simpler to contribute.

With the pace going up and the codebase improving, you can be sure to see great stuff in the future of F-Spot! Oh and if you'd like to help build that future, drop on by on IRC: #f-spot on irc.gnome.org.

A little while back, Mike Gemünde (tigger) wrote one of the nice features that will be present in the upcoming F-Spot release (really soon!): the folder bar. What is this? It's a new sidebar page that shows the folders in which your photos are located and allows you to browse them by folder.

While we still believe that you shouldn't be bothered with files and directories in F-Spot (and focus on photos), it's impossible to hide this completely: laptop users can't store all their photos on the internal disk and often need an external hard disk. And some users are really fond of their directory structure. We're not trying to impose anything and this is a first step to give the users the freedom they want: browsing by directory. This is in git right now and will be present in the upcoming release.

Future things we should support can include things like support for external USB hard-disks. Want to see that happening? Come over and have a chat, we're always looking for extra developers and user interface designers.

Last week at GCDS, we rented a minivan and road-tripped around the island. One Banshee hacker (Bertrand), one F-Spot hacker (me) and six guys from the GNOME art team (Garrett, jimmac, Benjamin, Andreasn, Vinicius and mpt). From a risk management point of view, this was suicide, who whould do our artwork if we drove into a ravine? Fortunately, that did't happen, we had a great day and I can write this blogpost, a tale about design.

We were already aware of it, but hadn't fixed it yet: the F-Spot preferences dialog is totally netbook unsuited. And it is extremely ugly. Behold:

During GCDS, I was approached by Matthew Paul Thomas (mpt). He wanted to redesign our preferences dialog and fix it. We had a good chat and ran over the current preferences dialog, what it does and why. Two or three hours of sketching and drawing later, he presented this:



It's a simple paper mockup, describing the current dialog, what's wrong and how we can improve it. This was then followed by a proposal for a new design. For a hacker, this is gold. We generally aren't the best user interfaces designers (let's just admit it), but we do like good design. When given a spec, we can make things happen quickly. This mockup made sense and it was sound: it follows the HIG.

I handed it over to Stephane Delcroix and an hour of hacking later, we had a new preferences dialog:



Much nicer!

The moral of the story
The moral of this story is twofold:

• For hackers it's important to realize that our artwork team isn't just a bunch of guys with an obsession for pretty icons. They also do our visual styling and help us design great interfaces (one of the things that made GNOME to be a success). If your interface sucks, turn to them.
• For designers: we love you and even if you don't feel like coding, a simpel well thought-out mockup can have a huge effect. If you feel stuff is suboptimal, go to the maintainers and talk to them, usually it's not a big change, but with a large result. And generally maintainers love UI suggestions, if they make sense. And as a shameless plug: we at F-Spot really love UI designers, we know it isn't what it should be and if anyone wants to help with these kind of things, do get in touch.

It's this kind of cooperation that makes the GNOME community such a nice place to be in.

Somebody dropped into #f-spot on irc.gnome.org a few days ago and asked:

Fortunately, the answer is yes, F-Spot is very much alive and kicking. It's true, the pace was down for a period of time, mostly due to people getting precious time claimed by other obligations. Things are coming back up to speed lately and that's what this post is all about.

Build problems: resolved
F-Spot was quite hard to build for some time, due to a dependency on gtk-sharp from SVN. On top of that, this led to bugs for some users. Two weeks ago, sde came in and fixed it all.

Building F-Spot should now work on all modern distributions, without the need to install libraries from source. You can get it at git://git.gnome.org/f-spot.

F-Spot and Git: the power of DVCS in action
We've set up an automatically synchronized copy of the F-Spot git repository on gitorious.org. This allows external contributors to branch and publish their work, in such a way that we can track it. This has paid off, as you can see over here: http://gitorious.org/f-spot/. There's a buzz of activity with lots of cool branches being worked on. We love git, many thanks to the guys that made it happen, it's making our work so much nicer!

What's cooking
Here's a short rundown of what people are working on (remember, this is all very experimental and beta, no promises on it ever getting released):

• Mike Gemünde (tigger) is currently cleaning and refactoring quite a lot of IconView code. This will get our codebase into a much leaner shape, which will make future modifications much easier. He is also working on adding geotagging.
  
  
  
  Setting geodata (click for larger version)
• Paul Wellner Bou (piz) is working on a lot of stuff, including a nice extension that allows you to compare different image versions.
  
  
  
  Compare versions
• Lorenzo Milesi (maxxer) is taking care of bugzilla. Incidentaly, he also blogged about all this stuff. This is not coordinated, but it does nicely confirm the extra buzz I was talking about.
• Wojciech Dzierzanowski is working hard on Tabblo exporting to make it rock hard.
• And as for myself: I've been prototyping some stuff related to progressive image loading and preloading. I'm also looking into RAW processing for my GSoC. All of this is going at a rather slow pace as I'm in the final stages of writing my masters thesis.

Many hands make light work
It's true, F-Spot is far from perfect and we're all too aware of that. Also, there's so many cool features that we want in there, but haven't found time to build it yet. But we all want to build the nicest photo app there is.



And you can help with that! If you know how to program, join us on IRC and feel free to poke me. Many hands make light work and currently most of our hands are already overoccupied. We have plenty of feature requests already, so unless you want to program them yourselves, you'll probably just have to wait for it.

UPDATE: Due to me incorrectly parsing gitorious.org, I wrongly quoted Lorenzo as doing the Tabblo work. While he is helping to get it merged, it is Wojciech who deserves all the credit for the development, sorry for that!

GNOME just got 25 students accepted for GSoC 2009: check them out here.

I'm happy to be one of them, working on RAW for f-spot.

Less pleasant news, it turns out I'll have to withstand Stephane Delcroix' terror reign another summer to be his student slave ;-).

Extra! Extra!

We've just released the most awesome f-spot so far: 0.5.0! It features a countless amount of enhancements, polish and bugfixes. Here's some appetizer, but you'd better taste it by yourself:

- New Sidebar context switching
- Extendable Editors
- New Metadata display
- Color profile support
- Duplicate detection at import time
- Reduced and faster db access, faster queries on big collections
- Light speed tagging
- FullScreen mode enhancements
- New extensions distributed by default
- Updated documentation
- Updated translations
- Hundreds of bugfixes
- New contributors

We'd like to thanks everyone involved in that release cycle, bug reporters, triagers, testers, developers, translators. So thx, and keep up the hard work.

The minimal dependencies should be as they were for 0.4.4. But if you want to build for gnome 2.24, you'll probably need gtk-sharp 2.12.3

Just in: The new sidebar editors in F-Spot have landed. Apart from the color tool and some cosmetic changes, it's mostly finished.

Also: F-Spot now features a histogram in the sidebar.

That is all.

PS: F-Spot already had the histogram. It was just very well hidden.

When it comes to performance, F-Spot hasn't always been the best of it's class. Part of my Summer of Code time has been spent on improving that. While reworking the editors (which will land soon), I ran into trouble spots, which I've started fixing. My mentor improved in these.

To show the difference, I've made a small unscientific benchmark. Below are the times needed to add 2 tags to a set of 1000 photos. During this amount of time, the user interface freezes.

Observe how the whole UI freezes for over 20 seconds in the currently released version. In SVN, you hardly notice it happening! This is a 44.5 times speedup!

Similar improvements are to be found everywhere. I'm most fond of the fact that the image doesn't reload anymore while adding tags. This means using type-to-tag (the t-hotkey) is now completely instant and a joy to use.

All of this is in SVN and will be available in the next release.

Google Summer of Code
Lots of activity around F-Spot lately. As there's a number of people very curious about what I'm doing, I've made a small screencast providing a sneak preview.

In the screencast I first highlight the old editing tools below, which are quite hidden. I then show you how the new tools will be implemented.

The UI is still very basic, as my GTK+-fu isn't all that strong.

F-Spot performance enhancements
At the same time, both Stephane Delcroix (my mentor, who should really blog more!) and me are working on big patches to improve F-Spot performance. Expect a much smoother experience soon!

Great news from F-Spot land!

F-Spot 0.4.4 released
First of all, the new F-Spot 0.4.4 is just released (credits go out to Stephane Delcroix, who should really start blogging more).

From the release notes:

About a month after 0.4.3.1, we've released F-Spot 0.4.4. It features
some new blinky features, a better gnome and gnome2.22 integration,
updated translations and tons of bugfixes.

Major changes since 0.4.3.1:
- theme switcher
- reduced startup time
- migration to gio started
- sort tag by popularity
- rating with hotkeys
...and more

And, as this release is a pre-Soc one, more fun stuffs are coming.

More info here, downloads also on the website. This immediately marks the point where I can start pushing my GSoC code into trunk. So without further ado:

Google Summer of Code work started
One of the major problems F-Spot currently has is the space-wasting sidebar:

As you can see, it shows some information and a tag tree to search images. Not all that bad actually. Now when you switch to an image, you get the following:



The tag tree is quite useless in this view (except for tagging, if you don't use the awesome tag-to-type 't' key). On the bottom of the screen, there's a tiny row of editing tools. My Summer of Code work aims to improve the F-Spot experience, in part by moving these hard to find tools to the sidebar, where they will be much easier to use (and take up less space).

I have just landed the first bits of code, based on an old bitrotten patch, which makes the sidebar switchable. Currently there are three panes, looking like this:



This code still has a lot of issues though. For instance, the information box on the bottom left is gone. It'll be back, soon. Slowly the summer has begun, with plenty of cool stuff coming up. Stay Tuned!

It is now official, I have been selected to participate in the Google Summer of Code. I will be working on F-Spot, a photo management application. My mentor will be Stephane Delcroix, who is already trying to trick me into bringing him breakfast.

The last few years I was occasionally involved both in F-Spot and Banshee. Now that Banshee is totally rocktastic, it's time to make F-Spot shine.

I will be working on the Sidebar, most specifically integrating editing tools. You can read my proposal over here. This is based on Jimmac's awesome mockups.

Now here's your chance to add your pet peeve: I'd like to invite everybody to let me know of their favorite features which should come in the sidebar. I'll stick to my proposal for the coming summer, but I'd love to know what people are really waiting for. So e-mail me or comment with those suggestions, if they're really good, I might even squeeze them in!