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:
In order to understand why there are three different methods allowing to access the internal pixel data, it is important to know that until recently DiPixel (and derived classes) was a completely private class, i.e. it was only used for internal purposes. Starting with DCMTK 3.5.4 we've introduced a new method called getInterData() to the interface class DicomImage. However, since the method and the return value are "const" you can only use the const methods of DiPixel.
Coming back to your problem: What do you mean by "using data"? Did you check whether "data" is non-NULL and did you make sure that you're not trying to access pixel values out of the range of the allocated memory block?
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 along with the size of the array. The arrays from DicomImage::getOutputData() and DiPixel::getData() should generally be of same size, right? So how come getOutputData() works and getData() gives me segmentation fault? I'll have to check the array boundaries once more, but I don't think there's anything wrong with them unless the arrays these two methods give really differ in size.
Oh, by the way, the problem only occurs with multi-byte pixels. 8-bit monochrome images are transferred without problems.
You should use DiPixel::getCount() in order to determine the number of pixels stored in the internal array. 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.
Please note that DiPixel::getCount() returns the number of pixels and not the number of bytes! You should use DiPixel::getRepresentation() in order to determine the integer representation of the pixel values (e.g. EPR_Uint8 or EPR_Uint16).
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 define a different bit depth for the rendered data, or am I completely off base here? Then there's of course the case of 12-bit ANI files, but I don't have any of those. What does the internal representation of those look like? Do four 12-bit pixels take up four 16-bit words or only three as in the file?
You should use DiPixel::getRepresentation() in order to determine the integer representation of the pixel values (e.g. EPR_Uint8 or EPR_Uint16).
Thanks! That will certainly help me.
Last edited by mhavu on Mon, 2006-02-13, 15:52, edited 1 time in total.
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.