DcmFileFormat::saveFile truncates pixel data

[jstark]

Hi,
We have some code which reads from one file and writes to another like this:

Code: Select all

    const char * inFile = "/tmp/infile.dcm";
    const char * outFile = "/tmp/outfile.dcm";

    DcmFileFormat dcmff;
    OFCondition cond = dcmff.loadFile( OFFilename( inFile ) );

    cond = dcmff.saveFile( outFile, EXS_LittleEndianExplicit );
    if ( !cond.good() ) {
        std::cerr << "Failed to save file " << outFile;
        return 1;
    }
    return 0;

This works fine, providing the input file uses the LittleEndianExplicit transfer syntax. However, if the input file is compressed, saveFile writes no pixel data (actually the element is present but empty). The function still returns a 'good' condition - which seems like a problem to me.

Adding an explicit change of representation, restores the functionality:

Code: Select all

    if ( !dcmff.getDataset()->chooseRepresentation( EXS_LittleEndianExplicit, NULL ).good() ) {
        std::cerr << "chooseRepresentation failed" << outFile;
        return 1;
    }

My question is whether this is the expected behaviour or not? To me it seems strange that the pixel data is silently truncated in the first case.

Thanks for your help, John

[J. Riesmeier]

My first question is: are you already using the current DCMTK snapshot? If not, please try that first.

Of course, writing a compressed DICOM file with Explicit VR Little Endian (without decompressing the pixel data) does/should not work.

[jstark]

My first question is: are you already using the current DCMTK snapshot? If not, please try that first.

You mean the one dated yesterday? Of course. Seriously though, yes I just tested and got the same behaviour using DCMTK-3.6.1_20161102.

Of course, writing a compressed DICOM file with Explicit VR Little Endian (without decompressing the pixel data) does/should not work.

I agree that it should not work, and in the case that the necessary codec is not available it cannot work (in case the 'saveFile' function attempts to coerce the pixel data into a supported format, which evidently it doesn't).

But I'd expect it to fail with an error condition, not silently truncate the file.

[J. Riesmeier]

After checking the code...

First of all, I can confirm that the saveFile() method currently does not return with an error but silently stores a file with an empty Pixel Data element, which is not very nice.
Most (if not all) of the DCMTK sample tools, like e.g. dcmconv, check with canWriteXfer() before calling saveFile() whether the output transfer syntax would really work. Therefore, these tools do report an error.

Anyway, I will either check the source code of the dcmdata classes why saveFile() currently doesn't report an error in such a case or add this as an open issue to the bug tracker.

Update (after doing some testing): it seems that there is an issue with the DcmPixelData::write() method. I've added this to the bug tracker.

[jstark]

Thanks for your feedback. The findings seem reasonable to me.

[J. Riesmeier]

This issue should be fixed now: http://git.dcmtk.org/?p=dcmtk.git;a=com ... 286959f21f