Clarification for Raw Data IOD needed
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?
Re: 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?
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 !