Storing medical images - DICOM

This is a discussion on Storing medical images - DICOM ; Hi... I am doing some research into better storing and handling of medical image data. What is the underlying image format used to store medical images such as radiology images today? I know it is stored in DICOM format, but ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: Storing medical images

  1. Storing medical images

    Hi... I am doing some research into better storing and handling of
    medical image data. What is the underlying image format used to store
    medical images such as radiology images today? I know it is stored in
    DICOM format, but what is the format of the actual imagery data?'

    Jon


  2. Re: Storing medical images

    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

  3. Re: Storing medical images


    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"


  4. Re: Storing medical images

    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"



  5. Re: Storing medical images


    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


+ Reply to Thread