how to get offset table and process it

All other questions regarding DCMTK

Moderator: Moderator Team

Post Reply
Posts: 11
Joined: Thu, 2004-11-18, 08:16

how to get offset table and process it

#1 Post by joyli » Thu, 2007-11-08, 05:15

for instance

at DJCodecEncoder class there is a method named encode ,it process the offset other words ,the first pixlitem is offset table.

but at DJCodecDecoder class there is a methed named decode,maybe it does not process the first pixelitem. first item should be offset table

ref: result = pixSeq->getItem(pixItem, 1); // first item is offset table, use second item

especially with mutliframe,offset table is most useful.

how could i get the first pixlItem and process it with offsetlist


result = pixSeq->getItem(pixItem, 0);
(*OFFSETLISt*)pixlitem is ok??

or maybe have other methods.

I dont know the relationship between pixlitem and fragment all along.

maybe pixlitem is constructed with several fragments. is it right?

offset table stores the pixelitem offset ,is it right?

for another instance . there is a us multiframe image.there are 100 frames
then in the should have "101" pixlitem,the first item is offset table .all multiframe images are always like this. is it right?

when the offset is absent in some mutiframe image, are there numberframes+1 item in this sequence?

look forward to anybody's reply. tks

Posts: 11
Joined: Thu, 2004-11-18, 08:16

#2 Post by joyli » Thu, 2007-11-08, 09:36

i saw tk's reply. maybe it is useful for others with same question.

but i also hope tk can interpret the questions above. tks.

here is link viewtopic.php?t=1026&highlight=multiframe

* There is only one frame (NumberOfFrames=1) - no problem, all fragments "belong" to frame 1.
* The caller tries to decode the frames in increasing order, starting from frame 1. This is also fine (and actually what the DcmCodec implementations do - they never look at the offset table). You simply start with the first fragment and "consume" fragments until one frame is decompressed. You then ignore the rest of the fragment (which might contain trailing garbage, I have seen examples of that) and start the next frame with the beginning of the next fragment.
* There is an offset table. In this case, the caller could even decompress frames in arbitrary order.
* The number of fragments equals the number of frames (plus the offset table element). In this case an arbitrary selection of frames is possible even if the offset table is empty because each frame must have at least one fragment, so in this case each frame has exactly one fragment).
* Finally the worst case: the offset table is empty, there are multiple frames and there are more fragments than frames. In this case an arbitrary selection of frames is not possible, one must decode from the first frame to the selected one. In this case the attempt to decode an arbitrary frame could simply fail with an error code, or one could in this case fall back to the current behaviour of the toolkit, which would also work, but be slow of course.

Posts: 11
Joined: Thu, 2004-11-18, 08:16

#3 Post by joyli » Thu, 2007-11-08, 09:53

whenever dcmfileformat is always "loadfile",all elements are loaded in memory.anyway,if we have a big multiframe file,my system will be crushed.

i didnot know why DICOM3.0 permit offset table can be absent?

maybe if every file has a offset table. we could get offset table and get relative frame. in memory here always has only one frame. if we dont use cache.

can anybody give me some advice ,tk can get frame that i want ,if this file has a offset table.

Marco Eichelberg
Posts: 1297
Joined: Tue, 2004-11-02, 17:22
Location: Oldenburg, Germany

#4 Post by Marco Eichelberg » Tue, 2007-11-13, 11:38

DcmFileFormat::loadFile() creates an object for each element of the DICOM dataset, but does not load everything to memory. This only happens once you try to actually access the content of each element (in the case of a compressed object, when you access each fragment within the sequence).

The problem with offset tables is that they can be empty, and even if they are present, their content may be wrong. The offset table contains the offset (in bytes) in the encoded dataset (=file) from from the start of the second fragment (which by definition has offset 0) to the start of the fragment representing the n-th frame. Based on some calculation (including the overhead for tag, VR and length for each fragment) you can identify the first and last fragment containing compressed data for a single frame, if the content of the offset table is present and correct.

Post Reply

Who is online

Users browsing this forum: Baidu [Spider], Bing [Bot] and 1 guest