Omnipresent computers – Part 2

Once more into the world of the future and once more into the world of terrifying but strangely desirable paths.

Imagine this: You’ve got this great idea for a drawing, you sit at your desk, call up some pictures to remind yourself the exact details of what hyper modern weapon you are equipping your space fish with (*cough* Avengers *cough*). Then you draw, and draw and then decide that the laser equipped terrifying space bass is really rather good and the Internet will love it. So you post.

Now at the moment, I have a desk, with screens and I could draw, if I had any talent at it, and so, once I had finished, I’d turn around, walk over to the scanner, hit the button, select where I wanted to save/send/print it (NB: future OC on that whole fuss), then I’d email to myself (different computer and all) and then finally share it. And I’m okay with that, becuase I hardly ever do share things, and I can’t draw…I digress.

Cameras are getting pretty decent these days, tiny image sensors capable of taking sort of decent images at resolutions which allow pretty good crops to be taken, and these sensors will only get better. At some point processing it all might actually catch up, but that is a little far off. Imagine if, while drawing, your computer videoed all of your pen strokes, snap shotted each time you moved your hand away, and when you decided to post, you didn’t even need to scan, it knew it was “the drawing” or “it” and it went ahead and posted it on your angsty drawings blog. Really really high resolution, beautifully lit and with a complete “revision history” of most of the drawing progress. You notice a problem with some of the shading? You could edit an area without actually having to rub out…weird stuff.

I love this idea, where your area has cameras trained on it, in sufficient different angles to capture 3D hand movement, digitize objects and documents, without any trouble or special hardware. I want to specify a rough dimension into an actual measurement? I hold my hands to the size and say measure, and its done. I want to have a skype call with decent quality video, it can do that too!

I can think of hundreds of uses for this always on image processing, as we are already seeing with motion controlled televisions or puppet shows. But there are some major problems: Mainly, the processing power needed to take a 14Megapixel sensor at 50fps, make a depth map (or even full model), extract where is person, recognize the gesture and react in real time (while running that favorite program) is something that I doubt any single computer could pull off. Using back of envelope calculations, that is 6.3 Gigabytes a second of data pouring in (3 cameras, 24bit colour, 14MPx, 50fps). Thats raw data, let alone the hundreds of filters one has to run on it. Not a chance.

Always on high definition cameras also bring big personal privacy problems, especially with the inevitable level of networking any system one used this on would have and there are a few ideas I came up with to help quell those feelings of insecurity: Two modes, in hardware on the cameras: high resolution, slow frame rate (also addresses the bandwidth problem) and a low resolution, fast frame rate, indicated by a light or some infallible indicator on the actual camera.

Another feature would have to be firewalling, even inside individual applications: the camera and any network connected components would have to be separated by a strong data wall, limiting the bandwidth between the two so no video stream could be passed, although this wouldn’t stop everything, it would help stop live sevalence. Any video chat services or online games could have express user permission to break this, but it would be ideal that this was clearly stated somewhere when in use. Sounds messy to implement though, but in a model of crazily powerful computers, such a problem would largely dissolve.

Getting computers to see usefully is something I’d surely like to see, but we have a long way to go in processing (mainly) before such a useful bit of software/hardware comes forward.

See you in the future.



I’ve mentioned The Player of Games previously but this time I bring a slightly different post: a call for input.

A year or so ago (the last time I read the book in fact) I started designing the concept of a new board game, inspired by the concept of more complex board games taken from the book. A sort of chess with luck, hidden pieces, guesswork… something I would like to play.

Jernau (named after the protagonist of the novel) is a game played on a 15 or 20 to a side grid (probably on the computer, due to the number of pieces needed) between 2 (possibly more) players. I am releasing my preliminary work on the rules and mode of play behind the games that, although are no where near comprehensive, give a general idea.

I’ve made a Google Code project for it, at:

The rules will be transferred into the Wiki on that page in time, as well as the source code and a compiled version.

If you want to be able to edit it, just email “jernau” (dot) “game” (at) “gmail” (dot) “com” (that should throw the spam bots…) And I’ll add your email to the list of admins.

What needs doing is:

  1.  Coming up with the algorithms judging the conflicts
  2. Software implementation
  3. Closing the semantics of movement

I have already started a kind of program in which one can test the concepts (more of a test bench at the moment) in processing, although it lacks a lot of framework, any networking or a proper digital representation of the board.

The scheme of representation is a topic of a bit of interest to me, how to store, send and even play the game. The hierarchy of the system is one that I feel requires some thought, especially in thought of keeping the software light on RAM. There are multiple approaches:

  1. Have a set of counters, each with a properties stored locally, and also a coordinate of where it is.
  2. Have a set of squares, with member counters.
  3. Have a set of squares with member groups which has member counters and some other properties.
  4. Have a board with a member set of squares… a la 3.

I like the idea of 4, as it then could have tools for transferring state changes of all of the parts, as well as allowing multiple boards to be stored in one program simply.

Applying rules would require knowledge of the interaction, requiring another transfer medium etc… The usual programming choice.

I haven’t much experience in this sort of organisation of infrastructure (the networking side also needs writing!) so any help would be great!

%d bloggers like this: