X-ray Tomography Control

The School of Geosciences has an X-ray computed tomography (CT) scanner installed within one of its basement laboratories, which researchers within the school have assembled from individual components. The scanner consists of a number of independent elements, including an X-ray tube and corresponding camera, air table for holding and rotating samples and PCs for controlling the X-ray tube and handling image capture from the camera. Custom software to control the image capture process was written by a PhD student, and this software was driven by Testpoint (which also controls the table on which the sample sits).


The original implementation was based around a Windows 98 installation, and while this solution was rock-solid, time taken for the image capture process was significantly longer than ideal, at around 6 seconds per image (with a 0.5-1.5 second exposure time). Additionally, with the existing high resolution camera displaying worsening artefacts from X-ray exposure, a more modern camera was purchased and required to be integrated into the image capture process.

CT SCreenshot

IS Apps successfully bid on the work to replace the existing PC and software, as an alternative to either purchasing a complete pre-assembled solution, or outsourcing the work to a third party. Limitations of driver availability for the hardware used meant Windows XP was the most recent OS which was suitable for the task, although fortunately this posed relatively few difficulties bar sourcing a new license!

A new C++ application was developed, using the Microsoft Foundation Class library to provide the user interface. C++ was chosen as both the original image capture application, and the majority of worked examples for the hardware, were written in C++. The desire to improve performance, and memory usage of the image capture process, also indicated towards C++ for the fine-grain control the language provides.

The interface was streamlined to eliminate unused options, the image processing options were expanded to clarify the available options, and a control added to allow the camera hardware to be chosen. The image capture process itself was encapsulated within a new dialog window which is displayed when the process is running, and contains the progress indicators and status display (start time, estimated end time, number of images captured, etc.).

CT SCreenshot 2To enable development without requiring constant access to the hardware, support for “dummy” camera and table hardware was added, where the application emulates the relevant hardware internally. As the components operate independently of each other, the user interface, table and camera all operate on individual threads within the application, ensuring that interaction with any of these three elements is processed as close to real time as possible. Communication within the elements is handled primarily via MFC message pumps from the hardware threads to the UI thread, with semaphores and events used to pass data down to the hardware threads where required (most hardware threads as given a fixed task to complete, and are expected to return only when it has finished).

This revised coupling of the hardware control, in combination with reduction in how frequently the cameras require to be re-initialised during an image capture, reduced image capture overheads to a fraction of their previous times. Early estimates are around a tripling in performance, with actual exposure time taken by the camera now dominating time taken.

An example of the resulting rendered “slices” of a section of meteorite, after reconstruction in Octopus, is shown below:


Obviously we’re very pleased with the project results, and hope this provides a clear illustration of the level of work IS Apps is capable of, as well as the cost benefits of in-sourcing of applications.



Testing Times in the SSP

For a recent project we needed to establish some base line timings using selenium and the process had to be automated.  We solved this by combining Firebug and Selenium and producing HAR files.

This article outlines combing firebug and netexport which gives you a very handy export for analysing all of your timings.  Your can then use the HAR viewer to have a look and see what is going on.

Another approach which we tried was http://assertselenium.com/2012/11/02/performance-data-collection-using-browsermob-proxy-and-selenium/ – using a REST based proxy tool to record the har files.  This means you don’t have to use the firebug part so could be used cross browser.

We also are having a look at a couple of javascript based testing tools which are well worth a look:

SITS upgraded to 8.7.0

We have upgraded our SITS system to the version 8.7.0 over the last weekend. This was a double upgrade from version 8.6.0 to 8.6.1 and then from 8.6.1 to 8.7.0.

The upgrade process went well. It started from 1pm on Friday 28th Feb, and completed by Saturday evening. This allowed the technical technical tests to start from Sunday morning, and by the 4pm Sunday afternoon, the system was ready and re-opened to the public.


Creating a skeleton Spring MVC Portlet

If you’re needing to create a new JSR-286 portlet, the Apereo Foundation (formerly JASIG), have provided a Maven Archetype for the creation of a skeleton portlet.

Essentially you can run the following command:

mvn archetype:generate -DarchetypeGroupId=org.jasig.portlet.archetype -DarchetypeArtifactId=jsr286-archetype

It will ask you for the group, artefact and package information, and will automatically create a skeleton Spring MVC Portlet for you.

See the using the uMobile Portlet Archetype article for full details.


Welcome!  We have created this blog as a place for members of Development Services to share information, experience and thoughts relating to our work.  Although we use IM for sharing useful links and ideas, sometimes we want to write more than can fit in the space of a chat thread, and to keep the post for longer than the transient nature of an IM exchange.

That’s what this blog is for.  It may contain anything that people think may be interesting: discussions of particular techniques; snippets of useful code; links to and comments on interesting articles; or anything else that seems appropriate.

Anything posted here will be publically readable, so anyone posting should bear this in mind. Common sense applies.  The University has guidelines relating to the use of social media (see the link below).

Development Services

UoE Social Media Guidelines