Tag: project nightjar

Project Nightjar: Camouflage data visualisation and possible internet robot predators

We’ve had tens of thousands of people spotting nightjars and donating a bit of their time to sensory ecology research. The results of this (of course it’s still on-going, along with the new nest spotting game) is a 20Mb database with hundreds of thousands of clicks recorded. One of the things we were interested in was seeing what people were mistaking for the birds – so I had a go at visualising all the clicks over the images (these are all parts of the cropped image – as it really doesn’t compress well):

clicks-ReflectanceCF017Vrgb0.54-crop

clicks-ReflectanceCF022Vrgb0.52-crop

Then, looking through the results – I saw a strange artefact:

clicks-ReflectanceCP018VRgb0.55-crop

Uncompressed high res version

My first thought was that someone had tried cheating with a script, but I can hardly imagine that anyone would go to the bother and it’s only in one image. Perhaps some form of bot or scraping software agent – I thought that browser click automation was done by directly interpreting the web page? Perhaps it’s a fall back for HTML5 canvas elements?

It turns out it’s a single player (playing as a monkey, age 16 to 35 who had played before) – so easy enough to filter away, but in doing that I noticed the click order was not as regular as it looked, and it goes a bit wobbly in the middle:

Someone with very precise mouse skills then? 🙂

More procedurally rendered eggs in HTML5 canvas

The first Project Nightjar game was a big success, with 6 thousand players in the first few days – so we’ll have lots of visual perception data to get through! Today I’ve been doing a bit more work on the egg generator for the next citizen science camouflage game:

egglab3

I’ve made 24 new, more naturalistic base images than the abstract ones I was testing with before, and implemented the start of the genetic programming system – each block of 4×4 eggs here are children of a single randomly created parent, each child is created with a 1% mutation rate. The programs trees themselves are 6 levels deep, so a maximum of 64 binary composite operations.

All the genetic programming effort will happen in HTML5, thus neatly scaling the processing with the number of players, which is going to be important if this game proves as popular as the last – all the server has to do then is keep a record of the genotypes (the program trees) and their corresponding fitness.

One catch with this approach is the implementation of globalCompositeOperation in HTML5, the core of the image synthesis technique I’m using, is far from perfect across all browsers. Having the same genotype look different to different people would be a disaster, so I’m having to restrict the operations to the ones consistently supported – “source-over”,”source-atop”,”destination-over”,”destination-out”,”lighter” and “xor”.

Project Nightjar and responsive web design

Responsive web design is about how to deal with the multitude of different shaped screens that people are now using. Although it has some interesting technological aspects, it’s the philosophy that I find appealing – the idea of designing for the smallest and most limited form first, and then looking at how it can be progressively changed as the capabilities improve, in a continuous way rather than targeting specific devices. The idea is that this tends to be more successful than the other way around – i.e. thinking about the best case first, and taking stuff away as capabilities reduce.

For the design for Project Nightjar, we needed something colourful and accessible, and something we can build as we add games and other experiments later on. I decided to use compass, starting with fffunction’s tool sassaparilla for building the front end and django for the framework. This has meant that I’ve been able to quickly put together a site that the researchers can edit themselves, and that works on all devices.

Here are some quick screenshots, as the site isn’t public yet:

2013.07.10-15.03.28 2013.07.10-15.03.43

site1

One of the things that caught me out was how to stop mobile browsers trying to display the site as a normal web page, it turns out they report the screen width differently unless you specifically tell them not to with: 

<head>
    <meta name="viewport" content="width=device-width">
</head>