Smartphone image processing development made easy!

A very popular open source C# project for image processing, neural networks, machine learning etc. is the AForge.NET Framework, developed by Andrew Kirillow. AForge.NET has been used in numerous applications. It also forms the basis for the Accord.NET Framework, developed by César de Souza, which substantially extends AForge.NET with additional image processing filters, machine learning algorithms, statistical distributions and much much more. Numerous examples of what Accord.NET Framework is capable of are available here.

AForge.NET was developed to run on the .NET Framework and uses the System.Drawing assembly as basis for image manipulation and processing. In particular the dependency on System.Drawing heavily limits the applicability of AForge.NET (and subsequently, Accord.NET) to more modern platforms, like WPF, Windows (for tablet and desktop, as opposed to desktop-only applications), and Windows Phone.

It seemed like a terrible waste that these frameworks would only be available to the outdated range of Windows Forms applications. So, to enable the invaluable functionality of AForge.NET and Accord.NET for modern Microsoft platforms, I started the project of porting these frameworks into Portable Class Libraries, PCL. These efforts are also open sourced and are available on Github: Portable AForge and Portable Accord.

It should be noted that Portable AForge and Portable Accord cover a subset of the assemblies in the pure .NET based frameworks. Video and robotics support is not included, and audio support is limited. Windows Forms UI controls have not been ported. Nevertheless, practically all image processing and scientific computing functionality is included in the portable frameworks.

To facilitate continuous inclusion of updated code for the two frameworks, I have striven to keep the original AForge.NET and Accord.NET code bases as untouched as realistically possible. To cover up for those parts of the framework codes that are not applicable in the portable class libraries, I have therefore developed two support assemblies called Shim and Shim.Drawing.

Shim, which contains simple implementations of non-UI types and methods unavailable in the PCL profiles, is maintained in a separate Github repository, since this assembly is also immediately applicable as a legacy code bridge in other modern target adaptations, such as the port of the fo-dicom library to the (modern) Windows and Windows Phone platforms.

Shim.Drawing is internal to the Portable AForge and Accord assemblies, and is contained in the Portable AForge Github repository. It provides a down-scaled replacement for the System.Drawing assembly. Along with the platforms of primary interest, Shim.Drawing can also be contained in a .NET Framework WPF project as long as System.Drawing is not simultaneously referenced. Portable AForge and Accord is thus a also shortcut to using AForge.NET and Accord.NET in WPF applications.

To enable the portable framework assemblies on a specific target platform, the Shim and Shim.Drawing assemblies come in various flavors. There are for example specific Windows Phone (Silverlight) 8 versions of Shim and Shim.Drawing that should be referenced in a WP8 application using the Portable AForge and Accord assemblies.

Currently, Portable AForge and Portable Accord are available for the following target platforms:

• .NET Framework 4.5 and higher (for WPF applications)
• Windows 8 and higher (modern tablet/desktop applications)
• Windows Phone Silverlight 8 and higher
• Universal applications, i.e. Windows Phone 8.1 + Windows 8.1
• Xamarin.iOS
• Xamarin.Android

Yes, you read it right! My most recent developments also incorporate the ability to target the Xamarin.iOS and Xamarin.Android platforms. The Xamarin assemblies are however not available as open source. If you are interested in developing AForge and Accord based applications for Xamarin.iOS and/or Xamarin.Android, please contact me directly at licenses@cureos.com.

And now, with AForge and Accord available on the three mobile platforms, cross-platform development using Xamarin.Forms has also become a reality! This means that it is practically possible to contain an entire C# code base in a PCL core library that uses AForge and Accord, and consume this core library from end applications for all three mobile platforms, Windows Phone, Xamarin.iOS and Xamarin.Android.

Just to show what can now be very quickly done, I copied the functionality of the Face Detection (Haar Object Selector) sample application from the Accord.NET samples and contained it in a Xamarin.Forms project. All application code, including setting up the graphical layout and the face detection operation, is contained in the PCL core project. The platform specific end application projects only wrap the core assembly.

And this is what the face detection sample application looks like on the three mobile platforms:

A first small step, perhaps, but the possibilities that have now been opened up are practically infinite :-)

PCL Tips and Tricks: String sbyte* constructor

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.

Some of the PCL profiles do support unsafe code, in particular those profiles targeting Windows 8 and Windows Phone 8.1 (non-Silverlight). This means that it is possible to include for example pointers in the PCL code. On the other hand, methods dealing with unsafe code are rare in the .NET Portable Subset.

One case I ran into the other day is the String constructor. In .NET Framework, there are a few constructors taking an sbyte pointer as an argument, for example:

public String(sbyte* value, int startIndex, int length)

This constructor is not available in the .NET Portable Subset, so I had to come up with a replacement. And I came up with this portable method:

static unsafe String NewString(
    sbyte* value, int startIndex, int length)
{
  var chars = new char[length];
  for (var i = 0; i < length; ++i)
    chars[i] = (char)value[startIndex + i];
  return new String(chars);
}

So, instead of calling new String(...), the calls were changed to NewString(...).

I am still not entirely pleased with this approach of adding a new method to solve the issue. If any blog reader has a leaner solution to this issue, I am all ears.

Upgrading Caliburn Micro from 1.5 to 2.0 for a WPF application

I am happy to see that the Model-View-View Model (MVVM) framework Caliburn Micro is adopting the Portable Class Library approach in version 2.0, and I thought that now would also be a good time to upgrade some of my existing applications from Caliburn Micro 1.5 to version 2.0.

So far, this seems to be a painless experience, but I ran to a few issues after upgrading to 2.0 via NuGet. I'd thought I share these experiences in case someone else is facing the same issues.

The application in question is a WPF application, and it is using the Managed Extensibility Framework (MEF) for bootstrapping the application.

When trying to build the application immediately after the upgrade, I ran into a compilation error in the class definition line of my MEF bootstrapper class:

public MefBootstrapper : Bootstrapper<IShell>

error CS0246: The type or namespace name 'Bootstrapper' could not be found (are you missing a using directive or an assembly reference?)

Searching the Caliburn Micro documentation, I found that the bootstrapper base class is now called ... BootstrapperBase! And it is non-generic.

OK, this change seems easy:

public MefBootstrapper : BootstrapperBase

Hooray, the application builds! Let's run it. And wait ... and wait ... and wait ... but it never starts?

Of course! Since the bootstrapper base class is now non-generic, there is no way for the bootstrapper to know which View it should start displaying, unless it is explicitly being told which View it should display. And according to this documentation page, the fix is easy; just add

DisplayRootViewFor<IShell>();

to the overridden OnStartup method.

Let's try to run the application again. Still no sight of the root window. What is missing?

Looking more closely into the bootstrapper implementation example here, the constructor also seems to perform some initialization operation. This was not necessary with the pre-2.0 Caliburn Micro versions, most likely because the base class constructor performed this operation instead. But with 2.0 it seems to be necessary to also implement the bootstrapper constructor explicitly. According to the migration instructions here it also seems like the Start method has been renamed Initialize. So, here goes:

public MefBootstrapper() { Initialize(); }

Run the application, and ... Yes! The start-up window appears!

To summarize: when upgrading a WPF/MEF application from using Caliburn Micro version 1.5 or earlier to version 2.0, make sure the following details are in place:

• The MEF based bootstrapper class should inherit from BootstrapperBase.
• The root view will be displayed by calling DisplayRootViewFor<> in the overridden OnStartup method.
• The bootstrapper default constructor must be explicitly defined, and call the Initialize() method.

EDIT

Ironically, when I started upgrading my second application I faced a completely different compilation error:

error CS1501: No overload for method 'Publish' takes 1 arguments

But this issue has a quick and easy fix, as pointed out in the migration instructions:

EventAggregator.Publish now takes an action to marshal the event. Use EventAggregator.PublishOnUIThread for the existing behaviour.

PCL Tips and Tricks: Extension methods to the rescue

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.

Now, here is a very common scenario when porting .NET class libraries to PCL:

public class SomeClassToPort
{
    public static byte[] SomeMethodToPort()
    {
        var stream = new MemoryStream();
        var writer = new StreamWriter(stream);
        writer.Write("Result: {0}, {1}", 10, "Hello");
        // some more writer operations ...

        writer.Close();   // Non-existent in PCL
        stream.Close();   // Non-existent in PCL

        return stream.ToArray();
    }
}

Correct, the Close() method is not available for streams, readers or writers in Portable Class Libraries! Since the method in practice only executes Dispose(), the Close() method has been excluded from PCL. Trying to build this code yields the following error:

error CS1061: 'System.IO.MemoryStream' does not contain a definition for 'Close' and no extension method 'Close' accepting a first argument of type 'System.IO.MemoryStream' could be found (are you missing a using directive or an assembly reference?)

Dispose() is generally available in PCL, so one solution is to replace all Close() calls with Dispose(). For those wanting to avoid the hassle and maintenance issues of replacing (potentially numerous) Close() calls, there is however a workaround.

Enter Extension Methods!

Extension methods are a perfect fit for dealing with a scenario like the above. You can just add a static class with an arbitrary name to the PCL library, with code similar to this:

public static class CloseExtensions

{

    public static void Close(this Stream stream)

    {

        stream.Dispose();

    }

    public static void Close(this TextWriter writer)

    {

        writer.Dispose();

    }

}

Now, the compiler will "translate" stream.Close() into the call CloseExtensions.Close(stream) (analogously for the StreamWriter object) and the Portable Class Library can then build successfully. The extension methods perform practically the same operations as the Close() methods in the .NET Framework. Subsequent calls to Dispose() have no effect, so this implementation should be fail-safe. 

There is also no risk of name clashes; even when the PCL library is used in a .NET application the original Close() methods and the corresponding extension methods have completely different signatures (they can just be expressed equivalently in the code).

The Close() methods are probably the most obvious examples where this extension method technique can be applied, but whenever a PCL profile is not including an instance method of one type, the same technique may be applied. Other examples from the top of my head are:

• several methods from the Type class which are not available for Windows 8 (f.k.a. Store or Metro apps); much of this functionality has been replaced by TypeInfo instance and extension methods,
• Stream.BeginRead, Stream.EndRead, Stream.BeginWrite and Stream.EndWrite; again not available for Windows 8 but can be simulated using extension methods.

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.

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.

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.

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:

• StackOverflow question and answers
• Jon Skeet blog post on performance

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.

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

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.

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

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.

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.

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

Nick saved my day

For a couple of days now I have developed a new data fitting algorithm. Normally I commit my work to a remote Git repository, but because of the works-in-progress status of the code, I have not tried to upload anything until today.

Today the code was in a good enough state, so I decided to commit locally and to the remote repository. Using Github for Windows, I first committed and then pressed the Sync button ... and to my complete dismay the synchronization failed AND my local commit disappeared!

At first, I foresaw numerous hours trying to reproduce what I had carefully developed, but fortunately I found the life-saver here:

Git Ready: Restoring Lost Commits

My gratefulness goes to the author of that page, Nick Quaranto. He saved my day today.