Secondary capture image: which image information object to use?

[Dirk_Mirk]

I was wondering: if you save your pixeldata into a DICOM file format like for example "Multi-frame Grayscale Word SC", you are obliged to use :

- Samples per Pixel (0028,0002) shall be 1
- Photometric Interpretation (0028,0004) shall be MONOCHROME2
- Bits Allocated (0028,0100) shall be 16
- Bits Stored (0028,0101) shall be greater than or equal to 9 and less than or equal to 16
- High Bit (0028,0102) shall be one less than Bits Stored (0028,0101)
- Pixel Representation (0028,0103) shall be 0
- Planar Configuration (0028,0006) shall not be present

So this means you can pass at maximum a 16-bit pixel data array to the dataset, right?

So what to do if you have a 24 or 32 bit grayscale image? Does one has to use the "Multi-frame True Color SC (RGB)" then in order not to have any image quality loss?

I'm a bit confused since the input is more then 16-bit, but the color range is only grayscale, so not really RGB.

Or am I making a mistake in some of my assumptions here?

Thanks.

[Marco Eichelberg]

Correct: if you save an image as "Multi-frame Grayscale Word SC", the number of bits per pixel must be between 9 and 16. The "Multiframe Color SC" SOP classes do not allow you to store grayscale images, so this is not an option for you as well. If you have a grayscale image with more than 16 bits/pixel, the only appropriate SOP class is the "old" Secondary Capture SOP class which supports any bit depth and any color model. However, there are probably not too many applications on the market that would support something like a 32 bit/sample image anyway (our toolkit does, however).

[Dirk_Mirk]

Ok, thanks. But since the image is in fact an Xray coming from a CCD chip, I was wondering if it would also be OK to use the "Digital X-Ray image object" to store the gray values, since this one is not limited in bit depth if I'm correct?

Only thing is that the information for the Pixel Data for the DICOM image is not coming directly from the scanner, but that the scanner pushes this into a device context on screen, where we can retrieve the pixel data from...
So normally this should be a secondary image capture object.... But then I'm running into the problem that the image itself is 32-bit, and I loose too much grey values, when exported into a 16-bit array... So the only thing left for me to do is use this "old" secondary capture format you spoke about?

Please help

Thanks.

[Dirk_Mirk]

Just a friendly bump of the topic, since I'm still in need of an answer

Thanks.

[guy]

If you look the function of the DCMTK SaveDicomImage, it saves a grayscale image bitmap 1 byte per pixel as a Dicom Secondary Capture.

Like you, I was beginning to use Multi-Frame Secondary Capture Image IOD because it's said in the norme that the usage of SC Image IOD (1 single frame) is deprecated, but DCMTK uses this IOD and this IOD was not retired because a lot of personns still use it, so I use it too because I have only single frame, so try to use this IOD, I think it supports 32 bits / pixel, no ?

see A.8, PS3

[Dirk_Mirk]

Yes, you are right, it supports also 32-bit values:

A.8.1.1 SC Image IOD Description
The Secondary Capture (SC) Image Information Object Definition (IOD) specifies single-frame
images that are converted from a non-DICOM format to a modality independent DICOM format,
without any constraints on pixel data format.

Thanks. But the problem seems to be indeed that not all DICOM viewers are able to process 32-bit images, as Marco already mentioned. So I have to use 8 bits with 3 samples per pixel, no?

[Marco Eichelberg]

DX images are also limited to 16 bits/pixel, so as I said, the only way out is the traditional Secondary Capture object. And no, you cannot save 8 bits with 3 samples per pixel, unless you have an RGB or YCbCr color image. If your image is monochrome, the only portable way of encoding the image is to use the MONOCHROME1 or MONOCHROME2 photometric interpretation, SamplesPerPixel=1 and, in your case BitsStored=BitsAllocated=32. This may confuse viewers, but then there is no way anyway to make them digest a 32 bits/pixel image, you would have to provide a down-scaled 16 bit version for these viewers. One (very proprietary) way out would be to only save the 16 most significant bits of each pixel in the "official" PixelData attribute and to save the 16 LSB bits of each pixel in a private attribute. That, however, would prevent anyone except your own application from ever utilizing the full 32 bit resolution.

[bbishara]

The goal is to create a DICOM file based on a 2d array that will contain the
8bit unsigned #. So a simple image can be created as a test such as a line by
> having a certain row of the array containing one number while the rest of the
> 2d array is filled with a different number. How do i do that?

I have visual c++ and the dcmpstat dviface.cc file open but I don't know what to do , the people at the dicom team said a function which would do this is called DVInterface::saveDICOMImage() but I don't know how to call it or how to run these files,

PLease help

Mark