Getting Oriented using the Image Plane Module

 Just before diving into how to get oriented using the DICOM Image Plane Module, so we can put the letters right in our viewer, I want to get equipped with few more latin words so we understand what Radiologists are mumbling. If you're a Doctor, please be patient with us programmers. 

Cuts! Three major cuts we have (or planes): 

Transverse (AKA Axial) divides head from feet

Axial Cut

Sagittall Cut - right between the eyes

Sagittal Cut

and Coronal Cut - the Filet

Coronal Cut

And now that we're done with Anatomy let's do some Geometry. In this post I'm going to start explaining the use of the Image Plane Module. To refresh on Modules read chapter 4 of the DICOM Tutorial. The Image Plane module is part of the CT Image IOD and the MR Image IOD and any other object that have a frame of reference, i.e. that has a spatial coordinates system related to the patient or in other words is a 3D scan of the body.

Lovely whether on the first day of RSNA 2014

[update 24 March 2023: latest HRZ softwarecan be found on HRZ website - www.hrzkit.com]

It's that time of the year. I'm in Chicago again. Luckily, this year the whether is welcoming. We had a lovely two days and only this afternoon the temperatures are starting to drop. Tomorrow it's going to be below zero and hopefully it will get better during the rest of the week.

RSNA is a great opportunity to meet with colleagues and customers and see what's new and where things are going to. Apart from Big Data which is the number one interest right now, The two hot topics this year seems to be Image Sharing and Dose Recording and Monitoring (which I hope to cover on a future post). On the imaging side, I think the focal point is on Ultrasound technology that brings to the table its best up-side, no radiation damages! So Ultrasound has to evolve to the point where more and more anatomies and pathologies can be imaged with this great device. And it defiantly going that way. We're seeing giant steps in breast ultrasound imaging and many other fields will follow as hardware and software will evolve and mature. There's also the question of price and how it affects this technology. Ultrasound device is by 10's, 100's and 1000's less expensive to purchase and to operate compared with CT and MRI.

Image Sharing. Of course it links directly with big data which will also wait for a future post. As an ex-enterpuneer in this field with XRFiles, I'm always curious to see how the business model is built. One of the issues we had with XRFiles, apart from the misfortunate fact that we failed to raise money on it for various miserable reasons, was that patients don't want to see their images or any other medical data unless they really have to.

Video to DICOM (and back)

This is a story of a lost battle. For many years I refused to add MPEG to DICOM functionality in my DICOM SDK. The explanation I gave to myself and to my customers was that storing video in PACS is a bad idea because video streams are usually very big and nobody ever watches them. From an engineering point of view, the size of the video is not so much a matter of disk space but rather a network headache. The way that the DICOM network protocol works, with all the different levels of timeouts and with no failover mechanisms for PDU’s may cause such huge objects to fail over and over when stored and restored. For the clinical point of view, I consulted with Radiologists friends from whom I learned that the driving force behind keeping most of this stuff is not clinical but rather medico legal. These excuses held for some time but eventually, because I’m an engineer but also a businessman, I changed my mind. After all, the customer is always right, and when more and more customers asked to convert video to DICOM, I realized that winning this battle means loosing customers and that’s not something a businessman should do.

Videos were added to DICOM through the mechanism of Transfer Syntax. All together there are currently four (4) video transfer syntaxes for different types of MPEG’s. Here's the list of these transfer syntaxes:

• MPEG2 Main Profile @ Main Level : "1.2.840.10008.1.2.4.100"
• MPEG2 Main Profile @ High Level : "1.2.840.10008.1.2.4.101"
• MPEG-4 AVC/H.264 High Profile / Level 4.1 : "1.2.840.10008.1.2.4.102"
• MPEG-4 AVC/H.264 BD-compatible High Profile / Level 4.1 : "1.2.840.10008.1.2.4.103"

If I have to guess, there will probably be more added in the future as new formats of video gain take over. The embedded document option that was taken for PDF would probably be my choice but I admit that I didn’t investigate the reasons that led to the way the standard went and there may have

Low (Resolution) and Order (of applying transformations)

I'm doing a project that involves taking huge images of 400,000,000 pixels, 20000 X 20000, 700 MB on disk, scaling them down and cutting them into reasonably sized tiles (512x512 pixels).


In this post I want to present how simple code re factoring involving merely changing the order of applying the same transformations rewarded an enormous X20 performance gain.


As a first step, I had to order extra 8GB RAM for my workstation. Once thay have arrived (eBay, 100$, 1 week) I could finally click the input file and display it on windows image preview. Before that, my workstation, initially having only 2GB, hang for 20 minutes every time I accidentally hovered over the file.

The next step was to realize that .NET 2.0 bitmap classes won't do the trick. But than I was surprised to discover that WPF BitmapSource and its sub-classes (System.Windows.Media.Imaging) are capable of handling these very large images so I built the code around them avoiding a native C++ bite-cruncher completely. This was a very good start. It made me very happy.

The third step was to wrap the cropped images in DICOM. This is a subject for a dedicated, yet to come, post about the new multi-frame objects and concatenations. Then came the last two steps that proved out to be challenging.

My initial code looked like this:

1. Use ScaleTransform to down-scale the original image to the required resolution
2. Loop over the down-scaled image on X and Y to do the tiling (The Cut function)
3. Use CroppedBitmap to do the cropping (in the loop)

Here it is: