GSOC 2011 - PyOssim

The awesome Ossim library has served me (and disaster situations in New Orleans and Haiti) in getting large amount of imagery processed accurately and without too much manual messing around.

OSSIM already sports a JNI wrapper tying the rich C++ library to the JVM (I loathe to say Java - it is such a verbose and bureaucratic language). Coming from C++, an Ossim wrapper should attach to a more dynamic language. Indeed the OMAR developers chose to write it mostly in Groovy+Grails.

Ship Tracks in OssimPlanet

This year the GSOC project is aiming to wrap some important bits of the vast library using SWIG for use in CPython. Writing a SWIG wrapper can be painful at the best of times as I found out during my Kinect SWIG work. In spite of the hurdles Vipul has made decent progress and made some of the previous work with JNI + SWIG compile in the Python context. Now he is starting fresh from a purely Python perspective, we will figure out which functions are important and should form the seed for a python wrapping project.

If it all becomes too hard to do with CPython, we might stick with the link to JVM and script Ossim with Jython.

GSOC 2011 - Ship Detection in Opticks

This is my second mentoring stint for the Google Summer of Code. I am advising on 3 separate projects in different capacities.

1. Ship + wake detection and parameter estimation using Radar images in Opticks
2. Wrapping the awesome OSSIM library in python
3. Displaying sub-surface features in a 3D globe - NASA WorldWind

This post is going to be the first in a series describing the goals of each of the projects and where we are so far in them. In my personal opinion given the complexity of the algorithms involved and the visual outputs the ship detection project has progressed the farthest. We are using a beautiful 3m TerraSAR-X image from DLR as the basis for our implementation.

The various algorithms we have thrown in include:

1) CFAR with k-distribution model of the clutter
2) Elliptical width, height and orientation estimation
3) Isodata clustering for ship points
4) Linear feature (wake) detection with radon transform
5) Conversion of ship to wake displacement to ship velocity using satellite trajectory and imaging mode

Vijay is in his 5th week now and has been making great progress, picking up algorithms from various examples and adapting them to Opticks.

WebGL globes round up - in the face of security

WebGL bring the the OpenGL Embedded Systems (ES) profile to the virtual machine that the web browser is rapidly becoming. Microsoft has hit the headlines in the last few days with their proclamations about the security holes created by WebGL and their reluctance to fix them. They might be trying to plug any holes in their answer to high performance graphics in the browser - Silverlight, may be they can reuse the silverlight code to plug the GPU access security holes.

I wasn't going to rant about IE's double-standards but summarise a few WebGL globes I have come across, so here goes:

1. A very early port of NASA WorldWind API to WebGL - Lanyard.
2. The Swiss OpenWebGlobe.
3. Google's data visualisation globe.
4. WebGL Earth from Klokan.
5. Godzi globe from Pelican.

Let us just hope that Microsoft pulls its head out of the sand and works on securing GPU access via no-matter which technology. Meanwhile I will rush off to build a video buffer capture with handhacked versions of JOGL (if anyone ever accepts my signature). What Javascript really needs is establishment of trust and signed execution.

Why choose a language when you can be a Polyglot

Flamewars between language fanatics often gets in the way of "getting things done". I pick up languages fairly quickly and appreciate their benefits and short comings. After a fair bit of survey it seems like no language will instantly have familiarity and features concurrently, not unless it is also attached to a time machine and a brain washer. So why not call a truce and support them all (or most) - on a half-decent industry standard VM (no matter how much you dislike oracle).

Dynamic languages are a lot of fun to develop with, you can create prototypes quickly and have a tight feedback loop of your application taking shape. Sometimes the heuristics built into an application are not the right ones (u,v in vector interpretation are swapped, some format loader does not quite do what you expect). The expert/inquisitive user should be able to fix these vagaries at runtime and make the application behave. Any self-respecting application should include such dynamic scriptablity (Qgis does via CPython/SIP, Geoscript is nascent).

The REPL based languages that we are aiming to support via JSR 223 include:

1. Jython - with standard JSR 223.
2. JavaScript - with Mozilla Rhino, browser JNI bindings can be lobbed in as needed.
3. JRuby - again we get JSR 223 for free.
4. Groovy - the standard interface is not enough for delving in the depths of Groovy, but it does the job.
5. R - I hacked together a placeholder based on the JNI based rJava project, there are standard implementations but they don't play along nicely with our integration framework yet.
6. Perl - Another day another hack for the Inline::Java JNI based calls to the Perl interpreter.
7. Matlab - I had a chance to delve deep into the innards of Matlab and discovered a native and jvm based beast. There are several hacks to talk to Matlab from Java including running your Java code on the same VM Matlab is running (it even includes the felix runtime and scr). For now I am using matlabcontrol with some JSR-223 linkage.

The current integration tests with patchwork hooks to convert SUN Spi to OSGi Services looks something like below.


INFO: Testing Script Engine: jython
Jun 19, 2011 12:53:36 PM org.trikend.script.test.ScriptTest testConsole
INFO: Testing Script Engine: javascript
Jun 19, 2011 12:53:36 PM org.trikend.script.test.ScriptTest testConsole
INFO: Testing Script Engine: jruby
Jun 19, 2011 12:53:37 PM org.trikend.script.test.ScriptTest testConsole
INFO: Testing Script Engine: groovy
Jun 19, 2011 12:53:37 PM org.trikend.script.test.ScriptTest testConsole
INFO: Testing Script Engine: R
Jun 19, 2011 12:53:38 PM org.trikend.script.test.ScriptTest testConsole
INFO: Testing Script Engine: perl
Jun 19, 2011 12:53:38 PM org.trikend.script.test.ScriptTest testConsole
INFO: Testing Script Engine: matlab

A JSR-223 bridge may not do it justice and we may have to write our entire high-reliability portion of the system in Erjang, but that will not stop me from adding an Eshell to the integration test next. The java scripting project feels dead for a year, possibly due to Oracle turmoil, if there is any news on this front and Github forks alive and kicking I would really like to know. Other syntaxes and languages with fun features to evaluate would be: Scala + Akka, Clojure and Gosu.

CMAR Python Be-In - converting Matlab/R/VB folks

Last couple of days we have been running a coffee and cake fueled Be-In/Hackfest to learn Python at CSIRO CMAR. In the oceanography community a lot of coding goes on, the large models are written in Fortran and C. The throw-away prototyping is done in Matlab by physical oceanographers and in R by biologists.

R is open source and contribution/hacking friendly, but Matlab is another story altogether. Matlab however has a rich set of documentation and toolboxes which you will probably never read or use, just like you will never redline the tacho in your car - but one gets the comfortable feeling of knowing it is there in case something goes wrong. I was aiming for positive reviews like these.

In my true UI's are the best fashion I did a short IDE round up which you can find here. I learnt a lot about requirements of true large data processing, caveats in python and some backend magic for matplotlib. Also got a chance to look at the scripting API for Java and the pains with the SPI service registries and the death of com.sun.

Since we are on the Python topic I mucked around with running Matlab style functions from Python via Scilab (Java Matlab look alike). Data gets passed around Python Interpreter to Java VM for the sake of syntactic familiarity. After a couple of build hick-ups:

• locating includes due to scilab layout on Ubuntu
• launching with jvm and libjava on LD_LIBRARY_PATH
• proper setting of SCI env variable to /usr/share/scilab 

I had a matlab like API in Python. So I tried comparing computation of matrix inverses:





In [81]: from numpy.linalg import pinv,inv
In [82]: from scilab import scilab as sci
In [83]: x = sci.rand(100,100)
In [84]: from pylab import imshow,show
In [85]: a = inv(x)
In [86]: b = pinv(x)
In [87]: c = sci.inv(x)
In [88]: figure(1)
In [89]: imshow(a-b)
In [90]: figure(2)
In [91]: imshow(a-c)
In [92]: figure(3)
In [93]: imshow(b-c)


The inverse calculation is a fairly complex series of floating point operations and errors accumulate between the different techniques in the order of 4x10^-15 for the random array. No wonder results from matlab don't match up with those from Scilab and Numpy. Next I will grab a copy of Matlab and use mlabwrap to compare with the "real matlab" computed inverses.

PS: mlabwrap results are in, how do I tell which inverse is more "correct" suggestions welcome.
In [42]: mean(abs(sci.inv(x)-mlab.inv(x)))
Out[42]: 1.0797192783948417e-14
In [43]: mean(abs(sci.inv(x)-inv(x)))
Out[43]: 1.1512191793925341e-15
In [44]: mean(abs(inv(x)-mlab.inv(x)))
Out[44]: 1.0661985412661976e-14