Thursday, May 22, 2014

BioSuite and DICOM

A few years ago Dr. Julian Uzan together with Professor Alan Nahum developed a comprehensive research tool for radiobiological evaluation and optimization, called BioSuite. The tool has continuously evolved and has been made available at no extra cost for the participants of the Clatterbridge Radiobiological Modeling course that is being held (more or less) annually.

BioSuite uses input from treatment planning systems in the form of differential dose-volume histograms (DVHs). More specifically, the tool supports DVHs exported from Philips Pinnacle³ and Varian Eclipse. One format BioSuite does not support though, is DICOM!

To overcome this limitation, I have developed a simple preprocessing tool called the BioSuite Exporter. This tool allows the user to import DICOM RT Plans, RT Structure Sets and RT Doses,


and based on this data the tool computes the resulting dose volume-histograms associated with each RT Plan for the regions of interest in the RT Structure Set. The user can view the dose-volume histograms and select a subset of the DVHs for export.


Upon export, BioSuite Exporter writes absolute volume, differential dose-volume histograms for each of the selected regions-of-interest in a comma-separated value (CSV) format that can be imported by BioSuite.

For BioSuite users and others interested in obtaining a free copy of this tool, please contact me at biosuite@cureos.com.

Wednesday, May 21, 2014

Arrays are bound to get you into trouble

A few days ago I read this old yet informative blog post by Eric Lippert, about why it is good practice to avoid arrays as much as possible in your C# code. Since I am working a lot with numerical computations, I do use arrays quite a lot since they tend to be faster than class-based collections such as List<T> etc. for my particular purposes. Nevertheless, Eric's article is a good eye-opener on the caveats associated with arrays.

Ironically, I today stumbled into a serious problem involving arrays and multiple threads. It was not obvious from the start that it would lead to problems, but it certainly did.

Somewhat simplified, I had one pre-sorted key array with no duplicate entries and a collection of value arrays. The value arrays were subject to some operation from a 3rd-party library that involved sorting based on the key array. The operation on one value array would be independent of the operations on the other arrays, so I decided to parallelize the process to gain time. Schematically, the code looked like this:

double[] x = GetSortedKeyArray();

var y = new double[samples][];
for (var i = 0; i < samples; ++i) y[i] = GetValueArray(i);

Parallel.For(
    0,
    samples,
    i =>
    {
        ThirdPartyLibMethodUsingArraySort(x, y[i]);
    });

And in the 3rd-party library:

public void ThirdPartyLibMethodUsingArraySort(
    double[] x, 
    double[] y)
{
    ...
    Array.Sort(x, y);
    ...
}

Since the key array was already sorted before the first call to the 3rd-party library method, I never imagined that the Array.Sort call would cause any trouble. As long as the number of items in the key and value arrays were no more than 16, it did not either. But for 17 items and above, chaos!

If the number of items in the key and value arrays exceeded 16 and the number of value arrays were large enough (of the order of hundreds on my machine), the Array.Sort method would on some calls return duplicates in the key array x. Of course, once this error started appearing, it would continue to propagate and completely run havoc with the supposedly immutable key array.

Reading the MSDN documentation on Array.Sort, it seems like array size 16 is an important limit, where the sorting internally switch from an insertion sort algorithm to a Quicksort algorithm. The Quicksort algorithm apparently does not account for the fact that the incoming array might already be sorted and shuffles around the data. When the same array is then entering Array.Sort from another thread before the previous thread is finished, things are bound to go wrong.

What I had to do in the end was to copy the contents of x to a temporary array before each call to the 3rd-party library method, and call the method using the temporary array instead:

    {
        var tmp = new double[x.Length];
        Array.Copy(x, tmp, x.Length);
        ThirdPartyLibMethodUsingArraySort(tmp, y[i]);
    }

Take-home message: you can never be too careful with array immutability in a multi-threaded context.

Monday, May 19, 2014

3D scatter plots for WPF and Windows 8

A few years ago I was searching for an open source solution for creating 3-D scatter plots with WPF. Googling around eventually led me to this solution on CodeProject.

I have used this solution in a few of my projects since, but as far as I have been able to tell, the library has not evolved at all since the article was published in 2009.

Recently, I came across a newer 3-D drawing and charting project for WPF, namely the Helix 3D Toolkit. This project is actively developed, mainly by Øystein Bjørke, it has a vibrant user community and it is also available for Windows 8 applications (i.e. "Metro")!

First glancing at the library, I could not find any 3-D scatter plot solution. Fortunately, Øystein proposed a solution based on one of the surface plot examples in one of the sample applications. Based on Øystein's suggestion I today created a very simple 3-D scatter plot example for Helix 3D Toolkit. It looks like this:


Nothing fancy, just a proof of concept. Anyway, I made a pull request that Øystein kindly accepted, and my example is now included in the Helix 3D Toolkit example collection.

Friday, May 16, 2014

What does the _ in lambda expressions stand for?

While reading this interesting blog post by Stephen Cleary, I noticed that he used the following lambda construct in some of the code:

_ => action()

At first, I couldn't figure out what it meant, but like so many times before, Google search came to the rescue (here and here).

It turns out that this is a C# idiom. Since _ (underscore) is a valid C# identifier, it is applied here to represent an ignored identifier in a single-input-parameter lambda expression. It is the same as writing for example:

x => action()

or

(x) => action()

but it is thought to be more obvious that the parameter on the left-hand-side of the lambda expression will be ignored if an underscore identifier is used.

Now, the accepted answer on StackOverflow and the associated blog post is a little careless with the wording: this idiom is actually not applicable to parameter-less lambdas, i.e. the empty parentheses () in

() => action()

cannot be replaced with _. This would imply a mismatch between the number of input parameters in the () lambda expression (0), and _ (1). Trying to use _ with parameter-less lambdas will inevitably lead to compilation errors.

PCL Tips and Tricks: List.ForEach

The introduction of Portable Class Libraries, PCL, considerably facilitates the sharing of functionality across managed Microsoft and Xamarin platforms. I am very enthusiastic about the PCL concept, and I have ported several .NET Framework open source projects to Portable Class Libraries. Along the way I have stumbled across various issues of making .NET Framework source code PCL compliant. In this mini-series I'll share my experiences and workarounds to facilitate the transfer to PCL for other developers.

The List<T>.ForEach method is available on all managed Microsoft platforms, except one: Windows 8 (f.k.a. Windows Store or Metro). Possibly as a consequence of this, it is also not available in the Portable Class Libraries, not even when Windows 8 is not targeted.

The exact reasons for leaving out List<T>.ForEach from Windows 8 and PCL is unknown to me, but maybe the library maintainers want to discourage developers from using this method since it allows for side effects in a functional context (thanks Vagif Abilov for pointing this out). Fortunately, there is a simple replacement that should work practically always: use foreach instead!

So, instead of:

List<string> strs = ...;
strs.ForEach(str => DoSometing(str));

Use this:

List<string> strs = ...;
foreach (var str in strs) { DoSomething(str); }

I recently looked into the Clipper project, which is an open source library for clipping and offseting 2D polygons, available in several languages. I examined the C# source code, and it turned out that the author had used the List<T>.ForEach construct in his code. This was in fact the only issue preventing the C# Clipper code from being truly portable. Therefore, as a feature request I asked him to use foreach instead. This feature request was later implemented, and it is now possible to take the entire clipper.cs file and include it in any Portable Class Library.

Here are a few links about List<T>.ForEach vs. foreach:



Wednesday, May 14, 2014

Open source project of the day: Meta.Numerics

Over the last four years I have contributed a fair amount of code to the open source community. Some of these projects I have initiated myself, other projects are forks of existing projects that I have adapted to Portable Class Libraries or new target platforms. The projects range from optimization and scientific computing, over medical imaging and image processing to utility libraries. In this mini-series I intend to give a short introduction to each of these open source projects.


Meta.Numerics is an open source library for advanced scientific computation in the .NET Framework, with a bias towards statistical computations. The main web site is located here, whereas the library source code is available on CodePlex. The library has less functionality than another open source library for scientific computation, Math.NET Numerics, but at the same time it also has a substantially smaller footprint and a simple-to-use API.

Today, I stumbled across a Meta.Numerics review and noticed that one potential user was disappointed that the library did not seem to be available for Windows Store/Metro/WinRT applications. 

However, Meta.Numerics is available for this platform target, and for Windows Phone, Silverlight, Xamarin.Android and Xamarin.iOS applications as well, which I have also reported to the previously disappointed developer. 

It so happens, that Meta.Numerics is one of the projects that I have adapted to a Portable Class Library! Originally, I ported the library to Silverlight only and these changes were eventually merged into the original source code. When PCL showed up it was however a simple task to continue the adaptation to the entire PCL range of targets.

Since the library primarily is concerned with mathematical computations, it was fairly simple to port it to a wide-ranging PCL library. The only functionality I have not been able to port is the binary serialization of a few classes, and some ADO.NET based methods for initializing statistical samples.

I have done my best to update the PCL library whenever new source code is committed to the original .NET library. The PCL version of Meta.Numerics is available on Github.

Tuesday, May 13, 2014

PCL Tips and Tricks: Hashtable

The introduction of Portable Class Libraries, PCL, considerably facilitates the sharing of functionality across managed Microsoft and Xamarin platforms. I am very enthusiastic about the PCL concept, and I have ported several .NET Framework open source projects to Portable Class Libraries. Along the way I have stumbled across various issues of making .NET Framework source code PCL compliant. In this mini-series I'll share my experiences and workarounds to facilitate the transfer to PCL for other developers.

C# code that has its roots in pre-generic time (.NET Framework 1.x, that is) often tend to contain non-generic collections such as ArrayList and Hashtable.  In the Portable Class Libraries however, non-generic collections are avoided to the largest possible extent, and Hashtable is one of the missing classes.

Hashtable is simply a non-generic dictionary (it implements IDictionary) and it also shares the main methods and properties with the generic Dictionary<TKey, TValue> class, which is available across all PCL profiles.

It is thus actually quite straightforward to replace all Hashtable instances with Dictionary<TKey, TValue> instances. And as an added benefit, the dictionary can often be specialized as well, i.e. instead of replacing Hashtable with Dictionary<object, object> you can apply the actual key and value types.

Here is one example from the CSJ2K project, which is a C# class library for JPEG2000 encoding and decoding. In the .NET Framework-only project on Codeplex, in the ChannelDefinitionBox class, the field definitions is declared as a Hashtable where int is always used as keys and int[] as values.So, in my PCL adaptation of the CSJ2K project on Github, I have happily replaced Hashtable with Dictionary<int, int[]> in the adapted ChannelDefinitionBox class.

One additional comment is in place: in the aforementioned project CSJ2K, the hash tables are consistently created using the Synchronized method to ensure that the hash table is thread-safe. Dictionary<TKey, TValue> on the other hand does not guarantee thread-safety. A solution to this problem would be to instead use ConcurrentDictionary<TKey, TValue>, but this specialized dictionary is available in substantially fewer PCL profiles. If your PCL is targeting Windows Phone 8 or earlier, or Silverlight for that matter, ConcurrentDictionary will not be available. There is another workaround to this issue, but I'll save that for a subsequent post...

Friday, May 9, 2014

PCL Tips and tricks: ASCIIEncoding

The introduction of Portable Class Libraries, PCL, considerably facilitates the sharing of functionality across managed Microsoft and Xamarin platforms. I am very enthusiastic about the PCL concept, and I have ported several .NET Framework open source projects to Portable Class Libraries. Along the way I have stumbled across various issues of making .NET Framework source code PCL compliant. In this mini-series I'll share my experiences and workarounds to facilitate the transfer to PCL for other developers.

It appears to be very common that .NET Framework class libraries containing some kind of text processing relies on the ASCIIEncoding class, or alternatively the Encoding.ASCII static property.

ASCIIEncoding is not portable, but fortunately it can very easily replaced with another encoding that is available in (I think) all PCL profiles, namely UTF8Encoding. The UTF-8 encoding contains the ASCII character set as a sub-set, and it is even stated in the MSDN documentation for Encoding.ASCII that:

If your application requires 8-bit encoding (which is sometimes incorrectly referred to as "ASCII"), the UTF-8 encoding is recommended over the ASCII encoding. For the characters 0-7F, the results are identical, but use of UTF-8 avoids data loss by allowing representation of all Unicode characters that are representable. Note that the ASCII encoding has an 8th bit ambiguity that can allow malicious use, but the UTF-8 encoding removes ambiguity about the 8th bit.

So, whenever encountering ASCIIEncoding or Encoding.ASCII in source code that you are porting to PCL, simply replace it with UTF8Encoding and Encoding.UTF8, respectively.

Thursday, May 8, 2014

Open source project of the day: Evil DICOM

Over the last four years I have contributed a fair amount of code to the open source community. Some of these projects I have initiated myself, other projects are forks of existing projects that I have adapted to Portable Class Libraries or new target platforms. The projects range from optimization and scientific computing, over medical imaging and image processing to utility libraries. In this mini-series I intend to give a short introduction to each of these open source projects.


A while back, Rex Cardan published his DICOM toolkit Evil DICOM. Evil DICOM is a .NET Framework based light-weight toolkit primarily for parsing and manipulating DICOM files. Network communication is barely included, and the toolkit does not contain any imaging functionality.

The lack of network and imaging functionality makes Evil DICOM a suitable candidate for turning into a Portable Class Library, and thereby substantially broadening the platforms on which Evil DICOM can be utilized.

When I first came in contact with Evil DICOM, my initial idea was to adapt the toolkit to Windows 8 (formerly known as Metro) applications. Few changes were required, it was practically only the file I/O that had to be adapted to Windows 8/Metro. One of the very early commits in my Evil DICOM fork on Github contains this solution. My work also led Rex Cardan to look in the same direction, and he has later published his own Windows 8/Metro application based on Evil DICOM in the Windows Store.

Rex later made a large revision of the Evil DICOM class library, and I then decided to take a step further and attempt to adapt the library to a Portable Class Library targeting as many platforms as possible.

The result of this adaptation is available in my Evil DICOM fork on Github. This PCL version of the library provides all functionality of the original class library except one class for reading DICOM files via sockets. This specific functionality has instead been made available as a separate .NET Framework only class library. The Portable Class Library currently targets these platforms:

  • .NET Framework 4.5 and higher
  • Windows 8 and higher (formerly known as Metro)
  • Windows Phone 8 and higher (Silverlight)
  • Silverlight 5
  • Xamarin.Android
  • Xamarin.iOS
As I mentioned in the beginning, Evil DICOM is extremely light-weight and in principle limited to DICOM file textual manipulation. A substantially wider ranging C# DICOM toolkit is fo-dicom. It so happens that I have also extended this toolkit to other Microsoft and Xamarin platforms. However, this will be the issue of a subsequent post in this series. Stay tuned...

Wednesday, May 7, 2014

Open source project of the day: YAMP

Over the last four years I have contributed a fair amount of code to the open source community. Some of these projects I have initiated myself, other projects are forks of existing projects that I have adapted to Portable Class Libraries or new target platforms. The projects range from optimization and scientific computing, over medical imaging and image processing to utility libraries. In this mini-series I intend to give a short introduction to each of these open source projects.


Since I have just recommended the project on StackOverflow, I thought I'd start with YAMP. YAMP is short for Yet Another Math Parser. It is written mainly by Florian Rappl, and is a high-performing parser of mathematical expressions including scalar, vector and matrix algebra, a vast set of mathematical and statistical functions, variable management and so on. The parser is relatively fast compared to other mathematical parsers available, and it is written entirely in managed C# code; it has no dependencies towards native libraries.

Originally, YAMP was targeted solely at the .NET Framework. However, since YAMP is written entirely in C# and is only using a limited set of non-portable classes and methods, I took on the challenge of porting YAMP to a Portable Class Library, PCL, targeting as many of the Microsoft (Windows 8/Metro, Windows Phone, Silverlight) and Xamarin (iOS, Android) platforms as possible. It was a relatively simple task to adapt YAMP to PCL. The original code made use of some non-portable methods that could be easily replaced with corresponding calls to portable equivalents. The main issue turned out to be the inclusion of file I/O operations in the vanilla YAMP version. Fortunately, these classes were isolated and could easily be excluded from the PCL class library.

I published my adaptations in a Github fork of the original YAMP library; my fork is available here.

My work was appreciated by the main author Florian Rappl, and I have continuously collaborated with him to merge all PCL adaptations into the main YAMP repository.

Now, YAMP is avaliable as a .NET Framework only NuGet package here, and a PCL enabled NuGet package YAMP.Portable is available here.

To learn more about YAMP, you may also have a look at this CodeProject article by Florian Rappl.

Tuesday, May 6, 2014

Copying a project resource image to a WriteableBitmap in a Windows Store application

It seems like the Windows Store application projects in Visual Studio 2013 Update 2 do not like embedded resources:

Build action 'EmbeddedResource' is not supported by projects with an output type of 'appcontainerexe'.

So far I have used embedded resources to include image files that I programmatically assign to WriteableBitmap objects for example in my Windows Store applications, but now this approach does not seem so fruitful any longer.

Here is what I did instead.

a) Set the image file Build Action to Content, and Copy Always to Output Directory:


b) Reference the WriteableBitmapEx library, most easily via NuGet.

c) Use the FromContent extension method in the WriteableBitmapEx library to load the image via its URI:

var tmp = BitmapFactory.New(1, 1);
var wbm = await tmp.FromContent(
    new Uri("ms-appx:///Assets/image.jpg"));

And voilá! Now the image file resource is sufficiently loaded into wbm.

BitmapFactory.New is a method in WriteableBitmapEx which can be used portably to create a WriteableBitmap object across different targets such as Windows Store, Windows Phone, .NET Framework etc.

Otherwise, practically all methods in WriteableBitmapEx are extension methods, and therefore the FromContent method a little awkwardly requires an incoming WriteableBitmap object, that it ignores.

ms-appx:/// is the root or base URI (Uniform Resource Identifier) of the application, and Assets/image.jpg is the path relative to the base URI.

Monday, May 5, 2014

The revival of a blog

It's been practically two years since I last posted an entry on this blog. It's not that I have not had things to write about (on the contrary). However, there has been a little bit of mismatch between the blog format and my ambitions, and therefore I have rather focused my presence to forums like StackOverflow and Twitter.

At the same time, I continuously make new experiences in the field of software development and radiation therapy that I believe are worthwhile sharing, so I now think it is time to revive the blog. This time I will try to keep the posts shorter and appearing more frequently.

To really mark the beginning of this new era, the blog is also receiving a new name:

Outcome counts - Lessons learned from being a Cureos person.

Welcome to the new ride :-)

Upgrading to VS 2013 Update 2 - One word (or a few) of caution...

I have recently adapted AForge.NET Framework and Accord.NET Framework to Portable Class Libraries (here and here), targeting .NET Framework 4.5 and higher, Windows Store applications (Windows 8 and higher) and Windows Phone 8 and higher.

Both AForge.NET and Accord.NET make extensive use of unsafe code. This feature has not been officially available for Windows Phone 8, but by manually editing the project file of the Portable Class Libraries in question, I have been able to successfully circumvent this limitation.

After upgrading to Visual Studio 2013 Update 2 last week, it seems like this loophole of mine is now at least detected. When trying to compile the libraries containing unsafe code, I get error messages like the following:

Error 1 'Allow unsafe code' is not supported by one or more of the project's targets. [...]\accord\Sources\Accord.Math\Portable.Accord.Math.csproj 0 0 Portable.Accord.Math

For some reason, the libraries still appear to be successfully built, but I am currently not sure of their applicability. Further testing is obviously necessary.

Note: no error is reported when I build the libraries using Visual Studio 2012. For my own peace of mind, maybe I should revert to the previous VS version, then...