MicroView development continues with additional features being added with each alpha release.  While developing MicroView our primary focus has always been  analytic tool development, especially for microCT applications.  However, we recently took some time to complete the porting of Tkinter widgets found in older versions of MicroView to the newer wx interface that we're sporting in 2.5.0.  Completing this task allows us to re-examine a number of the open-source plugins in MicroView that we think need some attention, and we've started by rethinking volume rendering.  Based on the high-quality GPU-accelerated rendering code base found in recent versions of VTK, this renderer is significantly faster than the original renderer found in MicroView.  We believe it's also easier to use.  These days, GPU-accelerated volume rendering is pretty much a requirement for any visualization package if it wants to be taken seriously, so it's nice to check this off the development list.


If you've got a fairly decent NVidia or ATI GPU, give it a try and let us know your experiences.

Today we turn our attention to the GE Locus Ultra platform in our continuing set of posts on GPU reconstruction:  Integrating a faster GPU reconstruction engine into the GE Locus Ultra requires more careful consideration than some other CT scanners because of the system's complexity and the need for end-to-end integration.  Without this, the scanner cannot maintain it's incredible scan workflow. Keeping this in mind, we've sought out a solution that improves not only the raw reconstruction speed, but the data access rate to the operator console too.  We've blended the original 32-bit-only console software with a 64-bit host computer that runs GPU reconstructions as well as a 64-bit MicroView for visualization purposes.  The workflow is almost indistinguishable from the original, but is faster in almost all aspects, since data is no longer situated on a remote computer, but rather at the operator's console computer.  See the video below for an introduction to the work we're doing in this area.

Another GPU reconstruction progress update day:  See below two line profiles drawn through an aluminum stack phantom, imaged on a CT-120 microCT scanner.  A typical "cupping" artifact, caused by beam hardening, is clearly visible in the left-hand, uncorrected image. The right image demonstrates the advantage of the basic beam hardening correction algorithm integrated into our GPU reconstruction engine.

Click on the image to see a larger version.

Our efforts to integrate our GPU reconstruction engine into different CT scanner platforms continue:  see below a video showing the installation process for the Parallax Innovations GPU engine on an eXplore CT-120 console computer.  The total install time is about 2 minutes, not including the download of the software.  We recommend upgrading to NVidia driver version 295.49, since this driver provides the aforementioned Fermi architecture support such as on the GTX 680 and 690 GPU adapters.

And here's a video comparing CPU vs. GPU CT engines on the same machine:

As before, if you're interested in helping to test this release, don't hesitate to contact us.

We've posted a YouTube video that some of our readers might find interesting:  it's a video showing a side-by-side comparison of CPU vs. GPU for CT conebeam reconstruction - the GPU engine here, is the one that Parallax Innovations has developed.  We compare it against a conventional CPU-based multiprocessor CT FDK reconstruction engine found in GE Locus products.  

The astute reader will realize that perhaps what is really news here is that this reconstruction engine can now be integrated into existing scanning workflow on the Locus and Locus SP platforms.  Drop us a note if you are interested in beta testing this software on 32-bit or 64-bit Windows platforms.

Rumour has it that Nvidia is set to release their Kepler-based GTX 680 on March 22.  With a reported 1536 CUDA cores, and retailing around $560 USD, this card may quickly become the low-cost GPU of choice - certainly at Parallax Innovations HQ.  We've been happy with the cost-effectiveness and performance of the GTX 580 GPU, which we use with our GPU CT conebeam reconstruction software, but at a comparatively small 512 cores we see a hardware upgrade in our not-so-distant future.  More details to be found here.

Thanks to our friends at Endra Inc., we've had an opportunity to involve ourselves in GPU-based algorithm acceleration. This has ended up, for us, being a substantial deep-dive into technologies such as CUDA and OpenCL, but with significant results. The advantages of GPU acceleration over conventional computing are well known, even in the face of impressive improvements in generalized CPU multi-core capabilities in recent years. These advantages are especially true in the medical imaging field, where almost all compute-intensive tasks in the imaging pipeline are embarrassingly parallel. CT reconstruction is one example that we've chosen to focus on recently - we've started by implementing a flexible GPU-accelerated CT reconstruction framework, that can act as both a platform for algorithm design and development, as well as a de facto replacement for legacy CPU-based reconstruction engines. At the moment, it is capable of reconstructing scan data from GE's Locus, eXplore and Ultra CT products - depending on reception, we may choose to port it to more systems. Our reference implementation uses the well-known stock Feldcamp conebeam backprojection algorithm and is written in python for maximum flexibility. It uses pycuda for the heavy lifting. See below reconstruction results from a variety of platforms -- of particular interest, perhaps, is the NVidia GTX 580 results, for sheer speed, and the NVidia GTX 460M, which is running on a laptop. The latter results compare favorably against a 9-computer beowulf cluster, showing just how far GPU technology has come in recent years. The results are preliminary, and will be updated frequently as our recon engine improves and is tested more widely.

(Note: It seems that the interactive graph does not show up, if you are viewing with Internet Explorer. We apologize for that, but for now, you will have to use one of the other browsers, if you wish to see the results).