Thursday, August 18, 2011

Finally! WPF support in mdcm!

As I have mentioned in several recent blog posts, I have forked Colby Dillion's excellent C# DICOM class library mdcm and implemented a Silverlight DICOM class library largely based on the original mdcm code.

When dealing with Silverlight imaging support, it was apparent that it would be very easy to also make a WPF port of the mdcm class library.

Well, consider it done!

As of today, I have uploaded an update of mdcm to the Github repository, containing a complete .NET 4 class library Wpf.Dicom where DICOM images are rendered using WPF rather than Windows Forms.

Apart from imaging, the Wpf.Dicom project provides the same functionality as the original Dicom and Dicom.Linq projects combined. There are parts of the implemented imaging code for WPF that still remains untested, more specifically image rotation and flipping as well as multilayered images. I plan to test this specific functionality as soon as possible to verify that the WPF implementation is indeed fully functional.

The Dicom.Codec and Dicom.Codec64 projects have previously referenced the original Dicom project. To enable full codec support in WPF, I have updated the codec projects to instead reference Wpf.Dicom, and at the same time I have excluded the Windows Forms-based project Dicom and associated applications from the Visual Studio solution. This is of course an easy thing to change back, if anyone so wishes.

Please feel free to download and use the source code from Github. Comments and improvement suggestions are more than welcome. Do not hesitate to report issues under the Issues tab in the Github repository.

Wednesday, August 17, 2011

Completed mobile adventure: here's the iPhone Unit Converter!

It is now proven without doubt: the csunits class library for units of measurement support in C# is portable without modification to all major mobile platforms: Windows Phone 7(.1), Android, and now iOS!

To enable C# development on the Mac, I have used the MonoTouch tools from Xamarin. The current user interface certainly does not meet Apple design guidelines, but this is what the simple unit converter application looks like in the iPhone simulator:

This being my first attempt at C# development on the Mac, I have experienced quite a number of pitfalls. At this point I am not sure if these problems are due to limitations and issues in the MonoTouch components, or whether the problems are due to my limited experience with the platform.

Nevertheless, the unit converter works as intended, providing immediate unit conversion for all quantities and units currently represented in the csunits library. The source code, including a MonoDevelop solution (csunits-monotouch.sln) and MonoDevelop projects, are available in the Github repository.

Actual deployment on a real iPhone or iPad has not yet been tested. Phone deployment is not for free. For this proof-of-concept, I considered running on the iOS Simulator to be enough.

Thursday, August 4, 2011

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?



Thursday, June 9, 2011

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...

Tuesday, May 24, 2011

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? :-)

Thursday, May 12, 2011

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:

Monday, May 2, 2011

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:
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...