Looking for light DICOM lib to use w/JUCE


#1

Hi,

Can anyone recommend a reasonable DICOM library that can be used with JUCE? We only need basic functionality, like displaying (resizing) a preview image, maybe some basic mirror / rotation and (auto) window / level features. I guess DICOM send may also be needed to pass the image on, if we need to. Don’t want to reinvent the wheel, that’s all.

Thanks!


#2

DCMTK.

http://dicom.offis.de/

It’s a really good set of tools, and the API is generally easy to work with. Win/OSX/Linux support, all of which works fine with JUCE.

The only trouble I occasionally run into is when JUCE and DCMTK include the same toolkits, such as zlib.

DCMTK’s image format is (of course) not the same as JUCE’s, so you’ll need to map their images to a JUCE:Image, but DCTMK allows you to grab DICOM pixel data after modality LUTs have been applied, but before any kind of windowing has been performed. So, you can easily take a the int16s and render them as greyscales (or temp maps if that’s your bag) on a JUCE Image canvas.


#3

A few example screenshots of my app, if you care:

http://www.adam.adbe.org/abras1.JPG

http://www.adam.adbe.org/abras2.JPG

The first shows zooming, windowing, and measuring, the second, shows some header information taken from the DICOM (PID has been removed from the image of course).


#4

Thanks, valley! Yes, this one looks very comprehensive.
I’ll definitely check it out.


#5

[quote=“valley”]A few example screenshots of my app, if you care:

http://www.adam.adbe.org/abras1.JPG

http://www.adam.adbe.org/abras2.JPG

The first shows zooming, windowing, and measuring, the second, shows some header information taken from the DICOM (PID has been removed from the image of course).[/quote]

Cool stuff - I hope it saves many lives!


#6

Thanks again, valley,

dcmtk works for the most part. I do have problems with some specific dicom formats, though (unable to render). Here’s a quick and dirty preview window that took a few minutes to put together - after I figured out how to compile the stuff :slight_smile: The patient is frozen pork, so hopefully displaying the patient ID is not a big problem here.


#7

[quote=“spiderman”]Thanks again, valley,

dcmtk works for the most part. I do have problems with some specific dicom formats, though (unable to render).
[/quote]

That’s quite unusual. Contact the developers on the support forum. They’re busy guys and you wont get a ton of feedback, but they’re still very helpful, given the complexity of the subject, and the fact that DCMTK is free. If there’s limitations in DCMTK they seem to be fairly aggressive about resolving them too.

In general, most rendering issues come down to not always picking the right part of the toolkit for the given problem.

I personally don’t use any of their rendering code, because I need a lot of access to raw pixel values. It’s essential to me to know the hounsfield values in CT images, for example. Typically radiologists don’t want to bothered with that kind of thing, and simply want a correctly scaled image suitable for viewing. Most of DCMTK is set-up primarily for the purpose of getting data in a standard form as quickly as possible. Fortunately, DCMTK does allow you to get pixel values in a modality corrected form, before display transform LUTs have been applied. This means you can pretty much get what ever you need out of the image, but don’t need to worry about inverse monochrome, or slope/intercept style issues.

[quote]
Here’s a quick and dirty preview window that took a few minutes to put together - after I figured out how to compile the stuff :slight_smile: [/quote]

Good stuff!

I personally love the combination of JUCE and DCMTK. I’m pretty sure they’ll work well for you too.


#8

BTW, the .dcm files I had problem with are okay now. They were lossless jpeg images and all I had to do was register the jpeg decoder.