In a world gone mad, only a lunatic is truly insane.

I've been busy with a few things during the previous couple of weeks, mainly moving to a new flat in Trondheim. I've gotten in a few hours of work here and there though, and I'm currently back to working full time.

My main task at the moment is implementing a servlet that loads an image file from the 'complex obs' system, carves it into tiles and resizes it. My first version works very well with smaller images, but fails miserably on large ones because Tomcat runs out of memory. For example, one of the images I use for testing is an X-ray image, a 8192x9976 pixel grayscale jpeg. 8192*9976*8 bits = 78 MB of memory required to store the whole decoded image. Multiply with 3 for a 24-bit colour image.

This can be reduced significantly though, using built-in functionality in Java's Image I/O API. Setting the right Image Read Parameters allows me to only decode the portion of the image that I actually need, as well as applying subsampling to the image decoder. Seeing as each http request returns an image tile of only 256x256 pixels, there is huge room for improvement.

I enjoy listening to BBC World Service radio, and todays episode of 'Digital Planet' features a brief discussion of OpenMRS and the recent Durban conference. An mp3 of the show can be downloaded from the show's home page. (WMA/RealMedia stream, or mp3 download at the podcast link)

EDIT @ 5 August: BBC apparently only keeps podcasts from the previous week, so the show is now unavailable. I've uploaded a copy here.

In other news, my mentor Mike has spoken with Summer of Code organiser Leslie Hawthorn at the aforementioned conference, and she says we are good to go ahead with using Google Maps API. Hurrah!

Terms of (non)service

The previous week I ran into an unexpected problem: It turns out that the Google Maps API Terms of Service may prevent me from using the API in my summer of code project. This despite of the fact that I only use the map controls, and not the map data. The problematic clause is the following:

The API may be used only for services that are generally accessible to consumers without charge. Accordingly, You may not use the API for any service that requires a subscription or other restricted access, or for which a fee is charged.

An OpenMRS deployer must necessarily restrict access to the patient data.

Fortunately, I can see light at the end of the tunnel. (Though it might be from an oncoming train) I have been spending some time looking into alternatives in case I have to drop Google Maps completely. OpenLayers, for example, looks promising. It doesn't seem as polished as Google Maps, but it should work.

Because of all this I have put the image viewer itself on hold, and have instead focused on the back-end parts of the project. I've been looking at bmckown's complex obs system, and am now running the complex obs build of OpenMRS locally. I've written a simple module that tries to interact with the complex obs system, and I've almost completed a preliminary implementation of an image tile carver, (resizing images and carving them into 256x256 pixel squares upon request) implemented as a ComplexObsHandler.

First test

The current school semester is over, and I've finally started properly on my GSoC project. I've been exploring the Google Maps API, its possibilities and limitations. Yesterday I made a functioning mockup showing how an image viewer might work. Right now only zoom and pan works, but I'm currently reading up on Google Maps' markers and info windows that presumably may be used to implement image annotation.

Note: The mockup is hosted on my own webserver in my flat. I won't be posting any links to it here, because I have limited bandwidth.