Spatially sorting DICOM slices.
Harry
In order to perform interpolation (for thick slices, and also to be
able to handle inter-slice gaps), I must be able to select from a
series 'spatially consecutive' slices two at a time.
Now, rigorously speaking, I cannot spatially sort based on:
1. timestamp, because...
a modality could possibly scan neck region, followd by the leg
region and then finally jump back to abodmen.
2. position of the slice's first transmitted voxel (or, that of
any other position on the slice), because...
slices towards the very end of this series (see
http://simonsharry.blogspot.com/2007/02/spatial-sorting-of-dicom-2d-slices-in.html)
would then get (incorrectly) merged with those in the middle.
It seems, I need not spatially sort for building a non-interpolated
volume.
Has someone dealt with this before?
Any life-saver DICOM tags?
Any special/spatial (pun intended) assumptions I could make about
modalities and/or general patterns of acquisitions?
Thanks, best regards,
Harry
eric.g...@gmail.com
> Hi all,
>
> In order to perform interpolation (for thick slices, and also to be
> able to handle inter-slice gaps), I must be able to select from a
> series 'spatially consecutive' slices two at a time.
When you say you want spatially consecutive slices,
Do you mean you want pair-wise selections of sequential slices in the
series?
Or, alternatively, are you saying that in the case where the slices
near the end of the series rotate around so they are closer to the
beginning of the series, you want one of those pitched-back slices
paired with a slice earlier in the series since they are spatially
closer? I think, you mean the first alternative, but it wasn't
completely clear to me.
In any event, usually the slices/images in a series are numbered in
their logical sequence within the series
have you tried using Instance Number (0020,0013)?
Acquisition Number (0020,0012) is often included in CT slices, but
probably should not be used since the simultaneously acquired slices
from multislice scanners should all have the same acquisition number.
Harry
> When you say you want spatially consecutive slices,
> Do you mean you want pair-wise selections of sequential slices in the
> series?
Yes pair-wise sequential/neighboring, but not in acquisition timeline
nor in instance number sequence but rather spatially neighboring.
Basically, if someone were to give a jumbled up version of the slices
to an infinitely capable medical person, s/he in principle would be,
my merely visually examining the slice, able to sort them up such that
stacked up they correspond to a subset of the human body volume. And,
this would be true regardless of the time or order of their
acquisition.
So the question then is: how do you do this programmatically? A more
sophisticated version of the problem would be where there are large
spatial gaps in the series (say a few brain slices followed by a big
gap followed by leg slices).
> Or, alternatively, are you saying that in the case where the slices
> near the end of the series rotate around so they are closer to the
> beginning of the series, you want one of those pitched-back slices
> paired with a slice earlier in the series since they are spatially
> closer? I think, you mean the first alternative, but it wasn't
> completely clear to me.
Sorry, didn't quite catch it. So can only emphasize what I said above
just now.
> In any event, usually the slices/images in a series are numbered in
> their logical sequence within the series
> have you tried using Instance Number (0020,0013)?
This would be a problem if let's say the acquisition happens as
follows:
20 slices of the brain, followed by
10 slices of the knee region, followed by
200 slices of the abdominal region.
> Acquisition Number (0020,0012) is often included in CT slices, but
> probably should not be used since the simultaneously acquired slices
> from multislice scanners should all have the same acquisition number.
Ok, so won't use Acquisition Number. What's the alternative, then?
eric.g...@gmail.com
to be. You've stated that you want pairwise selections of adjacent
slices. While you can throw in the complexity of the "what if the
images were all jumbled together", the fact of the matter is they are
not so jumbled. You've also thrown in a complication of multiple
series in different anatomical locations (not shown in your wiki
diagram). The problem again could be made artificially complex by
composing an acquisition protocol where all these different anatomic
regions were acquired in a single acquisition series, but I will
assume you are dealing with a real problem and that those images are
in fact separate series.
If so, they are organized into sets (DICOM series) and are ordered
within those sets by instance number. All images in the same series
will have the same value for Series Instance UID (0020,000E). Each
series will also have a series number, but their is no guarantee of
uniqueness, and some vendors are lazy assigning duplicate values for
different series. Images within a series will be numbered with an
instance number. Sorting the images first by series UID (0020,000E)
and then by instance number (0020,0013) will separate your brain,
knee, and abdoment series into their separate sets/quences. A
secondary sort within series by instance number will give you the
ordering needed to select them pairwise from each set, with the caveat
that it is expected you're not pairing slices from different series
(implied by your pairwise/adjacency requirement).
Harry
> Seems like you're artificially making the problem harder than it has
> to be.
AFAIK, the standard nowhere explicitly says things like "the modality
shall / shall not do this and that when acquiring a series..." Thus, I
didn't know what I could / could not safely assume. Basically, like
most s/w developers, I want my code to work correctly with as many
vendor modalities as possible. Hence, I thought I'll probably ask the
group.
Thanks for taking the time to respond, will follow your advice (of not
making the problem needlessly complex), unless someone else shares a
different opinion...
Regards...
Yves Martel
The way I do it, is to compute an index for each slice. This index is
created from the slice origin (0020,0032) and "z" direction vector
(the cross product of the 2 vectors in (0020,0037). It is basically
the position of the slice along this "z" vector.
It is then fairly simple to sort the slices with this index.
Of course this will fail if the slices are not // :o)
Yves
Harry
I think the standards folks should address the issue that I've
raised... so that we developers can write more generic code, and write
it easily!
May I suggest a new "Spatial Vicinity" tag whose integer value could
be used for easily sorting up the slices?
Harry
David Clunie
If you take a look at the enhanced family of CT and MR objects,
we have added Stack ID and In-Stack Position for this purpose,
as well as Dimensions to allow the modality to explicitly
specify which is varying in space, time, contrast phase, etc.
But the bottom line for the existing single frame images is
that you just have to figure it out by detecting patterns that
allow you to partition the data ... the Series organization
and the Instance Number are not terribly useful or reliable
for any 3D work ... you need to treat all images in a frame
of reference as a large set and then factor out patterns of
commonality, e.g., parallel slices (same orientation within a
certain tolerance factor), same spatial location (within a
tolerance factor), same acquisition (by number or time),
different reconstruction kernel or slice thickness etc. Then
one has to sort along the appropriate axis as Yves suggests
(e.g., normal to the orientation for the spatial dimension,
which ever attribute appears to represent small changes in
time (e.g., successive slices) versus large increments in
time (e.g., separate contrast phases), etc.
This is a non-trivial problem, which is why it is hard to build
a completely generic 3D/4D workstation, and one of the primary
reasons why the new features in enhanced CT and MR can provide
benefit by conveying the modality's "intent", something that
is lost in the older single frame objects.
David