Clarification for Raw Data IOD needed - DICOM

This is a discussion on Clarification for Raw Data IOD needed - DICOM ; Hi Everyone, The Raw Data IOD states that: "The Raw Data stored with the Raw Data Module consists of one or more private attributes that are vendor specific." Does this really mean that re-using standard DICOM attributes is forbidden? Would ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Clarification for Raw Data IOD needed

  1. Clarification for Raw Data IOD needed

    Hi Everyone,
    The Raw Data IOD states that:
    "The Raw Data stored with the Raw Data Module consists of one or more
    private attributes that are vendor specific."
    Does this really mean that re-using standard DICOM attributes is
    forbidden? Would it be permissible to include, for example, Pixel Data
    [7FE0,0010] in a Raw Data object?

    Thanks,
    Jeff

  2. Re: Clarification for Raw Data IOD needed

    jeff.pohlhammer@philips.com wrote:

    > Hi Everyone,
    > The Raw Data IOD states that:
    > "The Raw Data stored with the Raw Data Module consists of one or more
    > private attributes that are vendor specific."
    > Does this really mean that re-using standard DICOM attributes is
    > forbidden? Would it be permissible to include, for example, Pixel Data
    > [7FE0,0010] in a Raw Data object?
    >
    > Thanks,
    > Jeff


    Hi Jeff,

    Yes, that would be perfectly acceptable, though it would be advisable
    to encode a complete and sane Image Pixel Module to go along with it,
    since toolkits generally depend on the accompanying attributes to
    handle (7FE0,0010) differently from "ordinary" attributes. And I
    would suggest remaining with OB/OW and no more than 16 bits just
    in case, for the time being, until more IODs do 32 bits and/or OF
    for Pixel Data.

    However, if your raw data really is an "image" and populates Pixel
    Data with something displayable or processable in the normal
    sense, wouldn't it be preferable to use a modality-specific image
    IOD or a secondary capture IOD ?

    I.e. Just because it is "raw data" doesn't mean one has to use the
    Raw Data IOD. If it is stored as a 2D array, or succession of 2D
    arrays, even if it does not map to a Cartesian real world space,
    then perhaps it is better stored as an "image".

    Two of the benefits of this approach are that one can "display" or
    applying processing as if it were an "image", and that one can
    take advantage of the awareness of toolkits and the transfer syntaxes
    that this is "bulk data", for buffering, caching and compression.

    So in summary, my suggestion is that if you have a reason to use
    (7FE0,0010), then in general that is a reason not to use the Raw
    Data IOD !

    David

+ Reply to Thread