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

Derivative-free nonlinear optimization for .NET and Java

Optimization of non-linear objective functions and potentially also non-linear constraints is a common problem in for example radiation therapy.

More often than not, the objective and constraint functions are not easily differentiable, which limits the possibility of applying the more efficient derivative-based optimization algorithms (of which IPOPT is a prominent open-source example).

There are several more or less time-efficient ways of solving (constrained) non-linear optimization problems, including simulated annealing, genetic algorithms and direct search methods such as the Nelder-Mead method (a good overview of mathematical optimization with several links is provided here.)

One rather popular code for solving non-linear optimization problems involving (potentially nonlinear) constraints is the COBYLA2 method. Originally formulated and implemented in Fortran 77 by Michael Powell, this method has been ported to both Fortran 90 and C (through f2c conversion), and it has also been integrated into the Python scientific calculations library scipy. COBYLA2 is simple to use, but it exhibits a rather slow convergence rate; the number of function and constraint evaluations required to locate an optimum that meets the constraints is often very large. As a first-attempt solver when objective and constraint function gradients are complex or time-consuming to derive, COBYLA2 is however often a good choice.

Being primarily a .NET developer, it has until recently not been straightforward to incorporate COBYLA2 though. It has of course been possible to build a native DLL and call COBYLA2 via P/Invoke. This works relatively well in a full .NET Framework environment, but it is only barely applicable in Silverlight applications and completely inapplicable in Windows Phone applications. On the other hand, the Fortran code is relatively well structured and well documented, so I recently decided to port COBYLA2 to C#.

I based the porting on the Fortran 90 code, since this implementation already utilizes more C/C++/C# like constructs. The porting has been successful and I have released the end result as an open-source project cscobyla on Github. Included in this project are unit tests demonstrating the use of COBYLA2 in C# applications. The C# code is very straightforward and does not make use of any advanced functions, so it should be possible to incorporate the code in Silverlight and Windows Phone applications just as easy as it can be incorporated in regular .NET applications. When built into a C# class library, it should be straightforward to reference the COBYLA2 optimization from any other .NET language as well.

Encouraged by the successful porting to C#, I then embarked on a Java porting experience! I have not been able to find a pure Java implementation of COBYLA2, so I considered this a good Java development exercise. Java does not provide delegates, multidimensional arrays can only be represented as jagged arrays, and Java does not support the goto statement, so I was forced to make some design changes. Nevertheless, the Java porting effort also succeeded, and I have also made this result available as open source on Github, the jcobyla project.

And this is not all there is! As mentioned, COBYLA2 converges slowly. Michael Powell has made several efforts to overcome this issue for specialized cases by making use of a local quadratic approximation rather than a linear approximation that is being used in COBYLA2. These improvements have been made available in the NEWUOA code for unconstrained optimization of nonlinear objective functions, and more recently for bound constrained optimization of nonlinear objective functions in the BOBYQA (Bound Optimization BY Quadratic Approximation) code. These codes exhibits substantially improved convergence properties compared to COBYLA2, albeit for unconstrained or bound constrained problems only.

In particular, I consider the BOBYQA being a very interesting development, as many problems encountered in for example radiation therapy can be formulated as bound constrained problems. BOBYQA has not been available for the .NET platform other than through P/Invoke, so again I decided to port Fortran code to C#. This time I had to rely on the Fortran 77 implementation, since I have not been able to identify any Fortran 90 port of BOBYQA. It took some additional effort, but even BOBYQA is now available as open source in C#. I have denoted this project csbobyqa and made it available on Github. Also written using standard C# constructs, the code should be easily incorporated in any .NET, Silverlight or Windows Phone application.

In the case of BOBYQA, there actually already is an open-source Java implementation available as part of the Apache Commons Math project. The API for this Java class can be found here. 

To confirm that my C# implementation is sufficiently efficient, I have also identified the longest-running unit test (bound-constrained Rosen with varying number of interpolation points) in the Java implementation and implemented the corresponding unit test in the C# unit test library. On my laptop, the C# unit test takes around 15 seconds in each consecutive run, whereas the corresponding unit test on the Java implementation ranges from 15 to 40 seconds. I am not sure why the Java timing varies this much, but it is however encouraging that the C# implementation consistently performs equal to or better than the Java implementation in this case.

To re-iterate, here are the links to my most recent open-source optimization projects:

.NET COBYLA2: https://github.com/cureos/cscobyla

.NET BOBYQA: https://github.com/cureos/csbobyqa

Java COBYLA2: https://github.com/cureos/jcobyla

Good luck with the derivative-free optimization!

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: http://code.google.com/p/csipopt/downloads/list
The source code is available here: https://github.com/cureos/csipopt/tags

A detailed description of the improvements and usage is provided here: https://github.com/cureos/csipopt/wiki/Substantially-extended-API

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!

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!

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,

[DllImport("NativeDll")]
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.

NativeDllHelper.SetupNativeDllFolder("Assets/NativeDll.dll");

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:

[DllImport("NativeDll")]
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.

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.

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?

Networking with Silverlight mdcm

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

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

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

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

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

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

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

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

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

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

Silverlight and a converter for multiple values

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

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

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

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

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

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.

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);

ThreadPool.QueueUserWorkItem(

delegate(object state)

{

...some long-running thread-able process...

((ManualResetEvent)state).Set();

}, handles[i]);

}

WaitHandle.WaitAll(handles);

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.

DICOM and WPF

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.

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.

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!

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.

IPOPT and F#

Theoretically, the C# interface that I developed for IPOPT should make it possible to access IPOPT from all .NET languages. To illustrate this, I recently implemented the basic HS071 example in C# and VB.NET versions.

As a proof-of-concept and as a first attempt to learn F#, I have now also implemented the HS071 example in F#. The F# source code can be found here. This is my first F# program ever, so I am sure it can be substantially improved. Nonetheless, it did compile and efficiently solved the HS071 example. Needless to say, I am pleased to have reached this far :-)

I have not yet packaged the F# example in a regular csipopt release, but the latest revision of the source code can be downloaded via a Subversion client. For further instructions, see this page.