Encapsulated PDF and DICOM Default Transfer Syntax - DICOM

This is a discussion on Encapsulated PDF and DICOM Default Transfer Syntax - DICOM ; Dear all, PS 3.5-2008 defines the DICOM Default Transfer Syntax in chapter 10.1 as follows: "DICOM defines a default Transfer Syntax, the DICOM Implicit VR Little Endian Transfer Syntax (UID = "1.2.840.10008.1.2"), which shall be supported by every conformant DICOM ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: Encapsulated PDF and DICOM Default Transfer Syntax

  1. Encapsulated PDF and DICOM Default Transfer Syntax

    Dear all,

    PS 3.5-2008 defines the DICOM Default Transfer Syntax in chapter 10.1
    as follows:

    "DICOM defines a default Transfer Syntax, the DICOM Implicit VR Little
    Endian Transfer Syntax (UID = "1.2.840.10008.1.2"), which shall be
    supported by every conformant DICOM Implementation."

    In chapter A.4 (TRANSFER SYNTAXES FOR ENCAPSULATION OF ENCODED PIXEL
    DATA), under a), the following is defined:

    "The Data Elements contained in the Data Set structure shall be
    encoded with Explicit VR (with a VR Field) as specified in Section
    7.1.2."

    What is required here when dealing with an Encapsulated PDF instance?
    This IOD does not include the "Pixel Data" element (7FE0,0010), but
    uses the element "Encapsulated Document" (0042,0011) for containing
    the actual content.
    This element is not included in the list of attributes in chapter A.1
    (DICOM IMPLICIT VR LITTLE ENDIAN TRANSFER SYNTAX).

    The question basically is: is a Storage SCU expected to offer both the
    Implicit LE and the Explicit LE Transfer Syntax in the Association
    Request, or is one of them sufficient? If so, which one is the correct
    to use when storing EPDF instances?

  2. Re: Encapsulated PDF and DICOM Default Transfer Syntax

    Hi Tobias

    This is just an unfortunate overloading of the term "encapsulated".

    The PS 3.5 descriptions linking explicit VR apply only to the use
    of compressed image pixel data in (7FE0,0010) in their "encapsulated"
    form in which the compressed bitstream is encoded within a sequence-
    like structure.

    The use of Encapsulated Document (0042,0011) (as used in PS 3.3 for
    PDFs) is not affected by this at all, so either implicit or explicit
    VR transfer syntaxes may be used.

    Of course, it is always preferable to offer and accept and choose
    an explicit VR transfer syntax over the implicit default, but one
    cannot refuse the default.

    David

    Tobias wrote:
    > Dear all,
    >
    > PS 3.5-2008 defines the DICOM Default Transfer Syntax in chapter 10.1
    > as follows:
    >
    > "DICOM defines a default Transfer Syntax, the DICOM Implicit VR Little
    > Endian Transfer Syntax (UID = "1.2.840.10008.1.2"), which shall be
    > supported by every conformant DICOM Implementation."
    >
    > In chapter A.4 (TRANSFER SYNTAXES FOR ENCAPSULATION OF ENCODED PIXEL
    > DATA), under a), the following is defined:
    >
    > "The Data Elements contained in the Data Set structure shall be
    > encoded with Explicit VR (with a VR Field) as specified in Section
    > 7.1.2."
    >
    > What is required here when dealing with an Encapsulated PDF instance?
    > This IOD does not include the "Pixel Data" element (7FE0,0010), but
    > uses the element "Encapsulated Document" (0042,0011) for containing
    > the actual content.
    > This element is not included in the list of attributes in chapter A.1
    > (DICOM IMPLICIT VR LITTLE ENDIAN TRANSFER SYNTAX).
    >
    > The question basically is: is a Storage SCU expected to offer both the
    > Implicit LE and the Explicit LE Transfer Syntax in the Association
    > Request, or is one of them sufficient? If so, which one is the correct
    > to use when storing EPDF instances?


  3. Re: Encapsulated PDF and DICOM Default Transfer Syntax

    On 3 Sep., 17:02, David Clunie wrote:
    > Hi Tobias
    >
    > This is just an unfortunate overloading of the term "encapsulated".
    >
    > The PS 3.5 descriptions linking explicit VR apply only to the use
    > of compressed image pixel data in (7FE0,0010) in their "encapsulated"
    > form in which the compressed bitstream is encoded within a sequence-
    > like structure.
    >
    > The use of Encapsulated Document (0042,0011) (as used in PS 3.3 for
    > PDFs) is not affected by this at all, so either implicit or explicit
    > VR transfer syntaxes may be used.
    >
    > Of course, it is always preferable to offer and accept and choose
    > an explicit VR transfer syntax over the implicit default, but one
    > cannot refuse the default.
    >
    > David
    >
    > Tobias wrote:
    > > Dear all,

    >
    > > PS 3.5-2008 defines the DICOM Default Transfer Syntax in chapter 10.1
    > > as follows:

    >
    > > "DICOM defines a default Transfer Syntax, the DICOM Implicit VR Little
    > > Endian Transfer Syntax (UID = "1.2.840.10008.1.2"), which shall be
    > > supported by every conformant DICOM Implementation."

    >
    > > In chapter A.4 (TRANSFER SYNTAXES FOR ENCAPSULATION OF ENCODED PIXEL
    > > DATA), under a), the following is defined:

    >
    > > "The Data Elements contained in the Data Set structure shall be
    > > encoded with Explicit VR (with a VR Field) as specified in Section
    > > 7.1.2."

    >
    > > What is required here when dealing with an Encapsulated PDF instance?
    > > This IOD does not include the "Pixel Data" element (7FE0,0010), but
    > > uses the element "Encapsulated Document" (0042,0011) for containing
    > > the actual content.
    > > This element is not included in the list of attributes in chapter A.1
    > > (DICOM IMPLICIT VR LITTLE ENDIAN TRANSFER SYNTAX).

    >
    > > The question basically is: is a Storage SCU expected to offer both the
    > > Implicit LE and the Explicit LE Transfer Syntax in the Association
    > > Request, or is one of them sufficient? If so, which one is the correct
    > > to use when storing EPDF instances?


    Thanks a lot for the clarification!

    Tobias

+ Reply to Thread