How to break XA multi Frame Image

[Akshaybar Kumar Singh]

Hello All,

In case of XA Multi frame, each Image is treated as different series while using on modality. But seriesInstanceUID is available in dicom file same for all images.

I have following query & requesting for some suggestion on the same.

1) How modality is treating, each image as different series?

2) Is there any tag from which modality consider each images as different series?

3) How to break this multi frame image, so that each images creates its own seriesInstanceUID as per functionality in modality even seriesInstanceUID is available in dicom file same for all images?

Please reply on the same.

Thanks & Regards
Akshay

[David Clunie]

Hi Akshay

The DICOM model is essentially a hierarchy of:

Patient>Study>Series>Image>Frame

As you know, each of these "entities" has its unique key to distinguish
one from the other (Patient ID, Study Instance UID, Series Instance
UID, and the implicit frame number).

However, since sometimes images are single frame and sometimes
multi-frame, even within the same modality type, it can be a
challenge to figure out how best to convey this to the user.

One challenging scenario is a single series that contains a
mixture of single and multi-frame objects, and the user does
not expect these to be "combined" in the user interface.

Another user expectation is that a set of "frames" will be
treated appropriately (as a set that can be scrolled or played
as a cine loop), regardless of whether they are a bunch of
single frame images in a series, or the same frames encoded
in one multi-frame instance (e.g., the "legacy" CT/MR/PET
format with one slice per instance versus the "enhanced"
multi-frame CT/MR/PET with all frames in one slice).

To hide the difference between multiple single frames and
single multi-frame encoding, in a revision to the IHE Basic
Image Review (BIR) profile, we described the concept of a
"FrameSet" as a user facing navigational entity. See:

http://www.ihe.net/Technical_Framework/upload/IHE_RAD_Suppl_BIR.pdf

In particular see Appendix F that contains some examples, and
the rules for defining a Frame Set from:

"Each DICOM image instance is a separate FrameSet, with two exceptions:

- a Series of only single frame instances comprises a single FrameSet

- the combined frames of a Concatenation comprise a single FrameSet
(if Concatenations are supported, which they are not required to be)

This means that when a Series contains a mixture of single frame and
multi-frame images, in order to preserve sequence of images within
a Series:

- each successive single frame image will be a separate FrameSet
consisting of one frame

- each multi-frame image will be a separate FrameSet (except for
combined images of a Concatenation, if supported)

Furthermore, there will never be fewer FrameSets than Series (i.e.,
Series will not be combined)."

Note the last rule; sometimes it is appropriate and practical to
combine series (e.g., to produce a whole volume when there are
separate chest and abdo/pelvis CT series), but that requires more
analysis of the geometry and timing of all the frames in the
study.

The BIR profile is probably not detailed enough, in that it does
not consider the size (Rows and Columns) of images, since combining
different size images into a single FrameSet does not always (ever?)
make sense.

You may be interested in some of my experiments with extracting
FrameSets; see com.pixelmed.dicom.FrameSet and SetOfFrameSets
and an example of its use in MultiFrameImageFactory. It is high
time I factored out and parametrized the hard-coded rules in
there, but it may suffice as an example.

Anyhow, to get back to your question, in the case of XA, the same
principles apply, i.e., each "run" that is encoded as a multi-frame
image can be treated as a single FrameSet, and the actual (arbitrary)
organization into "series" completely ignored if there are multiple
multi-frame images in each series (other than to annotate the
displayed frames with the appropriate series number and other
series-level attributes).

Not that this approach does not "change" the Series Instance UID of
each multi-frame image, but "conceptually" each one can be considered
as being in each own "pseudo-series". That said, if it is simpler
for your implementation to actually reassign each of these to a
separate new series with a new Series Instance UID then you can
certainly do that, but it would be pretty confusing if you persisted
these and there were two copies of the study floating around, one
with the modality-supplied Series Instance UIDs, and another with
your replacement Series Instance UIDs.

Admittedly probably no more confusing than the conversion of single
to multiframe objects that is described in Sup 157, but that is
why a whole lot of behavior is defined in that document.

David

PS. The standard does not define any particular use of the series
(except for some restrictions about the same equipment and
modality), so the acquisition modality is free to use the
series organization as it sees fit (effectively or not at all).

PPS. In the Enhanced family of objects the hierarchy is sometimes
extended to be:

Patient>Study>Series>Concatenation>Image>Frame

but that is probably not relevant to your case, and in any case,
the "concatenation" should be hidden from the view of the user
(all instances comprising the concatenation treated as if they
were combined).

PPPS. Though the BIR FrameSet approach provides a solution to the
problem of what to display and scroll/cine in a single viewport,
and what thumbnail icons to display (one per FrameSet rather than
Series), it does not describe on what a hierarchical (tree)
browser should look like, and whether the FrameSet should replace
the Series as a node in a tree, or be subordinate to it; either
choice is probably reasonable, but the latter exposes a bit too
much of the (arbitrary) DICOM encoding to the user and the former
is probably more friendly (and more consistent with the icons
and scrolling behavior).

Some thought is also required to provide a "label" for a FrameSet,
since in a Series:FrameSet 1:1 case, the Series Number and Series
Description and Series Date would do, and in a series with one
multi-frame image only, the Instance Number, Image Comments and
Content Date would do, but when there is more than one FrameSet
per Series and more than one Image per FrameSet, one has to get
creative.

PPPPS. In an ideal world, hanging protocol engines would also
support the FrameSet concept such that both the rules for
constructing a FrameSet could be made scenario-specific as
well as the rules for displaying the FrameSets once identified.
E.g., a traditional 4 view screening Mammo might consist of two
or four series with two or one images per series respectively,
yet be all the same size, yet one would want to display them
in separate view ports, whereas it might be a user preference
as to whether to display 4 single frame XA or XRF exposures
in one viewport or in separate ones, or pair of anterior and
posterior planar whole body NM bone scan images encoded as
a two-frame multiframe image in the same viewport or separate
viewports as other planar images in the same series or study.
Folks who want to use tiling in per-FrameSet viewports face
more challenges.