Spatially sorting DICOM slices. - DICOM

This is a discussion on Spatially sorting DICOM slices. - DICOM ; 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. Now, rigorously speaking, I cannot ...

+ Reply to Thread
Results 1 to 8 of 8

Thread: Spatially sorting DICOM slices.

  1. Spatially sorting DICOM slices.

    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.

    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...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


  2. Re: Spatially sorting DICOM slices.

    On Feb 19, 2:25 am, "Harry" wrote:
    > 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.


  3. Re: Spatially sorting DICOM slices.

    On Feb 21, 3:36 am, eric.good...@gmail.com wrote:

    > 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?


  4. Re: Spatially sorting DICOM slices.

    Seems like you're artificially making the problem harder than it has
    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).


  5. Re: Spatially sorting DICOM slices.

    On Feb 21, 6:46 pm, eric.good...@gmail.com wrote:
    > 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...


  6. Re: Spatially sorting DICOM slices.

    Bonjour Harry,

    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 // )

    Yves


    On 18 Feb 2007 23:25:19 -0800, "Harry" wrote:

    >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.
    >
    >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...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



  7. Re: Spatially sorting DICOM slices.

    Bonjour Yves! Thanks for responding.

    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


  8. Re: Spatially sorting DICOM slices.

    Hi Harry

    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

    Harry wrote:
    > Bonjour Yves! Thanks for responding.
    >
    > 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
    >


+ Reply to Thread