storescu error during transfer - DICOM

This is a discussion on storescu error during transfer - DICOM ; I am using OFFIS DCMTK's storescu utility (version 3.5.4)to push a dicom image to our review station running K-PACS. I consistently get this error with some images but almost all transfer fine. A sample error is: DcmElement: PixelData(7fe0,0010) larger (4510806) ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: storescu error during transfer

  1. storescu error during transfer

    I am using OFFIS DCMTK's storescu utility (version 3.5.4)to push a
    dicom image to our review station running K-PACS.

    I consistently get this error with some images but almost all transfer
    fine. A sample error is:
    DcmElement: PixelData(7fe0,0010) larger (4510806) that remaining bytes
    in file
    storescu: Bad DICOM file: /xray_uploads/10437.20060928.095258.dcm:
    Invalid Stream
    storescu: SCU Failed:
    0001:0004 Invalid Stream

    I have an x-ray image in 8-bit format (2393 x 1885 8bit JFIF N
    224681). I convert it to pnm then dcm using David Clunie's
    dicom3tools.These steps work just fine (snapshot.20060918).

    If I can transfer other dicom images created from jpeg or tiff, but I
    cannot figure out why this dcm image will not transfer using storescu.

    I can manually copy it to the review station then import it through
    K-PACS without error.



    Thanks.

    Steve Poe


  2. Re: storescu error during transfer

    Hi Steve,

    I would like to test this image, what version of K-PACS are you using?
    Send me the image to:
    rafaelcharrua.com

    Regards,
    Rafael Sanguinetti
    CharruaSoft.com

    steve.poe@gmail.com ha escrito:

    > I am using OFFIS DCMTK's storescu utility (version 3.5.4)to push a
    > dicom image to our review station running K-PACS.
    >
    > I consistently get this error with some images but almost all transfer
    > fine. A sample error is:
    > DcmElement: PixelData(7fe0,0010) larger (4510806) that remaining bytes
    > in file
    > storescu: Bad DICOM file: /xray_uploads/10437.20060928.095258.dcm:
    > Invalid Stream
    > storescu: SCU Failed:
    > 0001:0004 Invalid Stream
    >
    > I have an x-ray image in 8-bit format (2393 x 1885 8bit JFIF N
    > 224681). I convert it to pnm then dcm using David Clunie's
    > dicom3tools.These steps work just fine (snapshot.20060918).
    >
    > If I can transfer other dicom images created from jpeg or tiff, but I
    > cannot figure out why this dcm image will not transfer using storescu.
    >
    > I can manually copy it to the review station then import it through
    > K-PACS without error.
    >
    >
    >
    > Thanks.
    >
    > Steve Poe



  3. Re: storescu error during transfer

    Rafael,

    K-PACS 0.98. I'll send you a copy of the image.

    Thanks for your help.

    Steve

    rafa_sanguinetti@hotmail.com wrote:
    > Hi Steve,
    >
    > I would like to test this image, what version of K-PACS are you using?
    > Send me the image to:
    > rafaelcharrua.com
    >
    > Regards,
    > Rafael Sanguinetti
    > CharruaSoft.com
    >
    > steve.poe@gmail.com ha escrito:
    >
    > > I am using OFFIS DCMTK's storescu utility (version 3.5.4)to push a
    > > dicom image to our review station running K-PACS.
    > >
    > > I consistently get this error with some images but almost all transfer
    > > fine. A sample error is:
    > > DcmElement: PixelData(7fe0,0010) larger (4510806) that remaining bytes
    > > in file
    > > storescu: Bad DICOM file: /xray_uploads/10437.20060928.095258.dcm:
    > > Invalid Stream
    > > storescu: SCU Failed:
    > > 0001:0004 Invalid Stream
    > >
    > > I have an x-ray image in 8-bit format (2393 x 1885 8bit JFIF N
    > > 224681). I convert it to pnm then dcm using David Clunie's
    > > dicom3tools.These steps work just fine (snapshot.20060918).
    > >
    > > If I can transfer other dicom images created from jpeg or tiff, but I
    > > cannot figure out why this dcm image will not transfer using storescu.
    > >
    > > I can manually copy it to the review station then import it through
    > > K-PACS without error.
    > >
    > >
    > >
    > > Thanks.
    > >
    > > Steve Poe



  4. Re: storescu error during transfer

    steve.poe@gmail.com wrote:
    > I consistently get this error with some images but almost all transfer
    > fine. A sample error is:
    > DcmElement: PixelData(7fe0,0010) larger (4510806) that remaining bytes
    > in file


    This error message means that the file is too short, i.e. the file suddenly ends somewhere
    "in the middle" of the pixel data - in fact there might just be a single byte or a few
    bytes missing, but the file is corrupt and, therefore, rejected by the DCMTK parser.
    That is, of course, unless the file triggers a specific bug in DCMTK, something which
    sounds unlikely with such a basic operation but is not impossible of course.

    Regards,
    Marco Eichelberg
    OFFIS

  5. Re: storescu error during transfer

    Marco,

    Thanks for the explaination, this helps make sense. It could be an
    issue with DCMTK, dicomtools, or netpbm not trapping the error to begin
    with during file creation.

    Example:

    The original file is a 8-bit jpeg x-ray image.

    convert to pnm using jpegtopnm (from netpbm-10.34) - fine.
    convert to dicom from pnm (dicom3tools snapshot.20060922) - fine.
    send to reviewPACS station using storescu - error.

    Thanks again.

    Steve


    Marco Eichelberg wrote:
    > steve.poe@gmail.com wrote:
    > > I consistently get this error with some images but almost all transfer
    > > fine. A sample error is:
    > > DcmElement: PixelData(7fe0,0010) larger (4510806) that remaining bytes
    > > in file

    >
    > This error message means that the file is too short, i.e. the file suddenly ends somewhere
    > "in the middle" of the pixel data - in fact there might just be a single byte or a few
    > bytes missing, but the file is corrupt and, therefore, rejected by the DCMTK parser.
    > That is, of course, unless the file triggers a specific bug in DCMTK, something which
    > sounds unlikely with such a basic operation but is not impossible of course.
    >
    > Regards,
    > Marco Eichelberg
    > OFFIS



+ Reply to Thread