Where can I store extra array information in DICOM image? - DICOM

This is a discussion on Where can I store extra array information in DICOM image? - DICOM ; Hi all, I generated a multi-image series. What I'd like to do is for each image, add an equivalent size pixel data block somewhere to the image. This would be so if I read this DICOM image back in one ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: Where can I store extra array information in DICOM image?

  1. Where can I store extra array information in DICOM image?

    Hi all,

    I generated a multi-image series. What I'd like to do is for each
    image, add an equivalent size pixel data block somewhere to the image.
    This would be so if I read this DICOM image back in one of my
    applications, I can find this 'extra' pixel data. I do not want to
    create an extra series for it.

    Can I just simply append the data to the end of my normal pixel block?
    Or is there some special place I can store this? Can I just store it to
    the end of the file in a binary operation, would this harm the validity
    of the DICOM file when viewers try reading it in?

    Thanks!


  2. Re: Where can I store extra array information in DICOM image?

    No you can't simply add your data to the end of pixel data, not without
    causing either parse errors or display issues with applications who
    would receive your data expecting standard compliant data.

    DICOM is a standard for data interchange between different
    applications. What you describe is a need to cache proprietary
    information embedded in this public/standard format so your application
    can store your objects in some external, standards based repository and
    still retain access to the this proprietary data when it is retrieved
    back.

    The DICOM standard provides the mechanism for doing just that in
    private data elements. However, it is atypical for those private data
    elements to be bulk pixel data. Assuming you took the above approach
    (private data elements), some of the customers buying your device might
    be somewhat irate to discover your objects take up twice as much space
    in their archive as they should, given the size of the "standard" pixel
    data. Also, if their PACS uses DICOM transfer syntax based compression
    methods, the overhead for your private data will be even worse,
    because private data elements would not be included in the compresion,
    whereas the standard pixel data would be included.

    One immediate question is why you feel you need to hide or separate
    this pixel data from the standard pixel data. Since your objects are
    already multi-frame objects, why not just add these image frames into
    sequence containing the other frames and call out their differences
    from the "standard pixel data" with the attributes describing the
    frames in the object? Do you truly not want other applications to be
    able to "see" these frames; or alternatively is the problem that the
    standard doesn't give you the attributes and or attribute values to
    properly describe them (hence preventing you from including them with
    the standard pixel data)

    What kind of multiframe object are these images (US, NM, VL, MR, XA,
    RF, etc?)


  3. Re: Where can I store extra array information in DICOM image?

    Hi Eric,

    Thanks so much for your reply. My images are MR. I wanted to store some
    results from a per pixel calculation of the actual image pixel data. So
    each pixel would have a corresponding floating point number I'd like to
    store.

    Originally I had stored these results in separate image frames
    altogether (after multiplying the results to get them into unsigned
    short value range for storage compliance) but the data isn't really
    meant to be meaningful as a standalone image. I was really worried some
    viewers would mis-interpret these images as subtraction images when
    really it's just storing the result of my per pixel calculations.

    It seems like the standard doesn't have many options for this - either
    store it in the private tags with double storage used, and not be able
    to take advantage of compression - or store it as a separate image
    altogether.

    These are really the only 2 options right? Thanks for any more
    info/suggestions!

    Mark


+ Reply to Thread