Stuff to look forward to at FOSDEM 2010: The GNOME room and for the first time ever: the Mono room. And seeing everybody again, off-course. Can't wait!

I am happy to announce that the schedule for the Mono developer room at FOSDEM 2010 has been finalized. We have a lot of great talks lined up for you to enjoy:

09:00 - 09:15	Opening (Ruben Vermeersch, Stéphane Delcroix)
09:15 - 10:00	MonoDevelop (Lluis Sanchez Gual)
10:00 - 11:00	The Ruby and .NET love child (Ivan Porto Carrero)
11:00 - 12:00	Mono Edge (Miguel de Icaza)
Lunch Break
12:45 - 13:15	The evolution of MonoTorrent (Alan McGovern)
13:15 - 13:45	Image processing with Mono.Simd (Stéphane Delcroix)
13:45 - 14:15	ParallelFx, bringing Mono applications in the multicore era (Jérémie Laval)
Coffee Break
14:30 - 15:30	Building The Virtual Babel: Mono In Second Life (Jim Purbrick)
15:30 - 16:00	Moonlight and you (Andreia Gaita)
16:00 - 16:30	OSCTool - learning C# and Mono by doing (Jo Shields)
16:30 - 16:45	Smuxi - IRC in a modern environment (Mirco Bauer)
16:45 - 17:00	Closing (Ruben Vermeersch, Stéphane Delcroix)

Full abstracts should appear on the FOSDEM site soon. I am very happy with the line-up we managed to come up with, with a lot of good technical talks. Hope to see everybody there, come soon as the capacity of the room is limited!

Are you a developer hacking on or using Mono? Coming to FOSDEM 2010? Be sure to submit your talk for the developer room and do it quickly: the deadline is nearing!

More info.

I am very pleased to announce that in 2010, for the first time ever, we will have a Mono developer room at FOSDEM. This room is organized by Stephane and me, with the kind input of Andreia and many others.

As of now, you can submit your talk proposals! We want to make this a fun room and we want to accomodate all kinds of talks. For that reason, one thing we're experimenting with is having dynamic timeslots. Only want 15 minutes? That's okay! Need an hour? We'll see if we can squeeze it in! The most important factor is that it's interesting and fun.

So send in your proposals, be it large earth-shaking projects, or little hackery experiments that make you giggle with hacker joy, we want to hear it. We have the complete Sunday to schedule. Still have questions? Email me: ruben @ savanne be.

The submission form is here, go fill it in now! (Send in your proposals before December 20)

We hope to see you all in Brussels in 2010!

I recently read the book Zend Framework 1.8 Web Application Development by Keith Pope. Having done quite a lot of PHP work and having used Zend Framework, this book caught my attention. In general, I don't really like IT books that cover a technology, most of them tend to be a refactored version of the reference manual.

Not this book. It's actually nice and complementary to the reference manual provided by Zend: whereas the reference manual describes each component in great detail, this book takes a more high-level view of things, showing how the pieces of the puzzle fit together.

It does this by building a full application, from the ground up, step-by-step. Where needed, a detour past theory is not shied. So it's not all application: the author takes quite a lot of time to cover e.g. the ideas behind MVC.

I also liked the broad range of topics covered, including testing, something which is quite often overlooked for web applications.

In all, this is a good read. No earth-shattering must-have literature, but certainly useful. If you plan on building a lot of Zend Framework applications, this book will certainly help a lot. The only minor point is the somewhat confusing Model description. Other than that: good one.

Disclaimer: Packt Publishing was so kind to send me a review copy of this book. This would not stop me from declaring that it's utter shit, it just so happens to be that I liked the book. You can buy my time, not my opinion.

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).

Yesterday a friend of mine pointed out that I have six computers which I all use regularly: a laptop for work, a laptop at home (for photography and hacking), a netbook, a backup/file server at home, a webserver and a smartphone.

Is this too much, do I need to go into rehab? Or is the average much higher? How much computers does the average IT-er have (and why do you have them)?

Discuss in the comments!

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.