Posts Tagged ‘programming’

Who’s actually using RDFa?

Jess Norwood - February 21st, 2011

A year ago we were very excited about RDFa, and in particular about using it to mark up consultations in our Citizen Space software. By providing certain bits of metadata in a machine-readable format (for example the consultation’s title, start and end dates, target audience, author etc) the consultation record can be used by third-party systems, and potentially incorporated into applications that hadn’t even been envisaged when the data was originally published.

RDFa actually became a mandatory requirement for all central government consultations published after 1st January 2010, but in the past year we have seen very little use of this new wealth of freely available data. There were rumours that Directgov planned to use it to import consultations, but I can’t find any evidence of this on their site.

We were sad that we’d gone to all the trouble* to incorporate RDFa into our clients’ consultations, and nobody was making use of it, so we decided to do something with it ourselves. We’ve made an Aggregator that can collect together consultations from any website as long as it publishes its consultations in an RSS feed and includes the appropriate RDFa markup. It also publishes its own RSS feed so that the aggregated consultations can be fed into a further tier of applications.

We’d be really interested to hear of other apps that are making use of RSS and RDFa in relation to consultation data. Surely we’re not the only ones?

*actually it wasn’t much trouble at all thanks to the helpful guidelines from the COI.

Basic Eyetracking using Python – overview

Tim Wintle - January 18th, 2009

Mis-using this blog to write up a personal projects again, I thought I’d explain the basics behind a simple eye-tracker I hacked together a while back (this video from August 08 shows my first version):

0 Basic Eyetracking using Python   overview

I’ve had quite a few questions about how to implement this in Python, so I thought I would explain the general process:

Detecting the Face

The first stage is to take the image from the webcam and estimate where the face is. There are good tutorials on using the haar classifiers that come with open cv to detect faces, and I would recommend reading a few of those.

The important thing is that this stage has to be really fast and give a low false positive rate – so I tweaked the parameters so that the false positive rate was low, and it accurately detected a face position on average about one in ten frames. Since the face isn’t going to be moving much, I used the previous face positions if I had not detected a new one. I did not care too much about accuracy for this stage, though.

Detecting the Eye positions

This is (again) very important, but this step has to be done with a very high level of accuracy for the simple method I used. Since the eyes are expected to be in a certain position on the head, I ran the haar classifier for eyes over the top 2/3 of the “face” detected before, which massively reduces the processing time for this stage.

I also found that I regularly had several suggested regions where the eyes were (possibly because I used a low-quality classifier), so I enforced some hard-coded rules to try to reduce the number of regions to two, while ensuring that they were in fact eyes being detected.

For example, I checked that the two regions didn’t intersect, and that they were roughly the same size. I also checked the probability that they were in that position based on the previous recorded position etc.

Analysing the pupils

Once we have the eye positions, we only look at properties of the image around the eyes. (you can see an example image of an eye region being shown in the video – I analysed both, but I only displayed one)

I really did take a very basic technique here – rather than relying on having a light in front to reflect a white dot in the pupils (which is the standard trick), I simply analyse the normalised moments of the pixelvalues.

(I just realised that sentence doesn’t sound like “simply” should be included, so here’s a bit more background). Basically, when you’re looking a distribution (like the distribution of values along the x-axis of an image), the “first moment” of the distribution is the average position, the second moment is the variance, and the third moment is the skew.

The variance does not tell us anything about the direction of the pupils, so I used the first and third moments in the X and Y axis as inputs to decide where the eyes are looking.

Feeding this into a simple linear learning algorithm worked very well. I did try a few more complicated algorithms, but my quick tests did show that I got almost linear behavior between the moments measured and the (true) pupil position on-screen (probably due to the wonderful accuracy of small angle approximations).

Question: Open Source Eye Tracking

What astounded me was the simplicity of the project -  I think it took me about two evenings to do as much as I had done. Why then does all quality eye-tracking software cost an arm and a leg? Sure, there are algorithms and bits of code out there as part of thesis’, but they all have to be made from source and none of them really have a nice interface.

In my opinion, it would be a massive boost to the FOSS community if someone would focus on building such a system. Something that integrates screen capture, a key/mouse logger, and eyetracking. Unfortunately my code for this was really a quick hack – and I think it would be better to start from scratch than to re-factor the code (which is why I haven’t made it available yet).

Tuesday at Europython

Tim Wintle - July 8th, 2008

It’s been an interesting day today, as I headed through talks on topics ranging from large scale python applications and software ideology to methods of inserting TeX-formatted maths into web pages – but here are some of the most entertaining events.

Harald Armin Massa gave another great talk as an introduction to the 5 minute lightning talks – “Is Python ready for Enterprise” introduced the new module ncc1701.py (google code page):

(Sorry about the quality of the image)

python enterprise Tuesday at Europython

Part of this code:

>>>import ncc1701
>>>p = ncc1701.Phaser()
>>>p.fire()
Traceback (most recent call last)
  File "<input", line 1 , in <module>
  File "ncc1701.py", line 86, in file
    raise PhaserNotLockedOnTarget
>>>s =ncc1701.Shields()
...

Despite the initial flaws, in the end we all saw that Python is indeed suited for controlling Enterprise applications.

At the end of the day Hans Rosling gave a very interesting keynote on the world’s economy using some very interesting interactive visualisation software designed for “people who are always being told what to do – young children and world leaders”. Here was one interesting slide:

“Where is child mortality highest?”

child mortality Tuesday at Europython

Yup, child mortality is higher in professors than in students, and almost as high as in Chimpanzees.

Monday in Vilnius (Europython)

Tim Wintle - July 7th, 2008

I am blogging this from the sunny city of Vilnius, Lithuania – the setting for this year’s Europython – straight after Guido’s keynote talk on Python 3000 (via teleconference, and at the end of the day due to the 10 hour time difference).
06072008489 Monday in Vilnius (Europython)
I’ll definitely say that I have really enjoyed the first day of the conference – especially Harald Armin Massa’s “Discouraging the use of Python” – a tongue-in-cheek look at different ways that “crafty developers” try to sneak Python into software companies, and ways to counter-act them. Here was my favourite example:

Developer:

“With Python, you have to write a tenth amount of the code as with C”

Why this is to be avoided:

“Less code means less programmers, less man-hours spent on your project, and a lower expenditure, which means that as a manager you will end up with a parking space further away from the office – stop it at all costs.”

I also went to two very interesting talks on PyPy, an interpreter for Python (and more) that would take more time to describe than I have now (and more than most would be willing to read through). It was great to be able to ask the developers some questions, and according to their first talk, we should expect production ready PyPy in between 6 and 12 months.

I also enjoyed the talk on “Building an App in a week” – a talk tailored at hacking together a django web site in very fast iterations – with some great tips, mainly under the heading “avoid doing work at all costs”.

If there is one slight problem I would complain about, it is that the wireless network here doesn’t seem to have been prepared for this many developers to all turn up at once with our IRC, email and ssh connections all running constantly during the talks. I heard one person complain that it was taking him 45 seconds to load the Google homepage – but amazingly Guido’s talk seemed to come through fine.

Signing off for now,

Tim
07072008499edited Monday in Vilnius (Europython)