Thursday, 31 January 2013

Small Polished Stones

  • TL;DR Download this spreadsheet and look up your pledge date in the table. If you are really keen you can update the values in the sheet called "Production Data !UPDATE ME!" from this website to get a better estimate.

Loads of people are very excited about backing the Pebble smartwatch at Kickstarter, because if they gave a certain amount of money they would be given a Pebble once production began. The small polished stones will ship out in roughly the order that people backed the Kickstarter project. This makes it easy to guestimate when your Pebble will be made; all you need to know is the date you backed the Pebble project at Kickstarter (try searching your emails for "Backer Pebble")...

So how do you do it?

Pebble are giving updates on how production is going in near real time:
On the 30th Jan 2013 about 1500 Pebbles were made, taking the total to 8000 produced so far.

It is also easy to look up how many backers there were on each day the Kickstarter ran for:
For example by the 25th April 2012 40376 people had backed the project, most of these are in the queue to be sent a Pebble as a reward for supporting the project.

If you backed on the 25th April then it will take about "people in the queue in front of you (minus the pebbles already made) divided by production per day" days to get to your place in the queue. i.e. (40376-8000)/1070=30 days (I reduced the production rate to account for no production on weekends).

To make this a bit easier to calculate I made this spreadsheet. Just download it and look up the estimated production date based on your pledge date in the table. At the moment this is what it looks like as a graph:

The red cross is production as of today... There is still a long way to go!

Pebble are hoping to ramp up production to 2500 Pebbles a day. That will make a huge difference to estimated production dates, roughly halving the wait. To update the spreadsheets estimate fill in updated values from in the "Production Data !UPDATE ME!" sheet. All the estimated production dates will be recalculated automatically.

This is just an estimate! And it is a pretty bad estimate based on very little data. Don't blame me if it's wrong.

Wednesday, 30 January 2013

Decoding The Encoding

Decoding The Encoding is my new infographic/research comic feature in the Oxford University Biochemical Society (OUBS) magazine Phenotype. This term's feature is all about the ENCODE project, a massive international research project to move beyond just knowing the sequence of the human genome and moving towards understanding how that translates into its function. Check out the full issue here.

Software used:
Python: General data parsing and reformatting.
ImageJ: Creating the chromosome map plots.
Inkscape: Page layout and design.

Thursday, 17 January 2013

Colour Monitor

Mood of an image is hard to measure... but with hue, saturation and luminance ("spectral shade", "colourfulness" and "brightness") you can get a good idea. I wrote a website that can analyse the colours present in any image you give it. You can try it out here.

So how about some simple examples? Lets try these images:

Blue, a wet car.

Green, a conifer frond.

Red, champagne bubbles.

These simple examples give a clear impression about how the plots work: in the middle is a circular histogram of the colours (spectral shades) in the image, and gives an idea of how much of each colour there is. Up the left is a histogram of image brightness (lightness of colour), and up the right is a histogram of colour saturation (vibrancy).

Together these three measures give an impression of the mood of an image: its key colours, how vibrant they are and how bright they are. The main colours of this image are easy to pick out:

While my site lets you explore the colours that make an image appear vibrant and interesting it also reveals one of the tragedies of modern cinema; the teal/orange colour grading madness.

Screenshots from Transformers 2, Tron: Legacy, Hot Tub Time Machine, Iron Man and Wolfman.

So many blockbusters use orange and teal colour grading that a lot of modern films basically only have two colours: teal or orange. Bring back our other colours!

Software used:
Paint.NET: screenshot management.

Thursday, 10 January 2013

Time to Colour

It is hard to convey time in still images...

... but if colour isn't too important you can make the image black and white, then use colour to convey time.

This method works well where the background doesn't change; the splash of colour resulting from movement on the grey background draws the eye in.

It's easy to create photos like this. The hard bit is actually capturing the picture because you need to make sure the images align well, using a tripod is a good idea! Once you have the pictures aligned neatly then make each one greyscale, then colourise each one. They need to be coloured equally spaced shades of the spectrum in time order from red through the spectrum and back to red. For three images pure red, green and blue work perfectly.

The original pictures...

... and the recoloured pictures.

Using additive blending flatten the stack of images. Parts of the image where nothing moved should add to make shades of grey, but parts where things moved will be colourful.

The effect of movement is really clear if you look at cropped parts of the image where either nothing moves:

... or where there is a lot of movement:

Using a program where you can write scripts to automate processing steps it is very quick to make pictures like this. In ImageJ this macro takes an image stack and generates the recoloured and flattened images:

run("RGB Color");
for (i=0; i<d; i++) {
run("Duplicate...", "title=tmp");

run("HSB Stack");
run("Select All");
run("RGB Color");

run("Select All");
run("Z Project...", "start=1 stop="+nSlices()+" projection=[Sum Slices]");

Really quite simple considering how impressive the results are.

Software used:
ImageJ: Image processing.

Monday, 7 January 2013

OpenTTD 32bpp Part 4 - The Finished Product

By using 3D graphics and automation I was able to make a complete complete, high resolution, graphics replacement for OpenTTD almost completely on my own...

Making this graphics set was still a hell of a job though:

The total time I spent in Blender to make the graphics was 135 hours to make 391 blender files.
To render all these Blender files into sprites took 14.16 processor hours to produce 69931 images.
The final downloadable graphics files are 273 Mb and have been downloaded 24123 times.
The total size of all 146280 source files is 2349 Mb.

You can find out more about OpenTTD at and more about this high resolution base graphics set (called zBase) here and here.

Software used:
Blender: 3D modelling and rendering.
ImageJ: Sprite post-processing and managing.
Python: Computer usage tracking.
OpenTTD: The game!

OpenTTD 32bpp Part 3 - Automation

3D software makes it quick and easy to make high quality textured and shaded sprites, but it is not just limited to still images; 3D software is normally designed for animation. Using the animation tools in Blender I could massively simplify producing sprites for OpenTTD.

The graphics for different trucks are a great example.

There are 3 different generations of truck graphics (old, current and futuristic), 16 different cargo types and loaded and unloaded graphics; that's 96 different combinations! Designing the graphics in 3D allows the truck to be broken into chunks; the truck body, the trailer and the cargo.

A screenshot of the 3D source for the truck graphics.

With this setup making the various combinations of truck body and cargo is simple; different animation frames just have different trucks and cargoes positioned in front of the camera. It does need a bit of geometry to get all the angles perfect though:
OpenTTD's sprites have the front left and front right sides at 26.56805 degrees from horizontal.

In 3D it is simpler, the camera is at an elevation of 30 degrees.

Each truck has 8 sprites for the 8 different directions it can drive in. Creating these 8 different images using the animation tools in 3D software is also easy, just rotate the truck 360 degrees in front of the camera over 8 frames.

Finally a few extra images are needed to complete the set of sprites required. One of these is the mask sprite to show which bits of the truck should be coloured using the company colour:

Other ones are the different sprite sizes for different zoom levels (256px, 128px and 64px).

Handily these types of outputs are also useful for animators. This tangle of image processing nodes in blender automatically generates and saves these different images:

This level of automation generates all the sprites OpenTTD needs with the minimum of effort. With a little bit of coding these sprites are now recognised by OpenTTD and can be used.

Continued here: OpenTTD 32bpp Part 4 - The Finished Product

Software used:
Blender: 3D modelling and rendering.
OpenTTD: The game!

OpenTTD 32bpp Part 2 - Moving to 3D

The original OpenTTD graphics were 8-bit. This means that all the images were made up only of colours taken from a palette of 256 different colours. This image:
Is only made up from colours from this palette:

 For example you can take all the pixels from the building which are the grey shade indicated in the palette:

An 8-bit image format was used because it was much faster for older computers to display. While the images are simpler it actually makes the graphics harder to draw for a person; every single pixel has to be picked carefully. It isn't possible to use normal photoshop techniques like altering brightness or contrast or reshading the graphics which makes things difficult. Imagine having carefully drawn a brick wall. To use it on the shadowed side of the building you are forced to completely redraw it.

In contrast 32bpp images are easy to make, especially using 3D modeling and rendering. The fact that OpenTTD can now use 32bpp graphics is therefore a big advantage! Once a building is designed in 3D (modelled) the rendering process (converting it into an image) calculates all lighting, shadows, shading etc. This makes it very quick to generate a realistic looking building because the computer does a lot of the work for you.
The building as modelled in Blender, the lamps for lighting are the dotted sun-shaped objects on the right.

The rendered image with accurate shadows and shading.

In the same way that 3D modelling and rendering make lighting and shading simple they also make texturing simple.

In the old 8-bit graphics textures like brick walls had to be hand-drawn, brick by brick. With some smart texture design and 3D rendering even hard-to-draw materials can be rendered quickly and accurately. Like with lighting and shading this is far quicker than drawing the texture by hand.
Brick texture on some simple objects

Brick texture on a really complicated object!

With lighting, shading, and texturing simplified by 3D modelling and rendering this actually makes the new, high resolution graphics easier and quicker to make than the old ones. The modelling is still a bit tedious though...

Continued here: OpenTTD 32bpp Part 3 - Automation

Software used:
Blender: 3D modelling and rendering.
OpenTTD: The game!

OpenTTD 32bpp Part 1 - Making a Massive Graphics Update

If you didn't know OpenTTD is an open source remake of the classic "Transport Tycoon Deluxe" by Chris Sawer, the maker of Rollercoaster Tycoon. It still has a huge cult following! Unfortunately the original Transport Tycoon graphics, which can be used in OpenTTD, look slightly dated (1994/5)...

 The original graphics

Originally OpenTTD relied on the graphics from the original game. In an effort to make the game fully free to play the graphics were redrawn from scratch, a massive project that took nearly 3 years to finish. Unfortunately these were subject to the same technical limitations as the original Transport Tycoon graphics:
 The free graphics replacement

The biggest problem with these graphics is their size. The game was originally designed to be played on a screen only 640x480 pixels in size. Modern screens (like an HD display) are nearly 3 times wider/taller with 9 times the area. In an effort to make the game more playable extra zoom levels were added: now the view can be zoomed in 4x further, but the result is not pretty:
 I can see pixels!

The solution? Redraw all the graphics. Again. The result is totally worth it though:
One retina display-safe set of graphics.

OpenTTD uses a (now quite outdated) method for displaying game graphics in which every in-game object is a single image called a sprite, like this:
One construction stage of one building.

In some ways this makes a complete, high resolution, graphics replacement is simple; all you have to do is draw the big brother of each sprite:
The same sprite, 4 times larger and with better colour depth and full transparency.

While this this sounds simple it is still a mammoth task. There are currently 11949 sprites (11949 separate images) required for OpenTTD. These cover all the objects, buildings, vehicles, industries, etc. to cover all the four different world environments you can play in... Some of these don't need to be replaced (like the sprites used for the fonts) but it is still a huge number of images.

So could I possibly go about doing this? In short, automation and 3D rendering.

Continued here: OpenTTD 32bpp Part 2 - Moving to 3D

Software featured:
OpenTTD: The game!