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

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

[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

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
>
>

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
> >
> >

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

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