Showing posts with label DICOM. Show all posts
Showing posts with label DICOM. Show all posts

Monday, November 17, 2014

Opening DICOM files in the browser

Traditionally, there has been two main trends in the development of applications oriented to end users. The first one has been the most extended for many years: The development of native solutions, tied to a specific platform. The second one came into scene with the adoption of the web and its possibilities related to the creation of web based applications.

When HTML5 was introduced, the possible scenarios for web based applications broadened as never before. Web applications started to appear even in the most unexpected domains.

The medical imaging field did also benefit from this set of new tools and possibilities. Reading and rendering DICOM files was already possible in pre-HTML5 environments, but the new framework just made things much simpler and easier to implement, with no need of any kind of obscure hacks.

In my particular case, I decided, nearly two years ago, to switch from a flash (actionscript) based solution to display medical images to a different set of tools, using just plain HTML and javascript.

I started to work on my own image viewer, while following and getting some ideas from other products, like dwv.

Since this particular application was also oriented to run also on mobile devices, I tried to do my best trying to find an efficient solution. Some of the requirements of the new product were to minimize the amount of necessary memory as well as to maximize the performance of the final product.

One of the decisions to meet the performance goal was to rely on typed arrays, in particular DataView, since we had to read binary file headers containing heterogeneous data.
"Typed Arrays are a relatively recent addition to browsers, born out of the need to have an efficient way to handle binary data in WebGL..."
"DataView is the second type of view and it is meant for handling heterogeneous data. Instead of having an array-like API, the DataView object provides you a get/set API to read and write arbitrary data types at arbitrary byte offsets. DataView works great for reading and writing file headers and other such struct-like data."
Everything seemed perfect. The core language libraries offered us some tools which fit perfectly with the tasks we wanted to do. The fact of using the core tools also matches perfectly some well known principles of programming:

- Do not reinvent the wheel
- Center your efforts in the logic specific to your problem
- This is javascript: Native code has been compiled, while the code typed by anyone has to be interpreted.
- Core libraries in general include highly optimized code.

Sadly these premises ended being completely wrong in this case. All the coding efforts to get a fast code were unsuccessful. The implementation of the DataView class has some kind of weird problem which leads to horrible performance results.

This problem was noticed and reported longtime ago, but at the present day the problem still persists.

I have done some performance tests in a range of different machines. The code using DataView resulted to be extremely slow when compared with writing your own functions for raw data reading. Results are between 20x and 50x slower, depending on the test platform. Relying on DataView in your code is a nonsense given the current implementation problems. I do not catch the point of this class given such a bad results.

DataView performs between 20x and 50x slower than raw reading on a modern computer
So, the final thought, if you pretend to get performance on your javascript code, avoid using the  DataView javascript object. Otherwise you will end up loosing a big amount of your precious time writing useless code.

Thursday, February 19, 2009

Multiframe DICOM to Flash video

Following with the series of articles dealing with web based visualization of DICOM images, we are going to ilustrate a way of viewing multiframe ultrasound DICOM images.

As in the previous article, we have used just open source software for every action or transformation carried out.

This solution appeared in one ocasion when we were looking for a quick solution to share some cardiology studies among cardiologists. We wanted a solution with minimal software requirements, and fully multiplatform, in order to ease and promote the migration to open source workstations in public healthcare organizations.

One of the goals was to preserve the original quality of the contents, so we should preserve the original frame rate of the sequence as well as the original image quality (lossless transformations).



1.- The first step is to extract individual frames of the multiframe object. This step can be done using the dcmtk tools.

$ dcmj2pnm +Fa +ob multiframe.dcm /tmp/multiframe_


Use the +o modifier to indicate the output format. +ob to generate BMP, +on to generate PNG (You can test other available formats, but be careful to avoid loosy formats, such as Jpeg)

2.- Optional step: Obtain the frame-rate if you want to maintain the original values. I am not sure if the video format used (.flv) has a maximum allowed frame rate (59.94 is mentioned in some sites). O the other side, you will need a powerfull machine if you want to display the output at such high framerates. Anyway, you can alway create a slow motion version of the original content using lower framerates. If you choose this option, you must inform the user about the variation with respect to the original content.

$ dcmdump +P "0018,0040" multiframe.dcm


3.- Once you have done the extraction of the frames, you should convert the set of images to the desired video format (.flv in this example). We have tested with ffmpeg and mencoder. Both of them have their own advantages and limitations. Be sure to have the necessary codecs (flv) installed on your system.

Example 1: Assuming a framerate of 30 fps, bmp frames, and maintaining the original size (800x564 in our case).

$ ffmpeg -r 30 -i /tmp/multiframe_.%d.bmp -f flv -s 800x564 -sameq -an -r 30 multiframe.flv


Example 2: If you prefer to try with mencoder (png frames, 30 fps):
$ mencoder "mf:///tmp/multiframe_.%d.png" -mf fps=30:type=png -ovc lavc -lavcopts vcodec=flv -o multiframe.flv


Below, there is just an illustrative video, but you can see the full quality DICOM multiframe ultrasound video.

Saturday, February 14, 2009

Flash DICOM viewer

Some days ago, I passed the mark of seven years working in the field of healthcare related software. Due to the fact of working in this area, I have had the opportunity to learn about some topics and concepts that otherwise could remain just unknown for me. One of the topics that I find of particular interest is that related to medical imaging.

There has been a huge work during many years in order to create a standard for medical imaging. The result of such work is DICOM. At the begining most manufacturers preferred to tie their clients by the use of propietary and closed formats. Fortunately, in the last years most manufactures have chosen to follow the standards (with more or less success) opening a very interesting field for software development related to medical imaging.

One of the difficulties when dealing with DICOM imaging is the fact of having many differences compared to other image formats. In general, we can not use tools intended for other kind of images (such as those coming from digital cameras) to work with DICOM medical images.

The manufacturers of hardware equipment for medical imaging acquisition do usually provide their own diagnostic stations with specialized software, so the doctor (radiologist, cardiologist) can interpret the images.

Apart from the main diagnostics stage, it is often interesting to distribute images along with the medical report. If a doctor has derived a patient to radiology, the doctor would appreciate the inform with the results being attached to some key images. Given the fact that the medical data is evolving in order to replace the traditional paper by electronic reports, it becomes a necessity to provide remote access to medical imaging.

So, we can distinguish two kind of viewers: Diagnostic viewers, intended for those practicians that should emit a diagnostics from the examination of the image, and simplified viewers, intended just to allow the possibility of viewing the relevant imaging data, acting as a complement to the medical report.



If we want to achieve a fast and efficient deployment of an imaging viewing solution, we must consider a web based DICOM viewer. Since we are not dealing with simple imaging formats, we must consider environments able to act as RIAs (Rich Internet Applications), and that narrows a lot the available options.

For the development of a web based DICOM viewer, we can consider the following frameworks:
  1. DHTML: javascript, DOM, ...
  2. ActiveX
  3. Silverlight / Moonlight
  4. Java: In the form of Java Applet (browser embedded), Java Web Start applications or the new Java FX platform.
  5. Flash based viewer
Let us see the advantages and limitations of every possible option:
  1. The first option may have limitations in order to manage and being able to perform some tasks in DICOM images, such as lightning or darkening images.
  2. The second option (still adopted by many manufactures) has not ever been considered in our case, since one of the goals is to achieve a real multiplatform solution. That is a real must if we consider the fact that many public administrations and healthcare departments are migrating their systems to Linux based stations.
  3. The third one is something that deserves to be tested. If it is a real multiplatform environment, that can be an option for development of a web DICOM viewer in the form of a RIA.
  4. The option number four sounds really good. In fact a Java Web Start DICOM viewer would be a killer app in this field.
  5. The fifth option sounds good, but Flash (Actionscript) has many differences compared to Java: May be it is more limited as a programming language, but has many possibilities regarding the user interface and to present information to the user. We have chosen to start working in Flash, just to test what we can achieve.
Our first development was Stratos-viewer, a simple flash based DICOM viewer, but powerful enough in the cases where no advanced utilities were necessary. An online demo of the viewer is available.



Addendum (2009/02/18):
References to other flash based DICOM viewers: