Monday, December 19, 2011

Ipopt + Silverlight = True!

Today I have released a new version 0.9.5 of csipopt, the .NET interface to the Ipopt large-scale non-linear constrained optimization algorithm.

Compiled libraries can be downloaded here:
The source code is available here:

A detailed description of the improvements and usage is provided here:

Highlights include:

  • Unsafe directive requirement removed
  • IpoptProblem sub-classable, yielding cleaner instantiation of the optimization problems
  • Native Ipopt methods publicly available
  • Silverlight 5 supported in elevated-trust, out-of-browser applications
Do not hesitate to discuss or report experiences and problems in the csipopt forum!

Sunday, October 30, 2011

Silverlight mdcm merged into Colby Dillion's main fork!

Yesterday, I was excited to see that my Silverlight and WPF fork of mdcm was merged, in its entirety, into Colby Dillion's main mdcm fork.

Since my efforts have now become more "official", I think it could be worth recalling some of the specific issues that are currently applicable in particular to the Silverlight library of mdcm:

  • The Silverlight class library is currently using Silverlight version 5 Release Candidate. It should be fairly straightforward to revert to Silverlight 4, but there may be some incompatibilities especially with respect to network access.
  • I have tried to implement managed support for JPEG codecs in the Silverlight project, but I have so far stumbled on 12 (and 16) bit support. The available open source JPEG codec libraries (FluxJpeg.Core and LibJpeg.Net) only support 8 bit images, and I have not yet been able to extend either of the libraries to 12 bit support. Furthermore, these libraries only support lossy compression.
  • Silverlight 5 will open up new possibilities for the mdcm Silverlight library, since P/Invoke is now supported when running in so called "elevated trust" mode. In particular, it should be possible to implement network server and full image codec support through calls to native libraries. So far, I have not implemented any of these ideas.
  • I have not made any extensive efforts with the MonoTouch project yet; in particular, no image support is implemented. Basic functionality is there though, DICOM file parsing and network client for example works out-of-the-box.

Wednesday, October 12, 2011

LINQ and Dictionaries

LINQ is a very powerful technique for operating on collections of objects in .NET. If you for example have a collection of integers, it is a simple task to pick the even numbers from the collection using LINQ:

int[] ints = new[] { 1, 3, 6, 8, 9, 10 };
IEnumerable<int> evens = ints.Where(i => i % 2 == 0);

Similarly for dictionaries:

Dictionary<int, int> intDict = new Dictionary<int, int> 
    { { 2, 3 }, { 3, 5 }, { 6, 7}};
Dictionary<int, int> evenKeys = intMap.Where(kv => kv.Key % 2 == 0);

What? Compilation error?!?

In fact, the intDict.Where() statement is not entirely correct. From the LINQ point of view, Dictionary<,> and other classes implementing the IDictionary<TKey, TValue> interface are actually regarded as implementations of the IEnumerable<KeyValuePair<TKey, TValue>> interface. Thus (ignoring for a moment that we could also have used the var keyword), the correct evenKeys assignment should read:

IEnumerable<KeyValuePair<int, int>> evenKeys = 
    intMap.Where(kv => kv.Key % 2 == 0);

Now, my guess is that in the normal case one would rather have the above assignment to return a Dictionary. Fortunately, LINQ also provides a number of ToDictionary method overloads. So for the evenKeys assignment to return a Dictionary we simply type:

Dictionary<int, int> evenKeys = intMap.Where(
    kv => kv.Key % 2 == 0).ToDictionary();

What?! Compilation error again?

Yes, because the ToDictionary method also operates on IEnumerable<T> objects. You need to tell the compiler how you want to design your Dictionary based on this arbitrary type T. For correctness, our evenKeys assignment has to be expressed as follows:

Dictionary<int, int> evenKeys = intMap.Where(kv => kv.Key % 2 == 0).
    ToDictionary(kv => kv.Key, kv => kv.Value);

For dictionaries, this explicitness may appear quite counter-intuitive, and there are several forum questions on the Internet indicating that this API design indeed has caused confusion (here, here and here for example).

After giving this issue some thought, I believe I have come up with an approach to bypass this hurdle of confusion. I have implemented the following extension method in a static utility class:

public static Dictionary<TKey, TValue> ToDictionary<TKey, TValue>(

    this IEnumerable<KeyValuePair<TKey, TValue>> source)


    return source.ToDictionary(kv => kv.Key, kv => kv.Value);


This overload of ToDictionary takes any object that implements the IEnumerable<KeyValuePair<TKey, TValue>> interface, which is a common return type when invoking LINQ operations on dictionaries, and returns a Dictionary<TKey, TValue> object using the same keys and values as the dictionary in the argument list. With this extension method defined, I now actually can enter:

Dictionary<int, int> evenKeys = intMap.Where(
    kv => kv.Key % 2 == 0).ToDictionary();

without getting the annoying compilation error.

Now this is all good and well, but I then decided to take the issue even one step further. Wouldn't it be good if for example the Where() extension method when operating on a Dictionary by default returned a Dictionary with the same keys and values?

Well, it can of course be done! And here is the solution:

public static Dictionary<TKey, TValue> Where<TKey, TValue>(

    this IDictionary<TKey, TValue> source, 

    Func<KeyValuePair<TKey, TValue>, bool> predicate)
    return Enumerable.Where(source, predicate).
        ToDictionary(kv => kv.Key, kv => kv.Value);


When this method is defined, it effectively hides the general Where(IEnumerable<T>, Func<>) extension method when the IEnumerable<T> object also implements the IDictionary<TKey, TValue> interface. Having the above Where() extension method defined now even makes it possible for us to apply our first dictionary LINQ attempt without compilation error:

Dictionary<int, int> evenKeys = intMap.Where(kv => kv.Key % 2 == 0);

Unfortunately, this method will always return a Dictionary object, regardless of whether intDict is a SortedDictionary or SortedList or another object implementing the IDictionary<TKey, TValue> interface. At this point, I have no viable solution for returning the same dictionary type that was used as input to the specialized Where method. The quest for a solution will continue nonetheless.

I have also collected a few more similar LINQ extension method overloads in a Github project that I have chosen to call ... dictionarylinq

In this project you may find dictionary overloads for the Except, Intersect and Union extension methods. Due to their signatures, for these methods it has actually been possible to implement a specialized overload that returns the true input dictionary type, together with a designated overload with better performance for the Dictionary<TKey, TValue> class.

Included are also method overloads for the Select method when the return type of the Func<TSource, TResult> object is a KeyValuePair<TKey, TValue>. It would be relatively easy to add more method overloads to dictionarylinq, but for now this is what there is.

When the extension methods from the dictionarylinq utility class are included in your application, these methods will effectively hide the general extension methods in the System.Linq.Enumerable class. If you do want to fall back on the general methods in a certain scenario, either make an explicit cast to the IEnumerable<> interface:

IEnumerable<KeyValuePair<int, int>> output = 

    ((IEnumerable<KeyValuePair<int, int>>)input).Where(kv => kv.Key > 3);

or invoke the static method explicitly:

IEnumerable<KeyValuePair<int, int>> output = 
    Enumerable.Where(input, kv => kv.Key > 3);

Please also note that the dictionarylinq class library in the Visual Studio solution is a Portable Class Library. This means that the library uses the "least common denominator" of .NET Framework 4, Silverlight and Windows Phone 7 base class libraries. The library can be built once and consumed by all three .NET technologies without rebuilding. If you have not installed the Portable Library Tools, simply create a new designated class library project and include the source code from the dictionarylinq class library, or include the source code directly in your own class library or application.

I hope that this effort can be useful also to others than myself. For questions and comments on this work, please do not hesitate to contact me for example via a blog comment. If you are a Github user, please feel free to report code issues via the project's Issues tab.

Good luck with Dictionary and LINQ!

Friday, October 7, 2011

Getting the grip on your version control

I have recently been working with several different open-source projects that are available on Google Code, Github, CodePlex etc. The projects tend to use different software for managing version control, which in turn requires multiple SCM clients to be installed on the development system.

Version control software commonly used in open-source projects today include Subversion, Git and Mercurial. By default, the version control software is accessed through command-line interfaces. However, there are several different GUI wrappers available to facilitate the version control management. On Windows, different flavors of Tortoise are predominantly used. These tools are primarily shell extensions, enabling version control management inside Windows Explorer. TortoiseCVS for CVS version control was first in line, and it has inspired or formed the basis to followers like TortoiseSVN, TortoiseGit and TortoiseHg.

The various Tortoise tools makes version control management much easier and more efficient, and there is normally no problem having several of these tools installed at once on the same computer.

There is one annoying issue though: all the above tools use the same icons and icon overlays in Windows Explorer. It is therefore not immediately possible in Windows Explorer to determine which version control software that is being used to manage a specific folder.

Of course, if you enter the folder the version control administration sub-folders (.svn, .git, .hg, etc.) will be listed if you have configured Windows Explorer to display hidden folders. But this is a sub-optimal behavior; ideally the version control software should be detectable through some indication in the Windows Explorer list, or when hovering the mouse over the folder in question.

In case someone had experienced the same annoyance as I and found a workaround for it, I posted a question on the subject at StackOverflow. I got a few answers primarily explaining why the same icon overlays are used, but then I also got an eye-opening answer from Stefan Küng, lead developer of TortoiseSVN. Stefan suggested me to customize the version controlled top folder using the approach described here. This was exactly what I had looked for: a method for customizing the folder layout and provide explanatory text in the tool-tip when hovering over the folder with the mouse pointer!

My only remaining concern now was that I would have to do this customization manually for each version controlled folder, which would be quite tedious and error-prone when a large number of projects are involved.

But then, what do developers do, if not implementing solutions to repetitive problems?

Thus, I took the bull by the horns and came up with a simple yet efficient console application for managing the folder customization. The application identifies the version control software used in the specified folder, adds a tool-tip and sets the folder icon to indicate which software that is being used to version control the folder. Currently, the application identifies Subversion, Git and Mercurial, but if the conditions are right (version control administration files in a sub-folder with a fix name) it is a straightforward task to extend this list of software. The application source code is available under an open-source license (Eclipse Public License version 1.0) and can be obtained from here.

After running the application on the version-controlled folders in the image above, Windows Explorer will (after a few refreshes) provide the following display:

Hovering with the mouse pointer over a version control decorated folder will clearly indicate the version control software being used:

It is even possible to run the folder decorator application without changing the folder icons. If the icons are not available in the same directory as the folder decorator application, the classic folder icon will be maintained but the tool-tip will still be updated.

The icons have been obtained from the Open Icon Library. The Subversion icon is "Sub-optimal"; I was not able to find a better redistributable Subversion icon. For personal, non-redistributable use, a more identifiable Subversion icon is available here. If you so wish, download this Subversion icon file instead, rename it to svn.ico and replace the existing Subversion icon in the Visual Studio project with the downloaded one.

Happy version-controlling!

Friday, September 16, 2011

P/Invoke: Bundling native DLL:s in Silverlight 5 RC applications

One of the many interesting new features in Silverlight 5 RC is the ability for elevated trust applications (in-browser as well as out-of-browser) to access native DLL:s via P/Invoke.

Some interesting application examples are given here and here. These examples show how easy it is to access system DLL:s such as user32.dll, kernel32.dll and psapi.dll. However, the issue appears to be more complex when it comes to native DLL:s that are not automatically available on the system.

Ideally (I think), you would like to bundle the native third party DLL:s as Content in the XAP file, and the XAP file would be artificially included in the P/Invoke search path. Unfortunately, this is not the way it works today. When I bundle my third-party native DLL as Content in my Silverlight 5 RC application, and try to access one of its methods via the following declaration,

public static extern int add(int a, int b);

I get a discouraging DllNotFoundException. It does not help if I add the .dll extension to the file name, and I have also not been able to find the DLL by applying any of the pack URI approaches to the DLL file name.

Several people, including myself, have brought up this issue in various forums, but so far I have not seen any published solution to the problem.

Well, as we say in Sweden, "själv är bäste dräng" (which is similar to "if you want something done, do it yourself"), so here is my attempt to solve the problem. Granted, it might not be the most Elegant Solution, but at least it is A Solution.

It is important to note that this solution is applicable primarily to Silverlight 5 RC. In the best of worlds, Microsoft will fix the native DLL path issue in the RTM release of Silverlight 5, and then this solution would be superfluous. We'll see what happens in the end.

Note also that since P/Invoke is a feature requiring elevated trust, this solution is only relevant to applications running in elevated trust (in- or out-of-browser).

In short, the solution is to bundle the native third party DLL:s as resource files in the Silverlight 5 RC application, and when the application is started copy these DLL:s to a local directory and add the directory to the system path during the execution of the Silverlight application.

In more details, here is how it can be done:

Add each native third party DLL as an existing item to the root folder or, even more preferably, to an assets sub-folder in the Silverlight 5 RC application project.

In the File Properties window, set Build Action to Resource and Copy to Output Directory to Copy if newer.

The DLL copying and PATH environment variable setting of course requires some additional code. Fortunately :-) I have created a static utility class for this purpose. The class is named NativeDllHelper and can be found it is entirety here. Download and add this file to your Silverlight 5 RC application project.

Next, go to the App.xaml.cs or equivalent file. Add the following using statement.

using Cureos.Utility;

In the Application_Startup (or equivalent) event handler, add the following method call to the first line of the event handler.

NativeDllHelper.SetupNativeDllFolder("relpath/dllname.dll", ...);

where relpath is the path relative to the project root folder where the native DLL:s are located, and dllname is the file name of the DLL. Specify all DLL:s to be copied in one argument list; the SetupNativeDllFolder method should only be called once at start-up to avoid adding duplicate entries of the local DLL directory to the system path.

The native DLL files are copied to a My Documents sub-folder Silverlight\Native. If you prefer a different folder for the DLL:s, edit the static constructor of the NativeDllHelper class.

Here is an example call of SetupNativeDllFolder, copying one file NativeDll.dll located in the Assets sub-folder of the Silverlight 5 RC application project.


Having performed these steps, no user intervention is required when running the application, the native methods in the third party DLL:s can simply be invoked using only the file name of the DLL:

public static extern int add(int a, int b);

A complete example SL 5 RC application utilizing this functionality can be downloaded from here. Note that it contains a C(++) project for creating the example native DLL.
If you try out the application and get build errors due to copy prevention the first time, building a second time should do the trick. You might also need to manually set the start page of the Web project to the .aspx file.

The application itself is very simple; there is this button

with the following click event handler associated to it:

private void Button_Click(object sender, RoutedEventArgs e)
  button.Content = add(5, 7);

The add method is a native method, as declared above. Clicking the button leaves us with the following satisfying button update:

And that is basically all that there is to it. The utility method for copying DLL:s from the application resources can most certainly be further improved, for example by more efficiently handling DLL:s already existing locally. With the current implementation, any existing DLL:s are automatically overwritten. All improvement suggestions as well as reports of successes or failures are highly appreciated.

Monday, September 5, 2011

csipopt on Silverlight: almost there!

As mentioned in a recent post, it is possible to enable unsafe code support in the release candidate of Silverlight 5 for out-of-browser (OOB) applications in elevated-trust mode. Together with the introduction of P/Invoke support in Silverlight 5, it would thereby in principle be possible to also use my csipopt .NET interface to the IPOPT optimizer in Silverlight.

I have now tested to build and run csipopt on Silverlight 5 RC, and it almost works:
  • The code successfully builds, provided the <AllowUnsafeBlocks> tag is manually set to true in the .csproj file.
  • If I bundle the native IPOPT DLL:s as content or resources in the XAP file, I get a DllNotFoundException. At this point I do not know if this is a bug or by design. For now, it works to place the native IPOPT DLL:s in a directory that is included in the system path.
  • When I run my csipopt calling application in OOB elevated-trust mode, I eventually get a SecurityException: An error relating to security occurred
The exception occurs when trying to access an UnmanagedFunctionPointerAttribute in a call to an imported function from the native DLL. It remains to find out whether this restriction will persist into the final release of Silverlight 5. According to the API documentation, the UnmanagedFunctionPointerAttribute is not intended for regular user code in Silverlight. This writing might not be entirely up-to-date, but realistically, I think the restriction will be there at least in Silverlight 5. After all, I am pushing the limits here, using P/Invoke and unsafe code at the same time.

So, bets are I have to wait for Silverlight 6 to employ csipopt in my Silverlight applications.

DICOM on the phone!

I received an e-mail the other day from Pantelis Georgiadis. He wrote that he had forked my mdcm fork and that he is now developing a Windows Phone 7.1 ("Mango") class library based on my Silverlight mdcm efforts.

It is really great to see that Colby Dillion's, and more recently my, work on this C# DICOM library is now proliferating into the phone. It will be very interesting to follow Pantelis's work and see what kind of applications will come out of his efforts.

Friday, September 2, 2011

Unsafe support in Silverlight 5?

Silverlight 5 Release Candidate is available for download since yesterday. Interestingly enough, the RC supports P/Invoke for calling native functions. If only Silverlight could also support unsafe code, it would maybe be possible to use csipopt, my .NET interface to the IPOPT optimizer, from Silverlight...

After downloading and installing the Silverlight 5 RC Tools for VS 2010 SP1, I created a simple Silverlight 5 application project. Discouragingly, the Unsafe checkbox in the project settings is still disabled:

But at least the checkbox is there... Maybe I can manually edit the project file. In a regular C# project, unsafe support is indicated within each configuration/platform PropertyGroup using the following tag:


So, let's insert the same specification in the Silverlight project file and reload the project. The unsafe checkbox is still disabled, but lo and behold, the checkbox is checked!

Next, let's see if I can add some unsafe code and build it. First, I create a button with the instructive text "Click me!". I add the following event handler for the button Click event:

unsafe private void UnsafeTestButton_Click(
    object sender, RoutedEventArgs e)
    int i = 5;
    UnsafeTestButton.Content = i;

The event handler in turn calls a simple unsafe method that dereferences an integer pointer and squares it:

unsafe static void SquarePtrParam(int* p)
    *p *= *p;

After calling the SquarePtrParam method, the click event handler should update the button content to the value of the squared integer. (If the code looks familiar I have copied it from MSDN:s C# reference section on unsafe.)

When I now build this "unsafe" Silverlight application, I get the encouraging prompt "Rebuild All succeeeded"!

Next question is, can the "unsafe" Silverlight application also be executed? It turns out that when I run it in-browser and click the button, I encounter a VerificationException, "Operation could destabilize the runtime", regardless of whether I run in normal or elevated trust. When I run out-of-browser, I get the same exception when running in normal trust, but when running out-of-browser and elevated trust, I can successfully go from here:

to here:

So the conclusion is that Silverlight 5 RC does provide hidden-away support for unsafe code. At this point it only seems to be executable out-of-browser in elevated trust. It will be interesting to see to what extent the unsafe support will be exposed in the official Silverlight 5 release.

Sidenote: I was also able to build the "unsafe" project with Silverlight 4. However, in this case I encountered the VerificationException in out-of-browser elevated-trust mode as well.

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:


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

Wednesday, April 13, 2011

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.

Monday, April 11, 2011

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.

Friday, April 8, 2011

DeflateStream in Silverlight

Another circumvented area in the Silverlight core libraries is compression and decompression of streams. The entire System.IO.Compression namespace that can be found in the regular .NET Framework is missing in Silverlight.

But of course, this limitation has been recognized. In the dotnetzip project on Codeplex, there is a Silverlight branch that among other things provide a DeflateStream replacement. This was a very welcome finding in my efforts of adapting as much as possible of the mdcm C# DICOM library to Silverlight.

My thanks go to the Codeplex user cheeso for this contribution!

WriteableBitmap extensions in Silverlight

The Silverlight WriteableBitmap class, intended for user-defined bitmap design, has very limited functionality by itself. It really only provides the Pixels property for direct modification of the editable bitmap.

Fortunately, this limitation has been recognized and mitigated by René Schule. René has initiated WriteableBitmapEx, which is a library of extension methods for the WriteableBitmap class. The entire project is open source (Microsoft Public License) and can be found on Codeplex.

I most urgently needed methods for rotation and flipping of the bitmap image, but there are also various methods for cropping, resizing, individual pixel editing, drawing shapes on the bitmap etc. All in all some very helpful extension methods for this specific need.

Thursday, April 7, 2011

Parallel operations in Silverlight

As far as I have been able to find out, Silverlight is fairly limited with respect to parallel and/or multithreaded computation support. The Parallel framework from .NET 4.0 is for example not present at all. However, it seems like the ThreadPool is a reasonable candidate for doing at least some work in parallel.

Based on the MSDN documentation for Silverlight, I have composed a very simple code snippet for separating larger computational work onto for example all available CPU cores.

int threads = Environment.ProcessorCount;
WaitHandle[] handles = new WaitHandle[threads];
for (int i = 0; i < threads; ++i)
handles[i] = new ManualResetEvent(false);
delegate(object state)
...some long-running thread-able process...
}, handles[i]);

I tested the above snippet on my eight CPU core computer, and repeated the same process throughout all iterations. The above parallel approach was then 2.5 times faster than the purely sequential one. Not a very impressive result, of course. There is certainly room for improvements, hopefully I will be able to implement more impressive speed-ups in due time.

Wednesday, April 6, 2011


I have recently taken up the effort of adapting the C# DICOM class library mdcm to Silverlight, as can be seen on the forked project website at Github.

Initially, I excluded all imaging, codec, HL7 and network functionality in order to make the library build at all in Silverlight.

Just now I have begun looking at porting the mdcm image handling to Silverlight. The mdcm library uses the .NET System.Drawing library for image handling, which is not available in Silverlight. However, I have modified the source code so that when it compiles for Silverlight, it instead uses the BitmapSource and WriteableBitmap classes from the System.Windows.Media.Imaging namespace.

The added benefit of these modifications are that they are equally applicable to WPF, i.e. it would be a simple task to switch from Windows Forms (which the original mdcm library depends upon) to WPF, given these Silverlight motivated modifications.

I have not explicitly made any WPF adaptation yet, but this is clearly worth future exploration.

UPDATE AUG 21: WPF support is now implemented! Please have a look in the Github repository and this blog post.

Friday, April 1, 2011

Advanced calculations for the web!

In my efforts to bring further functionality to the web, I have today explored the possibility of porting the versatile Meta.Numerics class library to Silverlight. Luckily enough, this was quite an easy task.

I only had to omit serialization support via the Serializable attribute, and the ADO.NET coupling of the various statistical Sample classes, otherwise the Silverlight class library built without issues.

The Meta.Numerics class library is distributed under the Microsoft Public License. I soon hope to find a suitable way for making the Silverlight library modifications public, either via Github or CodePlex.

Wednesday, March 30, 2011

DICOM and Silverlight

Since I would like to provide DICOM functionality in a Silverlight environment, I have examined whether there are any obvious libraries or tools available that would facilitate. Leadtools provide a DICOM Silverlight software development kit as a component in some of their commercial products, but so far I have not been able to identify any open source DICOM toolkit for Silverlight.

I have been using Colby Dillion's C# DICOM library mdcm for a while. This library provides all the DICOM functionality I have had the need for, but it has only been available for desktop applications until now.

However, I have started exploring whether the mdcm library can be sufficiently migrated to Silverlight. My continuous efforts can be followed here. At this stage I have made all shortcuts necessary to make the Silverlight class library build at all, and I have only included the most central parts of the original library. In due time I will fine tune the shortcuts to mimic the original library as much as possible, and I will try to add as many missing parts as I can.

It will be exciting to see if this effort can eventually result in a true open source alternative for DICOM functionality in Silverlight!

Tuesday, March 1, 2011

Units of Measure in C#: Introduction

F# provides the feature Units of Measure for sufficiently handling measurable entities of different units and quantities. Unfortunately this functionality is not accessible from the other .NET languages.

I have searched the internet for a similar solution in C#, but the approaches I have found so far have been relatively heavy-weight and not easily extendable. In particular, the measure type is generally implemented as a class with several members.

I would prefer a more light-weight solution where the measure type is implemented as a struct, preferably with a single member representing the measured amount in some reference unit for each specific quantity. At the same time I would like to have quantity type safety during compile-time, and it should the library should be easily extendable with new quantities and units without affecting the implementation of the measure type.

Based on these requirements, I have now implemented a compact C# Units of Measure library. I have implemented the library using the .NET 3.5 profile, and I have verified that it is possible to build under Mono (2.8 or later) as well. As far as I can tell, there is nothing preventing use of this library from other .NET languages either.

To facilitate feedback from other developers with similar requests, I have made the library available as open source (under the Eclipse Public License). The library is denoted csunits and is available on Github. A quick introduction to the API and instructions for extending the library are also provided on this web site.

I plan to continuously extend the library with new quantities and units, as well as add more functionality to it. In particular, I plan to implement a measure array type for efficient numerical handling of large number of measures in the same unit.

Any feedback on the library is more than welcome. Issues are preferably reported on the Github project web site, but comments to this blog post are perfectly OK as well :-) And ideas on how to further extend the library are of course very much appreciated.