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);
Cannot determine start fragment: basic offset table is empty
Moderator: Moderator Team
-
- DCMTK Developer
- Posts: 2073
- Joined: Fri, 2004-11-05, 13:47
- Location: Oldenburg, Germany
- Contact:
Re: Cannot determine start fragment: basic offset table is e
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
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
-
- DCMTK Developer
- Posts: 2550
- Joined: Tue, 2011-05-03, 14:38
- Location: Oldenburg, Germany
- Contact:
Re: Cannot determine start fragment: basic offset table is e
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.
Re: Cannot determine start fragment: basic offset table is e
Thanks your reply.
This problem was solved by saving again after changing TransferSyntax.
This problem was solved by saving again after changing TransferSyntax.
-
- OFFIS DICOM Team
- Posts: 1513
- Joined: Tue, 2004-11-02, 17:22
- Location: Oldenburg, Germany
- Contact:
Re: Cannot determine start fragment: basic offset table is e
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:
In fact, however, this is caused by the wrong value in NumberOfFrames.
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 fact, however, this is caused by the wrong value in NumberOfFrames.
Who is online
Users browsing this forum: Bing [Bot], Google [Bot] and 1 guest