MRIdb: Image management, in a virtual machine

MRIdb is an interesting new application for storing and managing images, from Imperial College London. Building upon the stalwart dcm4chee image store, it combines the functionality of a PACS with study-level management and access control, administered through a web interface. Also bundled is the PostgreSQL database for storing images and open source applications for viewing and converting images. MRIdb itself is the Java-based management application, and is the primary means of interaction with the system. Through this interface you log in (authentication with LDAP is supported), view or download images, and manage related images by grouping them into projects.

One unique aspect of this project is its optional deployment as a preconfigured virtual machine. This is a single downloaded file which is run within the VirtualBox application, a free application from Oracle that runs on any platform.
Oracle_VM_VirtualBox_Manager The virtual machine contains an entire CentOS Linux operating system, and all the MRIdb components, all configured and already running. Once started, the virtual machine (which in this case has the IP address is accessible in a number of ways.

Firstly, the MRIdb application is accessed by browser through the default HTTP port of the VM. Here’s where you can create projects and associate them with individual scans, a convenient means of managing large numbers of studies, and a useful research-oriented feature not provided by traditional clinical PACS systems.
Features found in most PACS clients, such as search by various fields, are also available. Image viewing is provided in two ways, by launching an instance of the ImageJ viewer, or through the in-browser Weasis viewer.

Then, to communicate with MRIdb using DICOM standard protocols, the dcm4chee instance provides full PACS functionality. This is accessed using standard DICOM tools, such as a network-capable image viewer, another PACS, or any DICOM-compliant tools. For security, the default dcm4chee instance requires that remote AE titles be configured in order to send or receive studies. The server uses the standard port 11112 and AE Title ‘DCM4CHEE’, as shown in this example of sending an image to the store:

Alternatively, the dcm4chee instance has its own web interface, running on its standard port of 8080. Through this you can search the PACS directly, and configure your remote AE entities. It’s a pretty dense interface, but this is a commercial grade application.

Finally, you can SSH into the virtual machine itself. Always a kick to find another machine running within your computer. Log in to it, and you have a full Linux environment to explore the MRIdb components, which start running when the VM is initialized.

In this test, the virtual machine launched quickly and with no intervention required, consuming less than 1 GB of memory including the VirtualBox overhead. Routine tasks can be accomplished through the MRIdb browser interface, though steps specific to dcm4chee require a visit to its separate interface. Deploying from source code was less successful: as is common with complex Linux installations, there are many platform-dependent details that can trip up the installation and configuration scripts. Perhaps due to the deviation from CentOS as the test platform (Debian and Open SUSE were available), the packages did not install automatically. This is par for the course with complex multi-package installations and most people familiar enough with Linux to attempt the source-based path would be able to resolve the incompatibilities. The final stumbles were encountered when launching the in-browser viewers, and were caused not by the application, but by the delightful Java version/security/update maze we all love to navigate.
MRIdb is built on a good number of solid free and open-source projects. The imaging tasks are performed by some old friends: from come the dcm4chee image server, dcm4che2 toolkit and Weasis web viewer, there is the DCMTK DICOM toolkit from OFFIS, and Erik Nolf’s XMedCon for image format conversion. Other projectss provide the non image-related infrastructure: (VirtualBox virtualization, PostgreSQL database, JBoss application server, Play web framework).

MRIdb is a useful program for those managing imaging studies. As supplied, it runs with just a few clicks, and has full control for those wishing to get more involved in the technical details. The implementation as a fully-configured virtual machine makes this of particular interest for those who’ve never run their own image store. Give it a try: in five minutes you can be sending images to and from your very own PACS!

Orthanc: A different approach to a PACS

Orthanc is an interesting new program from Sébastien Jodogne, at the CHU de Liège, in Belgium.  Described as ‘An open-source, lightweight, RESTful DICOM server’, it’s a fully self-contained mini PACS that you can download and run immediately.  It’s provided in source code form, and as pre-compiled Windows and Linux (Debian and Fedora) binaries. The database for storing images (SQLite) is built in to the application and is easily configured.

There are several ways you can talk to Orthanc: as a DICOM server, as a web server, and through its API. Download it and fire it up, and you have a DICOM server capable of sending and receiving images using the standard DICOM protocol. Command line tools like those supplied by DCMTK are ideal for this, as are any of the PACS-capable graphical programs. Additionally, it has Orthanc Explorer, a built-in web server (or you can run it behind an Apache server) for administration and showing image previews. This gives a nice responsive web interface to the program, including drag-and-drop DICOM image upload. By default its HTTP server is on port 8042, while port 4242 is the DICOM server using the AE Title ‘ORTHANC’, all of which are configurable.

What really sets this program apart is its ‘RESTful API’, a means of connecting with the image server by using standard web protocols and tools.  This allows Orthanc to be accessed through Web connections from anywhere, and without regard to the platform or language used in the originating program. REST APIs are characterised in part by the use of URIs to locate and access resources, which in this case include patients, studies, and images.  Orthanc returns textual data in the form of JSON files, a widely-used lightweight file format, while images are returned in the web-standard PNG format.  These technologies are familiar to many developers, and are more approachable than tackling the full DICOM networking protocol.

Here’s an example (many more are given in the Orthanc Cookbook) of accessing studies through their URL.  I have a couple of studies for one patient stored in my Orthanc instance, and I want to locate images by running through the DICOM levels of Patient – Study – Series – Instance. Orthanc is listening on port 8042 and a full list of the patients in the database is obtained from appending ‘/patients’ to the URL:

Appending the patient identifier returns the details for this patient:

In a similar way, the studies and series details can be obtained. Each series returns a list of its instances (images), and the details of each of these can be retrieved as a JSON file:

At the instance level, the image itself can be retrieved as a PNG file by appending ‘/file’ to the instance’s URL. Instance details are available as a list of tag-value pairs (‘/tags’), or just as the value of an individual tag (‘/content/0008-0060′ returns the modality).

Functions such as anonymizing or altering the instance headers can also be accessed through standard REST calls. Here are a couple of the supplied examples (the URI has been shortened for clarity). In the second example, an entire series is edited, resulting in the creation of a new series within the Orthanc store. A JSON message is returned with the location of the new series containing the edited information.

Issuing commands at the command line is useful for design, debugging and experimental work, but the real power of this approach comes from driving the commands from a scripting language. Python examples are supplied for some sample applications such as uploading and downloading images, which can be done in a few lines of code. Here’s the basics of the Python sample script to download an copy of all anonymized studies, where the ‘RestToolbox’ methods are short functions that do what they say.

Short and readable, and all the DICOM stuff is done by the Orthanc server, allowing you to concentrate on the functionality. There are other example programs in C++ showing how to use the library by itself or with the VTK toolkit for image display.

Orthanc lives in two worlds.  On the one hand, it supports the traditional DICOM transport protocol, and can communicate with standard networked DICOM programs. But while the DICOM standard has been around for decades, Orthanc comes from the modern and rapidly-changing era of web services, and its developers have adopted a number of web technologies to medical image transport. Maybe if DICOM transport is like email, Orthanc’s REST API is like Twitter: it’s fast and light, and gets the essentials of the message across.  It can’t do everything its heavyweight predecessor can do, but it does it more simply.

Orthanc is an interesting and novel imaging application, and is well worth the time taken to download and explore its capabilities.

New Releases: October 2012

Let’s have a quick look at some of the software projects that have recently released new versions.

Mango is a do-it-all program from the Research Imaging Institute at the University of Texas.  It’s easy to use for beginners, but offers great powers to advanced users, particularly those in the brain sciences.  It’s written in Java so it runs on any OS, and comes with platform-specific installers.  It has developer tools available, and a range of useful plugin modules. And let’s not forget the variant that displays DICOM images on a browser (webMango) and the iPad app, iMango (though it’s not free software).

For introductory users, it can quickly let you view images in DICOM or a half-dozen other formats.  But there’s a lot more functionality built in to the program, and with its  plugin architecture, it can be expanded to perform a very wide range of tasks.  While suitable for general purpose image viewing and analysis, there’s an emphasis on neuro imaging including support for file formats specific for that field: AFNI, NIFTI (use the Search page of this site and you’ll find 9 programs that support the former and 20 for the latter), also FSL and BrainVisa (which we’ve not yet got around to categorizing, ahem).

Advanced users will find useful features including a comprehensive package of ROI operations, image co-registration and overlays, statistical analysis, and image processing.  Plugins providing advanced neuro analysis tools and support for additional file formats are installed as needed from a library modules offered from the Mango site: adding and running these is straight-forward.  For programmers, there’s good support.  A package of developer tools can be downloaded and the API for developing plugins is well-documented.

Mango is a thriving project with much to offer everyone from the casual user to neuroscientist.

Nanodicom is one for the programmers.  It’s a PHP toolkit for reading and manipulating DICOM files (no flashy screen caps here sorry).    It’s one of very few (n=1) DICOM projects written entirely in PHP and is optimised for speed and a small memory footprint.  There’s a core class providing functions to read and modify the file header, as well as operations upon the pixel data.  Several ready-made sample applications are useful in their own right as well as providing reference implementations: there are programs provided for dumping, modifying or anonymizing the file header.

The package is well-supported, with extensive documentation, example programs, sample data, and a comprehensive test suite provided.  Since it’s hosted on GitHub, it’s available for developers to download, modify, and contribute to.

While Nanodicom does not handle DICOM networking, there is an existing class (not yet added to I Do Imaging) called DICOM PHP Class, which does just that.  It differs from NanoDicom in that it does its heavy DICOM work with the DCMTK toolkit.

Nanodicom is developed by Nano Documet, and the current release is version 1.3.

On the subject of DICOM libraries for interpreted languages, Ruby Dicom is well worth a look.  It supports reading, editing and writing file headers as well as network operations: querying, retrieving and sending files.  In conjunction with other Ruby packages, image data operations are also possible.

It’s written by Christoffer Lervåg who’s put out a steady stream of updates since the project’s inception in 2008.  The package is distributed in source form and as a Ruby gem  through RubyForge, allowing one-line installation.  The program is of course backed by a comprehensive site including tutorials, one of which walks you through creating a DICOM viewer with GUI controls in a few pages of code, using the Qt cross-platform toolkit.  Another tutorial uses the Rails framework to quickly build a web app to display DICOM header information on a browser.  Ruby Dicom is a cool application of a popular language with a devoted following.

Amide has been a major force in imaging software for a long time.  Developed and actively maintained  by Andreas Loening, it is by its own description a “Medical Imaging Data Examiner”.  As such, it’s strong on technical features and low-level operations on a broad range of file formats.  It’s written using the GTK+ cross-platform GUI toolkit which, together with good software design and a lot of hard work, means it will run on Windows and Windows computers as well as Linux.  There are too many features to go into here, but they include co-registering and fusing multiple data sets, volumetric rendering, 3-D ROIs, persistent storage of studies, and more.

Amide’s a good example of the collaborative nature of the open source imaging community.  The author uses (and contributes to) a variety of software packages, some specific to medical imaging (Medcon for conversions, DCMTK for DICOM support) and some more general (VolPack, FFMPEG, GSL).

Amide is notable in its support of the nuclear medicine formats ECAT and Interfile – strangers to those outside the field (just about everyone) but critical to those of us whose day jobs make possible the (admittedly spotty) maintenance of I Do Imaging.    Check it out, especially if you’re of a technical nature.

Medcon, together with its X Windows GUI xmedcon, is a medical image powerhouse for power users.  A product of Erik Nolf at Ghent University, it’s a format conversion program that supports a very wide range of file formats, with particular strengths in nuclear medicine but supporting all the widely-used formats.  It can work down to the voxel level to reslice image volumes along any axis and resample at varying resolutions.  Medcon can convert individual image slices to and from an image volume, convert the image value encoding, change colour maps, normalise values, and perform a number of other low-level operations.

Medcon has been in steady development for over 10 years, issuing dozens of releases, all well-documented and with careful attribution of fixes and feature requests.  It is particularly powerful when used from the command line or called from scripts, allowing full automation of complex repetitive actions.  There are distributions available for numerous Linux variants as well as the Macintosh and Windows platforms, and full source code (together with cross-platform make files) is provided under the (L)GPL license.  There’s not much he’s left out here!  (X)Medcon is a nice example of a defined problem (conversion of nuclear medicine file formats) being executed really well.