HgSubversion with Ossim-opencv

I have come to really like the flexibility of making changes and saving them locally with Mercurial , before pushing them off to a repository online. It lets me work on a project independently while saving my work as well as staying upto date with core progress. Ossim-opencv is one of the projects I did some minor contributions to a while back. I wanted to get back into it, but following the incident with losing my last google account I no longer had commit access. So I checked out the SVN with HgSubversion and started making changes and commiting them locally. Finally the organizer switched to my new ID and I tried a push. Things fell apart at this point. I had committed things with my local username, and I usually use my googlecode authentication to push since these are separate things. In subversion however these need to be the same and I was stuck with my changes. Happily Mercurial lets me shelve, make patches, push to another mercurial repository (sandbox) and do a lot of fancy things. I decided to take the convert route and changed name of the committer to match my ID.

After that I pushed it back into SVN. While doing this I of course validated the results. Here is the plugin loaded into my latest compile of Imagelinker showing OpenCV based Laplacian filter.

"Lollypop Forest" in Meep

I finally made some semi-realistic, well only very grossly, forests in MEEP. With dielectric cylinders as tree trunks topped by dielectric spheres as canopy. Then I bunched a few of them together to make a forest of 5 trees. I could have made much more complex structures but my knowledge of MEEP primitives and how to generate more of them automatically in Scheme is lacking. The attempts at replicating results with python-meep haven't gone so well, so I have to stick with Scheme-MEEP for now. Anyway even with the simplistic forest the wave propagation quickly becomes rather complex and difficult to handle analytically without gross assumptions. Yay for numerical methods.


Other small discoveries this week include the pagesel package in Latex for sending each chapter off to review, of course after you have done the whole document and you know where the pages go and apparently very dated model selection procedures in R. Even though it is dated it gave me a model with decent regression statistics - now to send off that chapter heavy with regressions for review.

Processing Lidar with MPI - Liblas + MPICH2

I did some work in the last company for processing and reclassifying Lidar points using Liblas. The first Python implementation had lots of point-in-polygon queries and even with prepared geometries in GEOS took a few hours. We improved the execution of this by rasterizing the polygons, while polygons in theory have arbitrary precision and rasters are limited to the spacing they are gridded at, in this case the polygons were derived by classifying a rasterized version of the Lidar and the raster mask should have the same degree of precision.

The mask is overly generous in classes at times, considering each class as a local surface. A piecewise interpolation model can often be used to identify disparate points in context and perform class switching. In unordered Lidar data this may lead to many passes through the data generating neighbourhood class relationships if an index has not been built e.g. Octree.

I decided to adopt the Google philosophy of scale solves everything - and implemented the Lidar processing using MPI (Specifically MPICH2). The solution is implemented with task queues.

1. Read all data on all nodes except last
2. Node 0 makes a pass through all data sending each point in round robin to intermediate nodes
3. Intermediate nodes receive a point and make another pass through all data identifying nearby points and using them in an IDW2 estimate
4. Intermediate nodes message with IDW2 estimate to last node in the set (in charge of serializing) which makes various comparisons against classification masks (e.g. SRTM Water Boundary mask) and geo-statistical surface consistency before reclassifying and serializing to an output LAS file.

The task is essentially O(n^2) but with sufficient nodes we can bring it down to O(n*n/M+M*overheads) where M is the number of nodes. If the dataset is large enough and M is suitably chosen we gain significant speed increases. I got so carried away with Lidar + MPI ( and since I don't want to mix it with my PhD stuff) I started a small code dump on Google Code. Use CMake and see if you can build it. Lots of sample Lidar here.