Hello All,

I have read all the group discussions going back to 1998 with regards to zero-length Basic Offset Tables and I am still confused about one particular case.

Here is the condition:
1. Multi-frame PixelData that has a valid zero-length Basic Offset table within the first fragment.
2. N-number of additional well formed fragments.
3. The DICOM standard rule that essentially states that a frame can span fragments BUT only one frames data can be present in a given fragment.

The questions:
1. Is this condition valid?
2. If so, how does one determine the start and end of each frames data?

I would be easy if there was an additional rule that stated that under this condition, each frame SHALL occupy only one a single fragment but I'm almost certain that this is NOT what the standard states.

Thanks for any answers!

Dave

This is a valid scenario for those transfer syntaxes that encode each frame independently (i.e., not MPEG family) - frames may be fragmented regardless of whether there is a BOT or not.

The short answer is that the recipient has to walk through the Pixel Data Items (using their fixed length) and build its own "offset table".

Obviously if the number of items after the (empty) BOT item is == the value of Number of Frames, then there is one frame per fragment, and the offsets to each fragment == the offsets to each frame.

If the number of items after the (empty) BOT item is > the value of Number of Frames, then one or more frames are fragmented, so one has to figure out which fragments belong to which frame, and doing that is transfer syntax dependent.

The general answer is to decode each frame using as many fragments as necessary to complete the frame, but that is a potentially expensive operation. For JPEG marker segment schemes (including baseline JPEG, lossless JPEG, JPEG-LS and J2K), one can cheat and walk back from the end of each fragment looking for EOI markers (allowing for permitted trailing padding), which may be faster.

David

On Wednesday, April 5, 2023 at 12:59:11 PM UTC-4, David Vaccaro wrote:
> Hello All,
>
> I have read all the group discussions going back to 1998 with regards to zero-length Basic Offset Tables and I am still confused about one particular case.
>
> Here is the condition:
> 1. Multi-frame PixelData that has a valid zero-length Basic Offset table within the first fragment.
> 2. N-number of additional well formed fragments.
> 3. The DICOM standard rule that essentially states that a frame can span fragments BUT only one frames data can be present in a given fragment.
>
> The questions:
> 1. Is this condition valid?
> 2. If so, how does one determine the start and end of each frames data?
>
> I would be easy if there was an additional rule that stated that under this condition, each frame SHALL occupy only one a single fragment but I'm almost certain that this is NOT what the standard states.
>
> Thanks for any answers!
>
> Dave

On Wednesday, April 5, 2023 at 11:39:09 PM UTC-4, David Clunie wrote:
> This is a valid scenario for those transfer syntaxes that encode each frame independently (i.e., not MPEG family) - frames may be fragmented regardless of whether there is a BOT or not.
>
> The short answer is that the recipient has to walk through the Pixel Data Items (using their fixed length) and build its own "offset table".
>
> Obviously if the number of items after the (empty) BOT item is == the value of Number of Frames, then there is one frame per fragment, and the offsets to each fragment == the offsets to each frame.
>
> If the number of items after the (empty) BOT item is > the value of Number of Frames, then one or more frames are fragmented, so one has to figure out which fragments belong to which frame, and doing that is transfer syntax dependent.
>
> The general answer is to decode each frame using as many fragments as necessary to complete the frame, but that is a potentially expensive operation.. For JPEG marker segment schemes (including baseline JPEG, lossless JPEG, JPEG-LS and J2K), one can cheat and walk back from the end of each fragment looking for EOI markers (allowing for permitted trailing padding), which may be faster.
>
> David
> On Wednesday, April 5, 2023 at 12:59:11 PM UTC-4, David Vaccaro wrote:
> > Hello All,
> >
> > I have read all the group discussions going back to 1998 with regards to zero-length Basic Offset Tables and I am still confused about one particular case.
> >
> > Here is the condition:
> > 1. Multi-frame PixelData that has a valid zero-length Basic Offset table within the first fragment.
> > 2. N-number of additional well formed fragments.
> > 3. The DICOM standard rule that essentially states that a frame can span fragments BUT only one frames data can be present in a given fragment.
> >
> > The questions:
> > 1. Is this condition valid?
> > 2. If so, how does one determine the start and end of each frames data?
> >
> > I would be easy if there was an additional rule that stated that under this condition, each frame SHALL occupy only one a single fragment but I'm almost certain that this is NOT what the standard states.
> >
> > Thanks for any answers!
> >
> > Dave

Great.. Thanks for the info, David. This makes perfect sense.

The below is stated for the benefit of others who might find themselves in the same pickle:

I was getting stuck wanting to completely be able to establish the list of offsets by ONLY using the overall length of the PixelData and the list of parsed segments (Item Tag/Item Length/Seq Del Tag) and not considering the Number of Frames value or the particular image encoding or anything else for that matter.

The rule for parsing the PixelData stream segments is universal and simple as is the rule for parsing and utilizing a non-zero length Basic Offset Table (with a simple set of 4-byte offsets into the stream).

BUT when the Basic Offset Table is zero-length, then the "Number of Frames" tag value is essential to determining IF each frame is occupying its own segment (simple happy path) OR if one or more frames actually occupy more than one segment. (valid but a bit more work)

FURTHER, when parsing a given frame (from one or more segments), the final segment containing the end of that frame data may be determined by either (1) using the cheat of looking back from the end of each segment for an EOI marker (if the encoding format utilizes one) OR (2) just feeding the segments of data to the decoder until it indicates that the frame is complete.

Dave