How can all my pixel data arrays be the same?

[zanguzen]

Hello once more I've gotten a little further in my understanding of DCMTK but again I'm at a roadblock. My goal is to take a DICOM image and obtain the raw pixel data (without all the transformations and manipulations done in order to display them). So, I ended up testing 4 different ways of obtaining pixel data:

1) using dataset and findAndGetUint16Array(DCM_PixelData,buffer) and then printing buffer directly

2) using DicomImage->getInterData()->getData(), casting to a (Uint16*) and printing directly

3) using same method as above, but setting the flag to ignore modality transformation

4) using DicomImage->getOutputData(bitsAllocated) - I did this just to compare to the other methods

In the end, all the methods produced the exact same results using the same image. Values ranged from 0 to about 65000. Regarding the image, it is a CT scan with BitsAllocated = BitsStored = 16 (US) and is 512x512.

My question: Is it possible that all my methods produced the same results, and do any of the results make sense? If not, perhaps someone can offer a suggestion? Thank you so much and sorry for the long read
________
Ca175

[Marco Eichelberg]

My question: Is it possible that all my methods produced the same results, and do any of the results make sense?

This entirely depends on the type of image and the content of the Modality LUT Transformation (i.e. Rescale Slope and Intercept, which you did not mention in your posting). The difference between the four methods is:

• Method 1 (findAndGetUint16Array) gives you the raw pixel data as encoded in the DICOM object. If the image contains overlay data, then image data and overlay data might be mixed in this blob of memory. Also for signed pixel data, the sign bit only extends to the number of bits allocated, not to the size of the pixel cell.
• Method 2 (getInterData()) provides a cleaned-up representation where overlay data is guaranteed not to be mixed with pixel data and where pixel data is always aligned on an 8, 16 or 32 bit boundary (depending on the number of bits stored), with sign bits extended appropriately. In your case you are mis-interpreting this block by casting it to Uint16* - casting to Sint16* would probably be more appropriate. Note that for this method the Modality transformation is applied to the pixel data, i.e. Rescale Slope and Intercept have been applied in the CT case, producing Hounsfield units.
• Method 3 is identical to method 2, but the Rescale Slope and Intercept (or Modality LUT) is ignored, which will make a difference for many kinds of CT images - some vendors encode signed, some encode unsigned, some use a negative rescale intercept, some don't.
• Method 4 yields post-processed data which are guaranteed to be unsigned (shifted into unsigned range).

[zanguzen]

Thank you so much for that informative reply! I'm sorry to ask another question, but do you think you could explain the difference between unsigned and signed in the context of this situation, and how I could go about determining which type to use for either of the methods for any given picture? Any information regarding the usage of sint and uint and which type to use (8,16,etc.) would be very much appreciated! Thanks again!
________
Suzuki Gsx-R400 History

[Jörg Riesmeier]

For method 2, you could e.g. use DiPixel::getRepresentation().