Hi Jon,

jondelac@gmail.com wrote:
> I know it is stored in
> DICOM format, but what is the format of the actual imagery data?'

Have a look at the standard itself (you will find the information under
the keyword "Transfer Syntaxes"): It's mainly uncompressed 16 bit
Grayscale, either signed or unsigned, and a variety of embedded JPEG
streams that are used to encode pixel data (very brief and roughly said).

Actually, DICOM does not "store" images, it only describes formates to
*interchange* image data so the application receiving the image
information has enough information to interpret the images.

How the images my be stored *inside* a system is not part of the
standard, it only describes how the data is to be sent via network or on
exchangable media from one application to the other.

HTH,


Peter

jondelac@gmail.com wrote:
> what is the format of the actual imagery data?'
It seems like you're looking for someone to say - it is really in the
same format as a TIF or JPEG file inside some other stuff that DICOM
wraps around the image type. This is not to be. The DICOM format
includes metadata which describes the layout of the pixel data within
one attribute, the pixel data attribute. Other attributes describe the
number of rows, columns, components per pixel, bits per pixel, bits
stored, bits used, high bit of the pixel, etc. There are a number of
patterns or combinations of these attributes that multiple different
manufactures have settled on for a specific imaging type. For example,
CT image data is typically 512x512 with 12 bit pixels stored in 16 bit
words, with bit 11 as the high bit. However there is nothing stopping a
manufacture from using a different layout of their device's pixel data
and adjusting the dicom attributes describing it appropriately.
Similarly, different modality types are more suited to different styles
of representation, and these change over time. At one point, Ultrasound
images were typically 512x512 store in RGB (3 components per pixel),
8-bits per component.
In all of the above cases, the image pixels are stored in the pixel
data attribute, but the specific parameters used to decode that blob of
bytes into a set of pixels is stored in other attributes.
Another factor working into all of this is transfer syntaxes. These are
used when an image compression algorithm has been applied to the pixel
data (there are actually other transfer syntaxes where the dicom
attribute data itself is compressed but we'll ignore those for the
moment). When the pixel data has been compressed, a dicom attribute in
the data informs you (the reader of the dicom "header") of this fact,
so you will know to decompress the data before you seek to apply the
logic implicit in the pixel data layout. Some compressed data streams
(Jpeg for example) include information about the rows, columns, and
pixel bit depth in the encode compressed pixel data stream. These are
expected to be consistent with the information in the DICOM header, but
do not replace the information in the DICOM header itself. Bottomline
is you have to read the DICOM header to know how to interpret the pixel
data. There is no magic "go to this offset in the DICOM file and its
really a rule"

Thanks for the great explanation there, Eric. Helps newbies like me a
lot.

Sai

eric.goodall@gmail.com wrote:
> jondelac@gmail.com wrote:
> > what is the format of the actual imagery data?'
> It seems like you're looking for someone to say - it is really in the
> same format as a TIF or JPEG file inside some other stuff that DICOM
> wraps around the image type. This is not to be. The DICOM format
> includes metadata which describes the layout of the pixel data within
> one attribute, the pixel data attribute. Other attributes describe the
> number of rows, columns, components per pixel, bits per pixel, bits
> stored, bits used, high bit of the pixel, etc. There are a number of
> patterns or combinations of these attributes that multiple different
> manufactures have settled on for a specific imaging type. For example,
> CT image data is typically 512x512 with 12 bit pixels stored in 16 bit
> words, with bit 11 as the high bit. However there is nothing stopping a
> manufacture from using a different layout of their device's pixel data
> and adjusting the dicom attributes describing it appropriately.
> Similarly, different modality types are more suited to different styles
> of representation, and these change over time. At one point, Ultrasound
> images were typically 512x512 store in RGB (3 components per pixel),
> 8-bits per component.
> In all of the above cases, the image pixels are stored in the pixel
> data attribute, but the specific parameters used to decode that blob of
> bytes into a set of pixels is stored in other attributes.
> Another factor working into all of this is transfer syntaxes. These are
> used when an image compression algorithm has been applied to the pixel
> data (there are actually other transfer syntaxes where the dicom
> attribute data itself is compressed but we'll ignore those for the
> moment). When the pixel data has been compressed, a dicom attribute in
> the data informs you (the reader of the dicom "header") of this fact,
> so you will know to decompress the data before you seek to apply the
> logic implicit in the pixel data layout. Some compressed data streams
> (Jpeg for example) include information about the rows, columns, and
> pixel bit depth in the encode compressed pixel data stream. These are
> expected to be consistent with the information in the DICOM header, but
> do not replace the information in the DICOM header itself. Bottomline
> is you have to read the DICOM header to know how to interpret the pixel
> data. There is no magic "go to this offset in the DICOM file and its
> really a rule"

eric.goodall@gmail.com wrote:
> jondelac@gmail.com wrote:
> > what is the format of the actual imagery data?'
> It seems like you're looking for someone to say - it is really in the
> same format as a TIF or JPEG file inside some other stuff that DICOM
> wraps around the image type. This is not to be. The DICOM format
> includes metadata which describes the layout of the pixel data within
> one attribute, the pixel data attribute. Other attributes describe the
> number of rows, columns, components per pixel, bits per pixel, bits
> stored, bits used, high bit of the pixel, etc. There are a number of
> patterns or combinations of these attributes that multiple different
> manufactures have settled on for a specific imaging type. For example,
> CT image data is typically 512x512 with 12 bit pixels stored in 16 bit
> words, with bit 11 as the high bit. However there is nothing stopping a
> manufacture from using a different layout of their device's pixel data
> and adjusting the dicom attributes describing it appropriately.
> Similarly, different modality types are more suited to different styles
> of representation, and these change over time. At one point, Ultrasound
> images were typically 512x512 store in RGB (3 components per pixel),
> 8-bits per component.
> In all of the above cases, the image pixels are stored in the pixel
> data attribute, but the specific parameters used to decode that blob of
> bytes into a set of pixels is stored in other attributes.
> Another factor working into all of this is transfer syntaxes. These are
> used when an image compression algorithm has been applied to the pixel
> data (there are actually other transfer syntaxes where the dicom
> attribute data itself is compressed but we'll ignore those for the
> moment). When the pixel data has been compressed, a dicom attribute in
> the data informs you (the reader of the dicom "header") of this fact,
> so you will know to decompress the data before you seek to apply the
> logic implicit in the pixel data layout. Some compressed data streams
> (Jpeg for example) include information about the rows, columns, and
> pixel bit depth in the encode compressed pixel data stream. These are
> expected to be consistent with the information in the DICOM header, but
> do not replace the information in the DICOM header itself. Bottomline
> is you have to read the DICOM header to know how to interpret the pixel
> data. There is no magic "go to this offset in the DICOM file and its
> really a rule"

This was an excellent, very relevent explanation... Thanks.

What are the standard compression formats used when these raw image
streams are saved in the PACS archive?

I assume, froma modality such as a CT, the DICOM information (header
and image data) are uncompressed... and the archive system can compress
the image data. What formats are supported there, or can an archive
use anything you want? I ask because you said Jpeg, and I am wondering
if that is standard... Since some other modality such as a viewing
station may request to read and display the data, it would have to know
the compression scheme used?

Jon