Byte Ordering : Little endian - Big Endian : Binary Files - DICOM

This is a discussion on Byte Ordering : Little endian - Big Endian : Binary Files - DICOM ; Hello Everyone, Need help with regards to the byte ordering . How does one find out whether the dicom file is in little endian or big endian. ex: the dicom preamble and the prefix are always liitle endian , how ...

+ Reply to Thread
Results 1 to 8 of 8

Thread: Byte Ordering : Little endian - Big Endian : Binary Files

  1. Byte Ordering : Little endian - Big Endian : Binary Files

    Hello Everyone,

    Need help with regards to the byte ordering .

    How does one find out whether the dicom file is in little endian or big
    endian.

    ex: the dicom preamble and the prefix are always liitle endian , how to
    go about reading the other tags.( how do we know the ordering of these
    tags are they in little endian or in big endian)

    Thanks

    Masood


  2. Re: Byte Ordering : Little endian - Big Endian : Binary Files

    Masood wrote:

    > How does one find out whether the dicom file is in little endian or big
    > endian.
    >
    > ex: the dicom preamble and the prefix are always liitle endian , how to
    > go about reading the other tags.( how do we know the ordering of these
    > tags are they in little endian or in big endian)


    The Transfer Syntax UID element in the meta information header
    tells you this.

    David


  3. Re: Byte Ordering : Little endian - Big Endian : Binary Files

    David

    What if the meta header is absent? If transfer syntax UID is absent
    what is the way to find programatically about transfer syntax (big or
    little / explicit or implicit?

    Regards,
    Prashant

    David Clunie wrote:
    > Masood wrote:
    >
    > > How does one find out whether the dicom file is in little endian or big
    > > endian.
    > >
    > > ex: the dicom preamble and the prefix are always liitle endian , how to
    > > go about reading the other tags.( how do we know the ordering of these
    > > tags are they in little endian or in big endian)

    >
    > The Transfer Syntax UID element in the meta information header
    > tells you this.
    >
    > David



  4. Re: Byte Ordering : Little endian - Big Endian : Binary Files

    [Sorry I reorganized the thread]

    > David Clunie wrote:
    > > Masood wrote:
    > >
    > > > How does one find out whether the dicom file is in little endian or big
    > > > endian.
    > > >
    > > > ex: the dicom preamble and the prefix are always liitle endian , how to
    > > > go about reading the other tags.( how do we know the ordering of these
    > > > tags are they in little endian or in big endian)

    > >
    > > The Transfer Syntax UID element in the meta information header
    > > tells you this.


    Prash wrote:
    > David
    >
    > What if the meta header is absent? If transfer syntax UID is absent
    > what is the way to find programatically about transfer syntax (big or
    > little / explicit or implicit?


    Well then this is not a DICOM file ;-P
    Anyway to deal with old ACR NEMA file or Mallinckrodt file, we use an
    heuristic for GDCM. We have been testing it on a fairly large
    population of files and seems to give good results.
    For more info see:
    gdcmDocument.cxx in GDCM 1.x
    or Reader::GuessTransferSyntax in gdcmReader.cxx in GDCM 2.x

    HTH
    Mathieu

    Refs:
    GDCM 1.x:
    http://www.creatis.insa-lyon.fr/Public/Gdcm/
    GDCM 2.x:
    http://sourceforge.net/projects/gdcm


  5. Re: Byte Ordering : Little endian - Big Endian : Binary Files

    See the com.protocols.dicom archives:

    http://groups.google.com/group/comp....c52b781d7a02d7

    David

    Prash wrote:
    > David
    >
    > What if the meta header is absent? If transfer syntax UID is absent
    > what is the way to find programatically about transfer syntax (big or
    > little / explicit or implicit?
    >
    > Regards,
    > Prashant
    >
    > David Clunie wrote:
    >
    >>Masood wrote:
    >>
    >>
    >>>How does one find out whether the dicom file is in little endian or big
    >>>endian.
    >>>
    >>>ex: the dicom preamble and the prefix are always liitle endian , how to
    >>>go about reading the other tags.( how do we know the ordering of these
    >>>tags are they in little endian or in big endian)

    >>
    >>The Transfer Syntax UID element in the meta information header
    >>tells you this.
    >>
    >>David

    >
    >


  6. Re: Byte Ordering : Little endian - Big Endian : Binary Files

    David

    Thanks for the link. It explains everything. It has logic to identify
    VR as well as byte ordering.

    Once you store a DICOM file on a media it has everything; 128 permeable
    4 DICM followed by Meta-header in which transfer syntax is mentioned.
    But when you receive a DICOM file in CStore communication all this part
    is cropped. In that case it becomes important to identify transfer
    syntax. Again in CStore it is negotiated and the entity downloading it
    knows. But what if this entity and parsing entity (entity attaching
    meta header, generating DICOMDir etc.) is different? Either they
    exchange the information between them or parsing entity should be smart
    enough to identify transfer syntax on its own.

    This is where the need to identify transfer syntax comes.

    Regards,
    Prashant

    David Clunie wrote:
    > See the com.protocols.dicom archives:
    >
    > http://groups.google.com/group/comp....c52b781d7a02d7
    >
    > David
    >
    > Prash wrote:
    > > David
    > >
    > > What if the meta header is absent? If transfer syntax UID is absent
    > > what is the way to find programatically about transfer syntax (big or
    > > little / explicit or implicit?
    > >
    > > Regards,
    > > Prashant
    > >
    > > David Clunie wrote:
    > >
    > >>Masood wrote:
    > >>
    > >>
    > >>>How does one find out whether the dicom file is in little endian or big
    > >>>endian.
    > >>>
    > >>>ex: the dicom preamble and the prefix are always liitle endian , how to
    > >>>go about reading the other tags.( how do we know the ordering of these
    > >>>tags are they in little endian or in big endian)
    > >>
    > >>The Transfer Syntax UID element in the meta information header
    > >>tells you this.
    > >>
    > >>David

    > >
    > >



  7. Re: Byte Ordering : Little endian - Big Endian : Binary Files

    Prash wrote:

    > Once you store a DICOM file on a media it has everything; 128 permeable
    > 4 DICM followed by Meta-header in which transfer syntax is mentioned.
    > But when you receive a DICOM file in CStore communication all this part
    > is cropped. In that case it becomes important to identify transfer
    > syntax. Again in CStore it is negotiated and the entity downloading it
    > knows. But what if this entity and parsing entity (entity attaching
    > meta header, generating DICOMDir etc.) is different? Either they
    > exchange the information between them or parsing entity should be smart
    > enough to identify transfer syntax on its own.


    Indeed, the meta information header is never transmitted on
    the network, deliberately.

    A correctly implemented DICOM C-STORE SCP should reconstruct its
    own meta header using the information in the command message and
    the presentation context of the association, before storing the
    information to disk; it is not necessary to parse the actual
    payload of the C-STORE dataset to do this.

    For example, in my pixelmed toolkit in StorageSCP you will
    find something like:

    CStoreRequestCommandMessage csrq;
    Association association;
    ....
    FileMetaInformation fmi = new FileMetaInformation(
    csrq.getAffectedSOPClassUID(),
    csrq.getAffectedSOPInstanceUID(),
    association.getTransferSyntaxForPresentationContex tID(presentationContextIDUsed),
    association.getCallingAETitle());
    ....
    out = new BufferedOutputStream(new FileOutputStream(temporaryReceivedFile));
    DicomOutputStream dout = new DicomOutputStream(out,TransferSyntax.ExplicitVRLit tleEndian,null);
    fmi.getAttributeList().write(dout);

    It would be an extremely poor design in my opinion to discard
    known information and then force the next component in the
    system to try to guess what was going on.

    The heuristic approach will fail when compressed transfer
    syntaxes are used (i.e., without conveying the transfer
    syntax explicitly, the "parsing entity" as you refer
    to it won't know which form of JPEG or JPEG 2000 is in
    use when it gets to the pixel data, or won't detect the
    presence of deflated data, etc.).

    Or to put it another way, given your choices of "either they
    exchange the information between them or parsing entity should
    be smart enough to identify transfer syntax on its own", the
    correct choice is the former, they should communicate the
    parameters; if loosely coupled via a file then the correct
    communication mechanism is the meta information header.

    David

  8. Re: Byte Ordering : Little endian - Big Endian : Binary Files

    David

    I Fully agree with you. Ideally the CStore SCP should construct the
    meta-header with bare minimum requirements or if SCP and Parsing entity
    are loosely coupled they should exchange the information through a
    file.

    But I have seen many test DICOM tools having CStore SCP not writing
    meta header and then your reading entity should be smart enough to
    identify the transfer syntax. In that case also you can only identify
    explicit/implicit or little/big but not the compression type if
    present.

    Some very old cath labs (I dont want to mention the name) associate a
    different transfer syntax and send data in a different format.

    Anyway thanks for your valuable notes.

    Regards,
    Prashant


    David Clunie wrote:
    > Prash wrote:
    >
    > > Once you store a DICOM file on a media it has everything; 128 permeable
    > > 4 DICM followed by Meta-header in which transfer syntax is mentioned.
    > > But when you receive a DICOM file in CStore communication all this part
    > > is cropped. In that case it becomes important to identify transfer
    > > syntax. Again in CStore it is negotiated and the entity downloading it
    > > knows. But what if this entity and parsing entity (entity attaching
    > > meta header, generating DICOMDir etc.) is different? Either they
    > > exchange the information between them or parsing entity should be smart
    > > enough to identify transfer syntax on its own.

    >
    > Indeed, the meta information header is never transmitted on
    > the network, deliberately.
    >
    > A correctly implemented DICOM C-STORE SCP should reconstruct its
    > own meta header using the information in the command message and
    > the presentation context of the association, before storing the
    > information to disk; it is not necessary to parse the actual
    > payload of the C-STORE dataset to do this.
    >
    > For example, in my pixelmed toolkit in StorageSCP you will
    > find something like:
    >
    > CStoreRequestCommandMessage csrq;
    > Association association;
    > ...
    > FileMetaInformation fmi = new FileMetaInformation(
    > csrq.getAffectedSOPClassUID(),
    > csrq.getAffectedSOPInstanceUID(),
    > association.getTransferSyntaxForPresentationContex tID(presentationContextIDUsed),
    > association.getCallingAETitle());
    > ...
    > out = new BufferedOutputStream(new FileOutputStream(temporaryReceivedFile));
    > DicomOutputStream dout = new DicomOutputStream(out,TransferSyntax.ExplicitVRLit tleEndian,null);
    > fmi.getAttributeList().write(dout);
    >
    > It would be an extremely poor design in my opinion to discard
    > known information and then force the next component in the
    > system to try to guess what was going on.
    >
    > The heuristic approach will fail when compressed transfer
    > syntaxes are used (i.e., without conveying the transfer
    > syntax explicitly, the "parsing entity" as you refer
    > to it won't know which form of JPEG or JPEG 2000 is in
    > use when it gets to the pixel data, or won't detect the
    > presence of deflated data, etc.).
    >
    > Or to put it another way, given your choices of "either they
    > exchange the information between them or parsing entity should
    > be smart enough to identify transfer syntax on its own", the
    > correct choice is the former, they should communicate the
    > parameters; if loosely coupled via a file then the correct
    > communication mechanism is the meta information header.
    >
    > David



+ Reply to Thread