Getting started question.

[somed]

Hello,

Posted a question couple days ago; it never showed up. Not sure whether it got moderated or genuinely did not reach your servers. Trying one more time...

If someone could share with me a win32/MSVC one-liner for rendering the dicom image using the pixel data returned by DicomImage::getOutputData(), I would really, REALLY appreciate it! The 'sample' code that comes with this toolkit simply says...

Code: Select all

    
    if (i_pixelData != NULL)
    {
        /* do something useful with the pixel data */
    }

, which I've been trying to... but obviously cannot make further progress!

My image is a monochrome MR image. One thing that I'm noticing is that even though my image dimensions (as reported by getWidth/Height() functions) are 224x256, the getOutputDataSize() function is returning a number that is twice as big. Does it mean that bits per pixel for this image is 2 bytes? (I was assuming bits per pixel is 8 bits because the sample code tends to say it's so for all monochrome images. I'm also assuming number of color planes for win32 is 1!)

I'll figure out the rest if someone could kindly just get me started.

Thanks much,
SomeDeveloper.

[Michael Onken]

Hi,

probably your MR image uses more than 8 bits per Pixel to store it's color value. If you dump your file using dcmdump, look at the value of attribute "Bits Stored". So if there are more than 8 bits stored, the DicomImage class will return 16 bit per pixel.

There is one exception:
The DicomImage class analyzes the number of colors found in the image. If it finds out, that there is the possibility to store all colors in 8 bit values, you get 8 bit output data returned.

Jörg might correct me, if I'm wrong here

Regards,
Michael

[Jörg Riesmeier]

Michael, the example explicitly specifies that getOutputData() should always return 8 bit data.

SomeDeveloper (btw, nice realname), did you specify the same bit depth for getOutputDataSize(), i.e. in your case 8? If not, that would explain the deviation.

[somed]

Jorg and Michael, thanks for responding.

1. Indeed dcmdump shows Bits Stored/Allocated to be US 12/16.

2. I still don't fully understand what needs to be done to render an image. Since I'm not creating an external copy of the pixel data, I see no need for calling getOutputDataSize(). Here's what I do...

I first cache the reference to the internal pixel data...

Code: Select all

m_di = new DicomImage("dicom.img");
if (m_di != NULL)
{
	if (m_di->getStatus() == EIS_Normal)
	{
		if (m_di->isMonochrome())
		{
			m_di->setMinMaxWindow();
			m_pixels = (Uint8 *)(m_di->getOutputData(8 /* bits */));
			if (m_pixels != NULL)
			{
				/* just cache m_pixels for use later */
			}
		}
	}
}

and then create the bitmap at drawing time as follows (using MFC/win32):

Code: Select all

// a. Create compatible dc, bitmap, etc...

// b.
CBitmap bmp;
bmp.CreateBitmap(
	m_di->getWidth(), 
	m_di->getHeight(), 
	1
	8
	m_pixels);

// c.
// BitBlt source dc to dest dc...

Some Developer.
(For lack of adequate courage, this is as real my name gets... hope kind readers would give a damn or less, )

[Jörg Riesmeier]

Since I'm not creating an external copy of the pixel data, I see no need for calling getOutputDataSize().

You don't need to use this function. The main purpose of this function is to determine the size of a memory block that is allocated externally, e.g. in order to use the second variant of getOutputData(). This function expects a "void *" as the first parameter and, therefore, allows to reuse the memory block multiple times, e.g. in a loop.

I first cache the reference to the internal pixel data...

Please note that the reference is only valid as long as the rendered pixel data (output data) is stored internally, e.g. until you call getOutputData() again.

[somed]

You don't need to use this function...
Please note that the reference is only valid as long as ...

Yes, fully understand both points.

1. Given that 12 bits are stored within 16 bits allocated in the file per pixel, should I use 8, 12, or 16 when calling getOutputData()? To my graphics draw function that requires bits per pixel (and, obviously, pixel datasource as well), should I pass 8, 12, 16?

2. When I tried all 3x3 = 9 combinations of the above for getOutputData() and BitBlt(), I found that Bitmap creation failed only for the cases:
getOutputData( 8 ) with
BitBlt(... 12) or BitBlt(...16)
. However, in neither of the 9 cases did the bitmap actually get rendered!

What is it that I'm doing wrong?

Also, how do I programmatically know from DicomImage what its bits/pixel stored/allocated values are... so that I know what to pass getOutputData()?

[Jörg Riesmeier]

I guess that your output device does not support more than 8 bits per sample, i.e. it would be safe to always pass '8' to DicomImage::getOutputData().

Btw, I don't know what CBitmap expects as pixel data format, but when I was displaying a DICOM image from a Windows program about 10 years ago I used the following functions: DicomImage::createWindowsDIB(), CreateDIBitmap() and BitBlt().