Fast non-pixel data from PACS - DICOM

This is a discussion on Fast non-pixel data from PACS - DICOM ; I'm part of a team that is working on implementing a workstation with support for DICOM hanging protocols and we'd like to support dynamic loading, ie the user can work with the application while data is loading. Ideally we'd like ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: Fast non-pixel data from PACS

  1. Fast non-pixel data from PACS

    I'm part of a team that is working on implementing a workstation with
    support for DICOM hanging protocols and we'd like to support dynamic
    loading, ie the user can work with the application while data is
    loading. Ideally we'd like to be able to fetch all the non-pixel data
    first and then only load the pixel-data dynamically. The idea would be
    that fetching the non-pixel data would be very fast and would allow us
    to go through all the stages in the DICOM hanging protocol pipeline
    including display set filtering and sorting, which would mean that we could

    * fetch the pixel-data we need to render right now first,
    * avoid image reshuffling as images arrive,
    * avoid loading pixel data that never make it through display set filtering,
    * support DICOM Display Set Adaptive Layout elegantly - it's not very
    nice to have the layout changed when all the images have arrived,
    * and many other things.

    Is there a way to be able to get all the non-pixel data fast in a
    DICOM-conformant way? As far as I can tell no, since C-MOVE will fetch
    everything and very little is guaranteed about what attributes can be
    returned by C-FIND.

    How about proprietary extensions? I'm only familiar with one particular
    PACS, but I understand it is common for PACS' to support proprietary
    extensions. Could someone with general experience with different PACS
    vendors tell me whether extensions exist that provide fast and efficient
    access to non-pixel data?

    Is this something that could be addressed by future extensions to the
    DICOM specification?

    Best regards,

    Thomas Sondergaard

  2. Re: Fast non-pixel data from PACS

    Thomas Sondergaard wrote:

    > Is this something that could be addressed by future extensions to the
    > DICOM specification?


    There is already work going on. See Supplement 106 (JPEG 2000 Interactive
    Protocol): ftp://medical.nema.org/medical/dicom.../sup106_pc.pdf

    Regards,
    Joerg Riesmeier

  3. Re: Fast non-pixel data from PACS

    Hi Thomas

    Thomas Sondergaard wrote:

    > I'm part of a team that is working on implementing a workstation with
    > support for DICOM hanging protocols and we'd like to support dynamic
    > loading, ie the user can work with the application while data is
    > loading. Ideally we'd like to be able to fetch all the non-pixel data
    > first and then only load the pixel-data dynamically. The idea would be
    > that fetching the non-pixel data would be very fast and would allow us
    > to go through all the stages in the DICOM hanging protocol pipeline
    > including display set filtering and sorting, which would mean that we could
    >
    > * fetch the pixel-data we need to render right now first,
    > * avoid image reshuffling as images arrive,
    > * avoid loading pixel data that never make it through display set
    > filtering,
    > * support DICOM Display Set Adaptive Layout elegantly - it's not very
    > nice to have the layout changed when all the images have arrived,
    > * and many other things.
    >
    > Is there a way to be able to get all the non-pixel data fast in a
    > DICOM-conformant way? As far as I can tell no, since C-MOVE will fetch
    > everything and very little is guaranteed about what attributes can be
    > returned by C-FIND.
    >
    > How about proprietary extensions? I'm only familiar with one particular
    > PACS, but I understand it is common for PACS' to support proprietary
    > extensions. Could someone with general experience with different PACS
    > vendors tell me whether extensions exist that provide fast and efficient
    > access to non-pixel data?
    >
    > Is this something that could be addressed by future extensions to the
    > DICOM specification?
    >
    > Best regards,
    >
    > Thomas Sondergaard


    Interesting use case.

    The JPIP Supplement 106 approach that Joerg mentioned is perhaps
    the tidiest solution, in that it proposes a transfer syntax
    that separates the transmission of the non-pixel data attributes
    using a normal C-STORE, and the pixel data which is retrieved
    on a separate connection using JPIP requests.

    Your use case suggests that there is actually a role for this
    transfer syntax in which, perhaps, the JPIP requests never
    actually transpire, and that the non-pixel data attributes
    are retrieved, and then the entire image object with all
    attributes (non-pixel and pixel data) is retrieved with
    a normal C-STORE, and JPIP is not used at all, or some other
    mechanism is used (e.g. WADO).

    Perhaps we should rewrite the proposed Sup 106 to actually
    provide for two separate transfer syntaxes, one of which is
    for the "non-pixel data attributes via C-STORE" only, and
    the other of which is for the JPIP URL. Or alternatively,
    have a sort of "parent class" of transfer syntax that is a
    "referenced pixel data transfer syntax" in which the pixel
    data reference sequence is unconstrained and possibly empty,
    and the JPIP-specific transfer syntax is the same but with
    an enumerated value for pixel data reference type and a
    mandatory reference.

    I.e., many folks might not want to use JPIP, but would want to
    get the non-pixel data attributes for other reasons.

    Problems with retrieving "all" of the non-pixel data attributes
    is that some may be very big - overlays and LUTs and some bulk
    data in private attributes come to mind; still, likely not as
    big as with the pixel data, except in some pathological cases.

    In addition to Sup 106, four other approaches using the existing
    standard come to mind:

    - use of C-FIND with an SCP that returns a lot more of the attributes
    than is normal in the IMAGE level response - requires an SCP that
    does this - probably impractical since query responses are usually
    generated from the database and most databases don't have the level
    of detail you want - it would be nice to have a C-FIND SCP design
    that when return keys were requested, looked into the objects if
    the keys weren't in the database, but that is not a design commonly
    encountered and would have a significant performance impact (imagine
    a C-FIND SCP that could learn and adapt its database, based on queries
    encountered, but I digress)

    - use of the new multi-frame CT and MR (and soon XA and PET) image
    objects, so that all of the information about all of the frames
    arrives before the pixel data starts to arrive - requires support
    of the new enhanced objects, and processing whilst the large
    object is still being received - using the multi-frame objects
    plus a C-FIND to fetch the functional group sequences might also
    be sufficient

    - use of asynchronous operations and/or multiple associations so
    that multiple objects are retrieved simultaneously - requires an
    SCP that supports this, and probably impractical for a lot of
    images (frames)

    - perhaps the most practical but limited, pre-fetching everything
    (attributes and pixel data) to the workstation based on the user's
    worklist - i.e. if they are looking at worklist task n now, pre-fetch
    n+1 - requires that there be a worklist (i.e. that the user is not
    fetching images randomly, and that the SCP supports GP-WL) - by no
    means a general solution, but helpful for many reasons when worklists
    are in use

    If I had to implement this today, I would probably use C-FIND and
    try and convince SCPs to put a richer range of return keys in the
    C-FIND response. That way, you get no more than you ask for, which
    is the primary problem that I see with the "all non-pixel data
    attribute C-STORE" approach, for this use case. But I would be
    sorely tempted to implement a private Sup 106 like transfer
    syntax.

    David

    PS. Talking about this in theory is one thing, but it would be
    interesting to experiment with actual performance gains (especially
    with large numbers of single frame objects) to determine whether
    or not the transfer of the pixel data really is a performance hit;
    i.e., whether the extraction, marshaling, transmission, reception
    and processing of all the non-pixel data attributes at both ends
    actually takes more time than the transmission itself. I suggest
    that this might be an issue, since some of the performance gains
    we have seen with single versus multiframe CT and MR images greatly
    exceed what would be expected from predications based on the size
    and packaging of the objects, implying that many systems handle
    single frame objects extremely inefficiently, regardless of the
    bulk of the pixel data itself.

    Similarly, generating and parsing a very large number of large
    C-FIND responses can be an issue in itself in terms of performance.

  4. Re: Fast non-pixel data from PACS

    Hi David,

    The change to Sup 106 that you suggest sounds very interesting and
    reasonable to me, but I don't have enough experience to know whether
    such a change would be generally useful, or useful only for us. Would
    such a rewrite add complexity to the proposed Sup 106 or would it
    perhaps ortogonalize the proposal and make it cleaner?

    I'm a PACS newbie and know little about their implementation, but
    concerning the potential win of upfront transmission of non-pixel data I
    suppose it depends on the PACS implementation. If a PACS has an
    optimized path for delivering all non-pixel data it could save a good
    deal of disk and network I/O and perform the transmission quite
    efficiently. On the other hand a non-optimized PACS would probably have
    to do more disk I/O and work harder to perform the non-pixel data
    extraction. On the workstation side, receiving the non-pixel data
    upfront has many benefits (a few are listed in my original posting) when
    hanging protocols are involved including performance benefits - at least
    from where I'm standing.

    Thanks for your suggestions concerning how to approach this within the
    current standard. I've presented them to my coworkers so we have
    something to discuss.

    Best regards,

    Thomas Sondergaard

  5. Re: Fast non-pixel data from PACS

    David Clunie wrote:
    > Perhaps we should rewrite the proposed Sup 106 to actually
    > provide for two separate transfer syntaxes, one of which is
    > for the "non-pixel data attributes via C-STORE" only, and
    > the other of which is for the JPIP URL. Or alternatively,
    > have a sort of "parent class" of transfer syntax that is a
    > "referenced pixel data transfer syntax" in which the pixel
    > data reference sequence is unconstrained and possibly empty,
    > and the JPIP-specific transfer syntax is the same but with
    > an enumerated value for pixel data reference type and a
    > mandatory reference.


    Maybe this would also be a part of a solution for a problem
    that I forsee for the Enhanced MR & CT image types. It is not
    certain that a DICOM application need the whole multi-frame
    object, which could be GigaBytes in size. I would be nice if
    it would be possible to first fetch the non-pixel data
    attributes, then fetch specific frames from the multi-frame
    image. This requires enriching the C-MOVE service with the
    ability to specify frame numbers.


+ Reply to Thread