In preparation for the talk, be sure to check out my GeoClue slides from FISL and the GeoClue project page. iPhone, Symbian and Google are all pushing for more geographically aware applications and web, and free software will need tools like GeoClue to keep up.

Another interesting thing in the conference will be that the location of next year's GUADEC and aKademy will be announced. I'm keeping my thumbs up for Tampere, Finland. You should too!

But whatever happens with the 2009 conferences, I will be happy to be in Istanbul. If you're there, contact me and let us have a beer in the shady corners of Beyoğlu...

1 0

I wrote in a previous post about my first experiment with applying a modern technique, namely Hidden Markov Models, for handwritten Chinese character recognition. I’m quite motivated in making this more than just a single isolated experiment so I decided to give a name to the project. I named it Project Tegaki. This is going to be the codename for the effort starting from now. Tegaki means Handwriting in Japanese.

Project statement

The aim of Project Tegaki is to push forward the creation of the next-generation open-source handwritten Chinese character recognition (HCCR) software.

Currently, the only open-source package for HCCR is Tomoe. This is a project that I have been contributing to and that I used for my Google Summer of Code project, “Japanese/Chinese handwriting recognition on maemo”. Maemo is the open-source platform used by Nokia PDAs. I have decided to start Project Tegaki as an external effort because I considered that Tomoe would not be a good environment to welcome the effort. However, if the Tomoe community is ready to help me in this effort, I will be happy to merge Project Tegaki back into Tomoe once Project Tegaki becomes ready for prime-time.

Handwritten Chinese character recognition in a PDA…

Here are some goals for the project:

- Free and open-source. The goal is to produce the next-generation free and open-source HCCR software.

- Modern. The software should use modern approaches to Handwriting recognition and be in tight connection with research.

- Embedded. The project must be designed to work with devices with restricted resources such as cell phones or PDAs.

- Online, as opposed to offline. In online recognition, characters are drawn using a device, typically a mouse, a tablet or a PDA stylus. In this setting, characters can be represented as sequences of points. In offline recognition, characters are scanned a posteriori. In this setting, characters are represented as images (width * height pixels).

- Isolated Chinese character recognition. Here Chinese character doesn’t restrict to Chinese language, since Japanese kanji are also Chinese characters! Even though the package should theoretically be generalizable to any kind of character, Chinese characters have some specific challenges and some approaches that give good results for Chinese characters may not give good results with other kinds of characters, due to the unique properties of Chinese characters. “Isolated character recognition” means that user will have to draw one character at a time in a separate box, as opposed to continuous handwriting recognition. This makes things much easier and in the case of Chinese characters, this is a reasonable limitation.

- Stroke order dependent and independent. Both situations have useful applications so Project Tegaki should ideally support both.

Python?

Usually I’m more of a Ruby fan but the project was started in Python due to dependencies on third-party libraries that only exist in Python. Even though I’m slowly getting away from those dependencies, I don’t want to re-implement everything just for the sake of using Ruby. So I keep up with Python.

As it was emphasized, this project is highly experimental. Moreover, a collaborative website will be created (see below) and it will reuse number of existing components. It thus makes sense to use a high-level language to focus on the experiments and to create the website.

Subprojects

Project Tegaki is now split into several subprojects.

libtegaki

This Python library contains functionality that will be useful to other subprojects. This includes array manipulation, character input/output, viterbi decoder…

libtegaki-gtk

This Python library contains user interface elements that will be useful to other subprojects. So far it only includes a Canvas, which can be used to draw characters. It is replacement for TomoeCanvas with some additional benefits:

- Truly reusable. TomoeCanvas assumes that a recognizer is connected to the canvas. However, there are situations when a recognizer is not needed.

- Resizable. TomoeCanvas cannot be resized at will.

- Animation. A stroke animation of a character can be displayed.

- Background character. A background character can be set as a model and animations will be displayed to help draw the same character stroke by stroke.

- Features other than (x,y) coordinates are supported such as pen pressure and pen inclination when available, stroke duration, point timestamp.

libtegaki-gtk is written in pygtk and depends on libtegaki.

tegaki-db

The most successful handwriting recognition systems nowadays use a “learn by example” philosophy. For each character supported, several samples of the handwritten character must be provided to the system in order to learn from them. Because those samples are used to train the system, they are called “training samples”. The challenge for the final recognizer is to be able to recognize unseen handwritten instances of the same characters. This is the ability of the recognizer to “generalize” the acquired knowledge.

A “training corpus” is a set of training samples. A good corpus should contain dozens of handwritten samples for each character. The corpus should be representative enough of all handwriting styles. Collecting all the handwriting samples and designing a good corpus is a huge task for Chinese characters because there exist thousands of them!

Such handwritten Chinese character databases do exist but they have a fee and they are usually restricted to academic research. They are by no means suitable for free software. The goal of the tegaki-db subproject is to create a collaborative web platform to collect handwriting samples. Native speakers and learners alike will be able to log in and contribute their own handwriting. The collected data will be published in a free license so that it can benefit to academic research as well. The tegaki-db will use a client / server architecture.

tegaki-db-client

tegaki-db-client is a client for people to input their handwriting. It will be written in Python and use the canvas provided by libtegaki-gtk. The client will communicate with the server through web services. The client should be distributed for several platforms such as Linux, Windows and Maemo to increase the number of potential contributors. A detailed specification of tegaki-db and tegaki-db-client will be provided later in a separate post.

tegaki-models

tegaki-models is by no means an end-user package and will only be used by developers. It is the placeholder for experimentation. Thanks to this package, model ideas will be tested and evaluated.

I continued to work on new model ideas… However, because my current training corpus is so small, it’s kind of irrelevant to spend to much time on models. The top priority now is to create tegaki-db.

tegaki-decoder

tegaki-decoder is going to be a high-performance decoder (recognizer). It should be a fast implementation of the Viterbi decoder. It will be written in C and designed to work with embedded systems. This is going to be the end-product that people will use. Once sufficient data have been collected, good models have been generated and the tegaki decoder is ready, then Project Tegaki will be ready for real use! Currently, implementing tegaki-decoder is not the top priority.

Roadmap

- Launch tegaki-db and tegaki-db-client.
- Hope that the collaborative effort is successfull and collect lots of handwriting samples from many different people.
- Create new models, especially stroke-based models.
- Implement tegaki-decoder.

If I continue to be the only one interested in this project, at this rate it will take from several months to a couple of years to achieve everything. That’s why I hope I can attract a few contributors.

Download

The work completed so far is still very experimental and thus targets potential contributors. If you want to test it with your own handwriting anyway, please see my previous post.

To download the source code, you can use

$ git clone http://www.mblondel.org/code/hwr.git

or

$ git pull

from the repository folder if you already have the repository on your computer.

The code can be browsed online using gitweb. By clicking the “snapshot” links you can get a complete copy of the source code at a given revision.

See my memo on git if you don’t know it yet.

I published my work under GPL license.

3 0

This week one more person had the problem. All three people were German, which made me suspicious. We discovered that all three people were using bytecamp’s email servers. For instance, gnome-de.org email addresses are hosted at bytecamp (for free, I believe). Major clue.

openismus.com was hosted at bytecamp a couple of years ago, but I moved it away because I found their services limited and rather ad-hoc, though it seems to have improved since then. It turns out that they forgot to update their MX records, so they were just swallowing any email to openismus.com from their remaining customers. Some emails to bytecamp solved the problem, so bytecamp customers can now send email to us again.

I do hope that several German GNOME developers (with gnome-de.org email addresses, for instance) have been trying to email me about working for Openismus. If you didn’t get a reply before, please try again.

0 1

Wifi networking worked, as long as you were already associated with access point under Maemo before you run the launcher to start up Android:

It is kinda sluggish on this hardware, there are some keyboard quirks, and I’ve had a few different apps (including the apps launcher app) crash away for seemingly no reason. But it’s a fantastic first effort, amazing they got it working at all. Kudos to the whole team!

1 2

Just tried to rotate my screen to see an iphone web app and … whoa. I found the menu’s were in order over on the left side, but I had to “use the force” to figure out where to click to get things restored.

Technorati Tags: android, maemo, n810, rotation, bug, kernel

1 2

Just like colliding with the front of your garage when you intended to stop anyway is still a bad thing.

Reprinted from a bug

3 1

I wanted to do something different again, so I persuaded the people at Brandt to do a kind of Rolf Harris punk thing. It’s a little bit funky. I don’t think it will please everyone but it will be noticed. Each one is different.

There was a shortage of T-shirts in these colours, so we did a small batch of classic retro-style dark green T-shirts too, with white banding and stripes with white flock-print. They are quite nice but less challenging.

Like last time, I chose to do a small number of expensive T-shirts rather than lots of cheap ones. Scarcity adds value.

1 3

As generated by Wordle from the maemo.org intro

6 0

Technorati Tags: android, google, mid, N810, Nokia, maemo

2 2

The reason I made it was because as I browsed and contributed to GNOME’s code, I noticed that a lot of developers seem to either ignore reference counting or they use it incorrectly all over their code.

I even saw people removing their valid reference usage because they had a memory leak they wanted to solve. As if introducing a race condition is the right fix for a memory leak! Some people have rather strange ways of fixing bugs.

What people who don’t want to care about it should do, and I agree with them, is to use Vala instead.(Or D, or Python, or C#, or Java, before I get hordes of language fans in my comments again. Oh! Or C++ with smartpointers too! - oeps, I almost forgot about the poor céé plus plus guys -)

Anyway, I’m sure my guidelines are not correct according to some people, as there are probably a lot of opinions on reference counting. In general I do think that whenever you pass an instance to another context (another thread or a callback) that you simply must add a reference. If you do this consistently you’ll have far less problems with one context finalizing while another context is still using it.

It’s a wiki page, I’m subscribed. You can just change the content if you disagree. Being subscribed I’ll notice your changes and I’ll review them that way.

http://live.gnome.org/ReferenceCounting

It’s not the first such item that I wrote down. Here are a few others:

• How to use gdk in threads and timeouts
• How to implement Vala interfaces in C
• Switching to multiple threads, with a non-thread-safe resource
• How to use DBus’s binding tool with GLib
• Iterators in GLib, a proposal

After reviewing this document José Dapena promised me he’s going to make a page about reference count debugging in gdb, like adding watches on the ref_count field of instances. To make sure he keeps to his promise I decided to put a note about that here. <g>

4 0

1. source package uploaded to autobuilder incoming queue
2. autobuilder builds package and moves it into the incoming queue from Extras-Devel
3. queuemanager for Extras-Devel will put the package in the Extras-Devel repository
4. developer checks packages from Extras-Devel and if the package is OK:
5. promote the package to Extras using the Promoter.

• Diablo Promoter
• Chinook Promoter
  

12 0

Picture this:

1. You're Wile E Coyote.
2. You're twenty feet away from a ledge (off the edge of a cliff).
3. You look down.
4. You see you aren't standing on solid ground.

What do you do?

Answer: You Fall.

What else can you do?

Not much.

You can only not fall before you run off the edge of the cliff, not after.

Why is this interesting?

Sometimes, we have users who ask us why we can't just "fix" a crash by changing the crashing function.

In the example from the bug, the crashing function, js_GetScriptLineExtent, has bad data and can't really do anything useful with it, other than simply crashing.

What can you do?

Report the crash (you know, what goes up, must come down... somewhere).

If you're lucky, the path to the crash will be obvious, such as when Wile E Coyote takes a wrong turn.

If you're unlucky, then the report won't have enough information, but at least someone will know to be on the lookout for something which could cause your crash.

Reprinted from a bug

2 2

• On Thursday me and some other igalians are flying to Guadec-ES (Madrid) where we’ll meet the Spanish-speaking Gnome team. We have some talks there: I’ll talk about the Maemo platform, a topic which will be further extended by Mario. Victor will show his YouTube viewer and Claudio will talk about how to extend Eye of Gnome,
• From there we’ll go to Guadec at Istanbul (not Constantinople). There we’ll meet the rest of the Igalia crew. Some of us will deliver talks there as well: I’ll talk a bit about the Vagalume Last.fm client, Iago will talk about the Gnome Buildbot and Juanjo about Gtranslator.
• The next version of Vagalume is going to be released very soon. Among other things, this will be the first version with support for the Moblin platform (the support is already available in SVN). Here you can see a screenshot of Vagalume on Moblin (click to enlarge):
  
• Regarding Vagalume, I was interviewed some days ago in a program called Extrarradio in the Galician radio (Radio Galega). Those interested in hearing the interview can get it from here, but note that it’s in completely in Galician Portuguese and that I talk very fast :)
• Wanna see Vagalume in action ? Someone has posted a nice video here.
• Our beloved Modest has finally seen its first official release !

See you in Istanbul !!

3 0