DataSet Trailing Padding (fffc,fffc) clarification - DICOM

This is a discussion on DataSet Trailing Padding (fffc,fffc) clarification - DICOM ; Hi there, I cannot find a clear definition of the DataSet Trailing Padding in the DICOM standard. I read PS 3.10 - 2008: .... The last Data Element of a Data Set may be Data Element (FFFC,FFFC) if padding of ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: DataSet Trailing Padding (fffc,fffc) clarification

  1. DataSet Trailing Padding (fffc,fffc) clarification

    Hi there,

    I cannot find a clear definition of the DataSet Trailing Padding in
    the DICOM standard. I read PS 3.10 - 2008:

    ....
    The last Data Element of a Data Set may be Data Element (FFFC,FFFC) if
    padding of a Data Set is
    desired when a file is written. The Value of this Data Set Trailing
    Padding Data Element (FFFC,FFFC)
    has no significance and shall be ignored by all DICOM implementations
    reading this Data Set. File-set
    Readers or Updaters shall be able to process this Data Set Trailing
    Padding (FFFC,FFFC) either in the
    Data Set following the Meta Information or in Data Sets nested in a
    Sequence (See PS 3.5 of the DICOM
    Standard).
    ....

    But still I do not understand how FS reader/update should deal with
    it:

    1. Is it a true Data Element ? ie. if Value Length is set to some
    garbage value, should the FS reader declare the file valid or not ?
    2. what happen if this tag is in the middle of the dataset, should the
    reading stop (since Value Length is not garanteed to be valid) ?

    thanks
    -Mathieu
    Ps: Using a very well know open source toolkit, I cannot make it fails
    reading a DataSet Trailing Padding with a garbaged Value Length, while
    other toolkit report a clear error.

  2. Re: DataSet Trailing Padding (fffc,fffc) clarification


    Data Set Trailing Padding is just a Data Element. It value length
    should not be not set to some invalid value. P.S. 3.6 defines it as
    just an OB. The values themselves have however no meaning.

    Some toolkits may be able to handle bad Value lenght values as it is
    the last data element.

    Victor

  3. Re: DataSet Trailing Padding (fffc,fffc) clarification

    Just as an FYI, the DataSet Trailing Padding tag along with the file
    meta information was originally intended as a way to make a DICOM file
    be a TIFF file also. These areas of the file were intended to put
    TIFF related tags in them. I believe TIFF has a way to skip over
    parts of the file and continue its tags in another part of the file,
    so the introductory tags would be in the file meta information, and
    then subsequent tags could be embedded in the DataSet Trailing Padding
    tag's value. I've also seen the DataSet Trailing padding be used to
    make a file be an even multiple of 1024 bytes, so its more efficiently
    stored on a CD.

    In any case, the tag can be safely ignored. If its occurring
    incorrectly in the middle of a dataset, that's really an
    implementation decision if you want to ignore the tag, or generate an
    error. Also, FYI, its common that applications include this tag in
    message transfers. I was involved in a DICOM implementation that's
    quite widely used that does this in some of its early versions. It
    did not strip out the tag when converting between a file and a message
    to be transferred over the network.

    Steve


    On Sep 22, 9:29*am, Mathieu Malaterre
    wrote:
    > Hi there,
    >
    > * I cannot find a clear definition of the DataSet Trailing Padding in
    > the DICOM standard. I read PS 3.10 - 2008:
    >
    > ...
    > The last Data Element of a Data Set may be Data Element (FFFC,FFFC) if
    > padding of a Data Set is
    > desired when a file is written. The Value of this Data Set Trailing
    > Padding Data Element (FFFC,FFFC)
    > has no significance and shall be ignored by all DICOM implementations
    > reading this Data Set. File-set
    > Readers or Updaters shall be able to process this Data Set Trailing
    > Padding (FFFC,FFFC) either in the
    > Data Set following the Meta Information or in Data Sets nested in a
    > Sequence (See PS 3.5 of the DICOM
    > Standard).
    > ...
    >
    > * But still I do not understand how FS reader/update should deal with
    > it:
    >
    > 1. Is it a true Data Element ? ie. if Value Length is set to some
    > garbage value, should the FS reader declare the file valid or not ?
    > 2. what happen if this tag is in the middle of the dataset, should the
    > reading stop (since Value Length is not garanteed to be valid) ?
    >
    > thanks
    > -Mathieu
    > Ps: Using a very well know open source toolkit, I cannot make it fails
    > reading a DataSet Trailing Padding with a garbaged Value Length, while
    > other toolkit report a clear error.



  4. Re: DataSet Trailing Padding (fffc,fffc) clarification

    Steve Wranovsky wrote:
    > In any case, the tag can be safely ignored. If its occurring
    > incorrectly in the middle of a dataset, that's really an
    > implementation decision if you want to ignore the tag, or generate an
    > error. Also, FYI, its common that applications include this tag in
    > message transfers. I was involved in a DICOM implementation that's
    > quite widely used that does this in some of its early versions. It
    > did not strip out the tag when converting between a file and a message
    > to be transferred over the network.


    DCMTK will also treat DataSet trailing padding very much like any
    attribute with OB value representation, i.e. will not strip the attribute
    from the dataset before sending over a network. I agree that whatever
    is contained in that attribute is probably of no value anymore once the
    meta-header has been ripped off the dataset (which necessarily happens
    during transfer), but a place for the TIFF header was probably not the
    only use case for that attribute, because DICOM explicitly mentions that
    it can also be used inside sequence items. This is only useful if you
    want to pad sequence items to a size that is a multiple of some block
    size of the device you are reading from or writing to - I could imagine
    that this was meant as a way of implementing optimization strategies
    for file storage on (very slow by todays standards) storage media.

    The "dcmconv" command line tool in DCMTK suppors the creation of such
    trailing padding elements that pad items to certain block sizes - not
    that we ever needed that, but it was interesting to implement :-)

    Regards,
    Marco Eichelberg
    OFFIS

+ Reply to Thread