Bringing physical unit conversion to the (Android) masses!

Yes, it could be done! As speculated in a recent blog post, the csunits class library that provides units of measurement functionality to C# can be built and used without modification on the Android platform!

By using Mono for Android developed by Xamarin, I have been able to build the entire csunits class library, and as a proof-of-concept that the library is indeed usable on the Android platform I have created a tiny unit converter application (similar to the Silverlight and Windows Phone applications I have developed earlier).

Here is what the unit converter application looks like in an Android emulator:

So far I have only tested the functionality in an Android emulator. Deployment on a real phone or tablet device is not for free.

I did experience several caveats when developing. The most notable problem was that the mandatory signing of the application package did not work correctly when Java 7 was installed on the computer (mentioned in a byline here, for example). It took some time before I could figure out that this was the reason my Mono for Android applications were never deployed on the emulator...

Mono for Android is of course lagging behind the main (Java) Android. As far as my initial attempts have revealed, the Mono Android API is not entirely complete vis-à-vis the corresponding Java Android API. The Android Honeycomb API for tablets is also not yet available on Mono for Android. It would otherwise be interesting to see if the C# DICOM class library mdcm could be built for use on Android as well?

There is also the concern that Xamarin is simultaneously developing Monotouch for iOS devices (iPhone and iPad). Android and iOS might just be one platform too many to maintain for Xamarin?

By the way, csunits on Monotouch remains to be tested. Given the success with Mono for Android, csunits and Monotouch should be no issue at all. Current lack of development resources (read: a Mac computer) prevents me from testing this right away. Who knows, maybe there is someone else out there who would like to give it a try?

Physical unit converter for the phone!

It was all too tempting, I had to try it out to see if I could make it work.

My first attempts with the Windows Phone 7 development tools were disappointing, but with WP 7.1 beta ("Mango") I have managed to build and use the csunits class library without problems.

And this is what the Physical Unit Converter looks like in the Windows Phone emulator!

I have previously created a Silverlight unit converter, which can also be found in the csunits GitHub repository. The Windows Phone Unit Converter uses practically the same code, except that the ComboBoxes for selecting quantity and units have been replaced with the ListPicker control from the WP7 toolkit.

It should be noted that the csunits class library compiled already under WP7, but some of the type reflection methods were not implemented, leading to errors when trying to identify the quantities of the library. This functionality has been a prerequisite for automatically loading the full set of quantities in the unit converter applications. Luckily, the required type reflection methods are apparently implemented in "Mango".

This has primarily been a "proof-of-concept" exercise, simply to explore the possibility of developing for the Windows Phone platform. The WP Unit Converter is definitely not in a "production state" right now :-)

I have for the time being ignored some rough edges in the application. In particular, the quantity list picker does not properly display the actual quantities in selection mode. The problem does not apply to the unit list picker controls, so I am fairly confident that the issue with the quantity list picker can be fairly easily solved.

One might ask whether these efforts are easily transferable to iPhone and Android phones as well? In principle I believe the csunits class library would be possible to build also using MonoTouch and Mono for Android, and from there it should be fairly easy to design user interfaces specific for each platform. But I'll leave this question open for now...

Direct optimization of treatment machine parameters in RT - Been there, done that!

In the early 90s I did my Ph.D. on radiotherapy optimization at Karolinska Insitute, supervised by professors Anders Brahme and Bengt Lind. The core part of this work concerned the development of a dose calculation formulation that facilitated the direct optimization of practically any beam delivery parameters that are relevant in external beam radiotherapy.

In the article Simultaneous optimization of dynamic multileaf collimation and scanning patterns or compensation filters using a generalized pencil beam algorithm, published in the AIP journal Medical Physics in July, 1995, I describe this algorithm in detail. In particular, I describe how the algorithm can be applied to optimize beam weights, effective wedge angles and jaw and MLC leaf positions.

To illustrate the power of the algorithm, it is applied to a number of different optimization scenarios. Two of these scenarios concern the optimization of leaf positions in multiply segmented MLC beams in combination with one or multiple beam scanning patterns (once relevant for the Scanditronix MM50 Racetrack Microtron, nowadays primarily applicable to proton therapy).

As far as I have been able to find out, this article is the first where MLC leaf positions of multiply segmented beams are optimized directly. Prior to my work, MLC segmented beams had been optimized in a two-step process, where initially an optimal fluence modulation pattern was obtained, and this pattern was then approximated by a finite number of MLC segments.

In retrospect, the direct MLC segment optimization could perhaps have merited an article of its own. Anyway, the new approach was recognized for example by professor Steve Webb who in his review books The physics of Conformal Radiotherapy: Advances in Technology and Intensity-modulated Radiation Therapy devotes one section per book on my algorithm. In Intensity-modulated Radiation Therapy, professor Webb also identifies subsequent work by other authors along the same lines of direct leaf position optimization of multiply segmented MLC beams.

In the IMRT optimization that I implemented in Helax-TMS in the late 90s, I applied some of the developments from my 1995 article. I deliberately excluded direct optimization of the leaf positions though, due to development time constraints. In the Helax-TMS successor, Oncentra External Beam, the direct optimization of leaf positions has eventually been incorporated through the optimization component that Raysearch has provided Nucletron with.

In 2002, Dr. David Shephard published his article on Direct Aperture Optimization, DAO, in Medical Physics. DAO is yet another implementation of direct optimization of jaw and MLC positions in single and multiply segmented beams. The main novelty is that Dr. Shephard uses a simulated annealing optimization engine, whereas I in my work from 1995 used a gradient-based optimization engine, since my dose calculation formulation allowed me to. Dr. Shephard references some of the direct optimization predecessors that were also identified by professor Webb in his Intensity-modulated Radiation Therapy book. Intriguingly enough, my article from 1995 is not referenced.

The DAO algorithm has been implemented in the commercially available Prowess Panther treatment planning system.

It is fascinating to see that, despite the preceding work that I and other authors have published on the direct optimization of jaw and leaf positions of multiply segmented radiation beams, Dr. Shephard and his co-workers have still managed to claim a US patent for the DAO technique.

Just recently, Prowess filed a complaint against Raysearch, claiming that Raysearch infringes on the DAO patent with their implementation of the direct optimization technique. It will be interesting to follow the legal process of this case. Who knows, I might even get a recognition in the court ruling? :-)

Logging now working in Silverlight mdcm

Another troublesome issue in the mdcm Silverlight DICOM class library has been the logging.

In the main mdcm project, the NLog class library for logging can be used without restrictions. There is a 2.0 beta version of NLog containing a Silverlight class library, which out of necessity is rather restricted.

However, with the help of the following response on Stackoverflow (many thanks, Stackoverflow user wageoghe) I have managed to add very simple logging capability to the Silverlight mdcm library as well.

With this solution, logging records are saved in a named file in the isolated storage of the running application. To enable logging globally, simply call the following static method:

Debug.InitializeIsolatedStorageDebugLogger();

To log something, simply access the Log member of the Debug static class:

Debug.Log.Warn("Some warning message {0}", variable);

This is a screen dump of the SL.DicomToXml Silverlight application included in the Silverlight mdcm project. To verify the logging functionality I have added a text box in the bottom of the application page to continuously display the contents of the NLog file:

Image codec support in Silverlight mdcm

In my Silverlight adaptation of the mdcm DICOM class library, image codec support is only barely existing. The only fully supported codec is the RLE (Run Length Encoding) format, which is also provided as a fully .NET managed implementation in the main mdcm library.

There are a number of image files in various compression formats available for testing here. I have used these images to verify that RLE compressed files can indeed be decoded by the Silverlight mdcm library.

I have also attempted to implement JPEG codec support in the Silverlight library, but I have not yet been successful. Since I am limited to fully .NET managed implementations of JPEG encoding and decoding, there are only very few open-source alternatives available.

I have thus far only identified the following two open-source alternatives:

• FJCore
• LibJpeg.Net

The former is a codec library developed practically from scratch, whereas the latter library is a C# adaptation of the LibJpeg library originally developed by the Independent JPEG Group. Neither of the above implementations appear to support images with precision larger than 8 bits. More often than not, the precision of DICOM images is 12 bits, so neither FJCore nor LibJpeg.Net seem to be capable of providing sufficient JPEG codec support in the DICOM context at this stage.

As a sidenote, Leadtools provide codecs for JPEG and several other image formats in its DICOM Silverlight SDK. This SDK however comes at a price...

Networking with Silverlight mdcm

As recently announced, I am adapting the C# DICOM library mdcm to Silverlight. Due to the compactness and security limitations of Silverlight, I have had to make several workarounds. However, I have now reached a stage where a large degree of the original library's functionality is in place. The only large part missing now is codec handling, which is highly dependent upon native support libraries in the original mdcm library.

Most recently, I have included network support in the Silverlight library. The client functionality is definitely in place; with the latest commit in the Github repository there is a working example of a storage SCU (service class user).

There are a few restrictions: Silverlight only supports the TCP protocol; there is currently no support for TLS or SSL. The only available port range is 4502-4534, and the port access has to be granted through a separate policy access server. As far as I have been able to find out, the server that the Silverlight client application is communicating with also has to be located on the same system. The supported DNS name of the computer should be obtained as follows:

string DnsHostName = Application.Current.Host.Source.DnsSafeHost;

(I should state that I have not yet learned all the windings of the Silverlight network support, so there may be more flexibility to this than I yet know.)

To test the functionality, I created a new Silverlight hosting web application in my mdcm fork at Github, denoted SL.DicomToXml.Web. When running this web application via Visual Studio, it is possible to open DICOM files on the regular file system. The DICOM file dump is displayed on screen, together with the contained image if any.

In the background, the application is also trying to send the DICOM object to a storage SCP server on port 4502. For this to work, a storage SCP application has to be running on the same computer (I used the storescp application from the OFFIS DCMTK library).

Furthermore, an access policy server has to be running, granting the Silverlight application access to ports 4502 through 4534. Based on code that I obtained from Stackoverflow user luke here, I also included a very simple policy server application, SilverlightPolicyServer, in the mdcm tree. Before any DICOM object sending can take place, the policy server must also be running; double-click the executable or start it from the command prompt.

Getting this to work in Silverlight was a little bit of a challenge. In particular, the Socket class in Silverlight is extremely stripped compared to its vanilla .NET counterpart. The regular mdcm library also makes extensive use of the NetworkStream class for sending and receiving network data. NetworkStream is not included at all in the core Silverlight library. Fortunately Alexander Wieser has developed a replacement in his Crystalbyte Networking project at Codeplex, and this support class was easily included in the Silverlight mdcm library.

While discussing the workarounds I have had to take in the Silverlight mdcm library, I should also mention that file access has been limited to the isolated storage assigned per user and application. This means that DICOM file access is limited to this isolated storage, and it is only practically available when running the Silverlight application. To access files on the regular file system, the most efficient solution is probably to open the file stream directly through an open-file dialog, pretty much like it is done in the demo application.

Silverlight and a converter for multiple values

Once again I have hit an annoying limitation in Silverlight, and once again the problem has been recognized and mitigated by other developers...

In XAML databinding in WPF, it is possible to do simultaneous data binding conversion for multiple values using the IMultiValueConverter interface. In the Silverlight core libraries there is however only support for single value conversion using IValueConverter.

In one example Silverlight application I developed, I wanted to compute the resulting amount in a specified physical unit, given the amount in another physical unit. A Silverlight multi-value converter would have come in handy, and gladly enough the job had already been done.

Colin Eberhardt has provided an extensive solution together with detailed usage instructions in his blog. I have applied Colin's implementation and it works flawlessly.

Apparently Silverlight 5 Beta is due at the upcoming MIX 2011 meeting. It will be interesting to see whether multi-value conversion will also be included in the SL5 libraries. If not, I still have something to fall back on, thanks to Colin.