Hi,

I'm looking for a library to handle DICOM files. What I need to do is basically: 

• load DICOM file
• fetch header data and images from it
• add graphics and text annotations
• store modified DICOM files
• Create DICOM files from skratch using my own images + header info.

I've come across clearcanvas, and it seems like this might be just what I'm looking for. I'm creating a WPF application in which I need to display data from DICOM files. What I'd like the library to do is only the mentioned parts surrounding the file handling. I'd like to handle the view part myself, e.g. showing the images by fetching them from the loaded DICOM files.

Does it sound like I'm on the right track by choosing clearcanvas?

Thx in advance for any help or comments.

Cheers!

Thanks for your reply!.

Sounds like we should stay clear of the ImageViewer then. I would assume this means that we shouldn't touch anything under the ClearCanvas.ImageViewer namespace? But this seems to be where the annotations (text and graphics) is placed too. I'm new to DICOM, but as far as I've understood annotations can be stored within the DICOM-file. I would expect to be able to fetch information about this too from the loaded DICOM-file. Can I? 

The ClearCanvas.Dicom namespace and dll sounds like where I should find the core DICOM file handling parts (is it?), but this doesn't seem to be covered in the Framework reference guide. Do you know if there is documentation on this elsewhere? What dll's should I focus on for the dicom file handling only? cc.Dicom.dll and cc.Common.dll? 

About the problems with real-time window leveling in Wpf; is this not a problem with WinForms? You think this is not possible to handle at all - or just not at all using only Wpf? I've heard about posibilities doing such things by writing a shader directly in HSDL for DirectX, but this isn't something I've looked into myself yet..

Cheers,

Stian

As the focus for the SDK is on the ImageViewer - would you still say the library is suitable for only the DICOM file handling part? Is all I need to fetch and modify data from DICOM files isolated in the cc.Dicom.dll? 

I have checked out the repository, so I'll digg into the code and see if I can figure it out.

Thanks for your attention! 

Best regards,

Stian

Hi Stian,

Yes, the toolkit library handles DICOM network communications too.

A short primer on DICOM messages:
A DICOM message (either in-memory like in network communications, or stored on a file system as a file) is really a collection of "attributes". Each "attribute" is essentially a pairing of a "tag" and a "value" - the tag describing the contents of the value in a standard way. Tags are 32-bit unsigned numbers, and they are usually represented in hexadecimal as something like (0010,002F). The standard prescribes, among other things, what kinds of tags can be used in what kinds of messages, what those values contain, what format the values are in, and so on. "IOD"s are the standardized "templates" of what tags may/must/cannot be used and how their contents relate to other tags. (Individual frames of an image are stored, concatenated, in a single pixel data sequence. Since the number of frames is stored separately in another attribute under another tag, you can compute the exact byte offset at which to find a given frame, and the frame length is precisely pixel data byte length divided by number of frames).

Now, the pixel data in any given DICOM message/file uses the tag Pixel Data (7FE0,0010), but its format is governed by other tags. For one thing, the pixel data may or may not be compressed - but the toolkit will handle this, provided you have the appropriate decompressor plugin. When uncompressed, all the pixel data is is simply a byte array - the format of which is determined by other attributes. This is where the toolkit stops handling things because what you do from here can be very implementation specific. Pixel data can be colour or greyscale, and, if greyscale, can additionally be palette-based, 8-bit, 9-bit (or up to 16-bit!)... And what often happens is that some devices have special more efficient ways of handling certain formats (for example, a pure grayscale display adapter may be able to show more than the 256 gray levels that a standard 32-bit ARGB colour display adapter can). A default handling of these display concepts is included in the CC.ImageViewer library, where we translate all the myriad of pixel data formats into a 32-bit ARGB bitmap and render it using GDI+.

What does this all mean for you? Well, it depends on how far you are willing to go in writing your own image handling code. Some people have special hardware of which they wish to take advantage, some have special software, and others will doubtless have their own reasons. But if you're just looking to create a simple, custom viewer (and perhaps especially if you're new to DICOM), all you would need to do is add a few more libraries or include code extracted from CC.ImageViewer to achieve this. There's some "glue" code you'll have to put in to make it work together, as the current ImageViewer assembly was written to favour a GUI (it is our intention to remedy this eventually, possibly by splitting the ImageViewer assembly into two). We've had other people on these forums make viewers using CC.Common+Dicom (our DICOM toolkit) in addition to some extra code from the ImageViewer to achieve a web viewer using Silverlight. You may find the tips on those forum threads very useful if you decide to go this route - just search for "web viewer", "simple viewer", "integrating viewer" using The Power of Google at the very top of this page.

Hope this helps!

Have you made any further progress with your WPF viewer?

I'm embarking on a similar task.