The main goal of this session is to give our Google Summer of Code and Outreach Program for Women students a forum to show what they’ve been working on in the past few months. Your feedback and support will be very much appreciated by them.

Be there or miss out on the future!

If you would like to know what our future rockstars are doing, this is where you should be heading! The session takes place on the first day, Saturday August 6, between 5:15PM and 6:00PM in the Audimax room.

To students that are still in doubt: Having done two Summer of Codes as a student myself, I can only conclude that this is probably the nicest way to earn some bucks as a student. Fun and interesting. The deadline for idea submission is approaching fast, but there’s still plenty of time to write-up a proposal. Talk to a maintainer and please work on top of an existing project rather than building something new.

I myself won’t be able to take up the mentoring of a student as I’m too busy founding a company (but that’s the subject of a future post). Now go submit your ideas and prepare for an awesome summer!

Each student maintains a wiki page with information about their projects. You can find these on the GNOME wiki.

The main hall at GUADEC 2010

In the end the selection was made based on a number of factors , which include the quality of the proposal, the usefulness for GNOME, the potential stick-around-after-gsoc-factor and others.

Also, some of the titles and abstracts below might not fully represent the actual projects, as we’ve asked some students to adjust their projects. More info will come over the coming weeks (mostly from the students themselves). Stay tuned!

A more useful Now Playing source for Banshee
Student: Alex Launi, Mentor: Alexander Kojevnikov, Abstract

Anjuta Snippets Plug-in
Student: Dragos Dena, Mentor: Johannes Schmid, Abstract

BuilDj: A build definition format for GNOME
Student: Emel Elvin Yildiz, Mentor: Albeto Ruiz, Abstract

Clutter screensavers
Student: William Hua, Mentor: Thomas Wood, Abstract

DACP support in Rhythmbox
Student: Alexandre Rosenfeld, Mentor: W. Michael Petullo, Abstract

Ease : presentation authoring tool for the GNOME desktop
Student: Stephane Maniaci, Mentor: Nate Stedman, Abstract

Enhance the operation of GNOME Shell LookingGlass
Student: Christina Boumpouka, Mentor: colin walters, Abstract

Extending Jokosher to Include a Musical Score Editor
Student: David Williams, Mentor: Michael Sheldon, Abstract

Flesh-Out the Message Tray in Gnome Shell
Student: Matthew Novenstern, Mentor: Marina Zhurakhinskaya, Abstract

gedit multiviews
Student: Ignacio Casal, Mentor: Jesse van den Kieboom, Abstract

Getting Things GNOME! integration with online GTD services
Student: Paul Kishimoto, Mentor: Lionel Dricot, Abstract

Getting things GNOME! integration with online services
Student: Luca Invernizzi, Mentor: Lionel Dricot, Abstract

Getting Things GNOME! Web Service and API
Student: Karlo Jez, Mentor: Bertrand Rousseau, Abstract

GNOME Project Mallard online
Student: Sergio Infante Montero, Mentor: Shaun McCance, Abstract

GTK+ refactoring to make possible GTK+ 3
Student: javier jardon, Mentor: Carlos Garnacho, Abstract

Improving the desktop experience with the “Task” and “TaskMonitor” D-Bus API
Student: Salomon Sickert, Mentor: Danielle Madeley, Abstract

Make a Tracker based ORM
Student: Adrien Bustany, Mentor: Juerg Billeter, Abstract

Proposal for completing Jokosher Telepathy support for recording VoIP calls and extending it with Tubes support
Student: Peteris Krisjanis, Mentor: Michael Sheldon, Abstract

Rhythmbox: Improved Last.fm Plugin
Student: Jamie Nicol, Mentor: Jonathan Matthew, Abstract

Spicing up Cheese – Sexier Form and More Function
Student: Yuvaraj Pandian, Mentor: daniel siegel, Abstract

Totem Markers/Chapters Support
Student: Alexander Saprykin, Mentor: Bastien Nocera, Abstract

Zeitgeist: Libzeitgeist wrapper around DBus API
Student: Michal Hruby, Mentor: Seif Lotfy, Abstract

Into the wild!
Went for a hike through nature last weekend. The day started out quite foggy, but when it all cleared up, there was a bright sun in the sky. Am rapidly turning into a nature hippie, loving it.

Grab your shoes and head out, the world is too pretty to sit inside!

Panorama – Slightly larger size (original is 25450×2604)

Google Summer of Code 2010

Bram Luyten (mentor at DSpace) and Vincent Verhoeven (2 year as student) will do most of the talking, but as I happen to work there, I (2 times student and now GSoC admin for GNOME) will be present too and talk about doing a GSoC with GNOME. Obviously there will be plenty of time for questions as well.

If you want to be the next GNOME rockstar, this is your chance, come over and have a chat!

More info

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.

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.

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.

We want you to write code for F-Spot!

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!

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