Cannot determine start fragment: basic offset table is empty

[majorss]

3.6.3 (2018-02-05 and GIT)
..\dcmdata\libsrc\dccodec.cc, line : 266

result = makeOFCondition(OFM_dcmdata, EC_CODE_CannotDetermineStartFragment, OF_error, "Cannot determine start fragment: basic offset table is empty");

How to fix this problem?

// Leadtools V18, ezDICOM can load normally with low memory




// Dicom Image : US Multiframe(138 frames, EXS_JPEGProcess1)

//////////////////////////////////////////////////////////////////////////////////////////////////////
// This method works normally, but high memory use.
ULONG ulFlags = CIF_DecompressCompletePixelData;
DicomImage* pDcmImage = new DicomImage(pDcmFile, xfer, ulFlags);
EI_Status estat = pDcmImage->getStatus(); // <<<<<== EIS_Normal
int nRetSize = pDcmSplit->createWindowsDIB((void*&)pData, nSize, nFrameIndex, 24);



//////////////////////////////////////////////////////////////////////////////////////////////////////
// This method does not work normally, but I've been using so far without problem and with low memory
ULONG ulFlags = CIF_UsePartialAccessToPixelData;
DicomImage* pDcmImage = new DicomImage(pDcmFile, xfer, ulFlags, nFrameIndex, 1);
EI_Status estat = pDcmImage->getStatus(); // <<<<<== EIS_InvalidImage
int nRetSize = pDcmSplit->createWindowsDIB((void*&)pData, nSize, 0, 24);

[Michael Onken]

Hi,

send the pic to bugs at dcmtk org if you like l and we can have a look. Probably the image has an incorrect encoding.

Best,
Michael

[J. Riesmeier]

It seems that the Pixel Data is fragmented (i.e. Number of Pixel Items != Number of Frames + 1) but the Basic Offset Table (1st Pixel Item) is empty. This combination is not not supported by the DCMTK - at least not in the context you use it.

[majorss]

Thanks your reply.

This problem was solved by saving again after changing TransferSyntax.

[Marco Eichelberg]

I also had a look at the image. The reason why direct frame-wise access did not work is actually that the image is faulty: The image contains 139 frames, but NumberOfFrames is only 138.
As you perhaps know, the DICOM standard allows JPEG compressed data to be store in a fragmented manner, i.e. there can be more than one item in the PixelData sequence.
Direct frame-wise access works in DCMTK if one of the following two conditions are fulfilled:

• The compressed data is not fragmented, i.e. there is exactly one pixel data item per frame
• The compressed data is fragmented, but the so-called "basic offset table" (the first pixel data item) contains information about where each frame starts

In your case, the number of pixel items is larger than expected, so DCMTK believes that pixel data must be fragmented, but the offset table is empty, so direct access does not work.
In fact, however, this is caused by the wrong value in NumberOfFrames.