DICOM @ OFFIS

The data you get from getInterData() is always in your system's native byte order. If you want to know the original byte order of the DICOM file, you can use DcmDataset::getOriginalXfer().

I couldn't get the code to work, so I changed it so that getInterData() is only used for monochrome images, and color images are rendered with getOutputData(). This makes more sense anyway.

Of course, the size of the array returned by DiPixel::getData() and DicomImage::getOutputData() can differ. The latter is used to get rendered pixel data which might have a different depth than the internal representation. Doesn't that happen only in case of EPI_PaletteColor or when I explicitly de...

Thanks for shedding light on the DiPixel design issue. I do have a check for data != NULL , but I haven't taken any measures to make sure that the array I get from getData() is actually the size it should be (is it even possible?). What I'm doing with the data is passing it over to a library routine...

Hi, I'm having a hard time trying to understand the difference between the DiPixel methods getData(), getDataArrayPtr() and getDataPtr(). I am trying to assign a value to const void *data with the following piece of code: const DiPixel *pixeldata = dimg->getInterData(); if (pixeldata != NULL) { data...

Thanks! That did it. Here's a version that supports compressed and color images as well, in case someone is interested: // test program for DicomImage::getInterData() // -- requires DCMTK version 3.5.4 #include "dcmtk/config/osconfig.h" #include "dcmtk/dcmimgle/dcmimage.h" #inclu...

I'm trying to construct a program that uses DicomImage::getInterData() to access the pixel data. However, the getCount() method of the DiPixel object I get from it always seems to return 0. Could someone point me to a working example of how to use the new getInterData() method, please?

Indeed. Thanks. Will the new getInterData method apply the modality LUT or not?

- Marko

I forgot to post an update, but I found out later on that this has actually nothing to do with the DiPluginFormat. The mapping happens with both DicomImage::getOutputData() and DiImage::getOutputData() regardless of whether DiPluginFormat is used or not. I'd still like to know why.

- Marko

What is the number of frames in this case? Single-frame images are not required to have this attribute. What does dcmdump say? Does the file have a Number of frames tag (0028,0008)?

- Marko

Apparently the pixelData doesn't retain its value after all, but changes to NULL even on successful calls. I was mistaken because of a structure like this: const Uint8 *pixeldata8 = NULL; const Uint16 *pixeldata16 = NULL; if (data->findAndGetUint8Array(DCM_PixelData, pixeldata8).bad()) if (data->fin...

No, these particular files use the Little Endian Explicit (1.2.840.10008.1.2.1) Transfer Syntax. I'm at a loss here.

- Marko

DICOM 3.0 files begin with a 128-byte preamble and the ASCII characters 'D', 'I', 'C', 'M'. You might want to take a look at http://support.dcmtk.org/docs/dcmftest.html . If your files are not DICOM part 10 compliant, you might find some of the code at http://paine.wiau.man.ac.uk/pub/doc_vxl/core/vi...

I have the same problem under Mac OS X 10.2.8 and DCMTK 3.5.3: Successful calls to findAndGetUint16Array() or findAndGetUint8Array() don't change the value of pixelData. I have tried with both count == NULL and count == n , but the value of pixelData always remains the same it was before the call - ...

Hi, I use a class derived from DiPluginFormat to act as a bridge between my application and DICOM images. I'm trying to read a bunch of 16-bit signed velocity-encoded MRI images, where the pixel values vary e.g. from -100 to 100. If I read these with DiImage::getOutputData() , the pixel values becom...