1 / 10

WADO evolution

WADO evolution. Multipart ? JPIP ? Or Web Services? With help from Emmanuel Cordonnier (ETIAM) - Thanks to him. Why a WADO evolution ?. Lot of request to support multipart for series/study retrieve Some would like to see WADO supporting JPIP (part of JPEG 2000). Multipart (1). IHE XDS

nicole-cash
Download Presentation

WADO evolution

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. WADO evolution Multipart ? JPIP ? Or Web Services? With help from Emmanuel Cordonnier (ETIAM) - Thanks to him

  2. Why a WADO evolution ? • Lot of request to support multipart for series/study retrieve • Some would like to see WADO supporting JPIP (part of JPEG 2000)

  3. Multipart (1) • IHE XDS • Multipart is neither understood nor well accepted by the vendors even it’s a part of XDS (the same document could be  ”single-file" or "multi-files" and in this case "multipart“). • The "XML guys" would like to do everything embedded into XML. They think that a complex document is a big file (unique XML) with a lot of binary documents inside. • As example given, scanned PDF documents converted as CDA, the “full XML” approach was chosen vs. multipart.

  4. Multipart (2) • Retrieving several images from a series/study could be done with two processes: • Using (present HTTP GET based) WADO and KOS • the server publishes a "manifest" (DICOM Key Object Selection) get by the “web client" (as DICOM using WADO) • the client builds queries using WADO (for DICOM objects or Jpeg images)from the references to DICOM objects contained in KOS, image by image or as a ”set" to display it together. This approach was retained for IHE XDS-I profile. • KOS retrieval as HTML (XML?) using WADO would allow to have WADO links directly accessible but image per image. • Evolution of WADO to Web Services • The communication is no longer in HTTP Get but uses HTTP POST + SOAP that means web services, using the MTOM/XOP as transport mode for the answer. • It is too early to define it, but in one or two years, following the approach used in IHE XDS

  5. Multipart (3) • The initially considered solution (an unique UID possible and retrieval of a ”set of images" using multipart - that means all in DICOM or all in JPEG) could be rejected by the vendors because actual browsers do not support the multipart. It may change in the future. • Despite the fact that with IE, if one put a multipart - related or mixed - with several jpeg images inside using the right file extension, one obtains the images on line (like digital photos sent by mail).

  6. JPIP (1) • The JPIP large supremacy (vs. multiple exchange of JPEG images) in the present implementation context is not yet technically proved, despite several trials. • JPIP is based on JPEG 2000 (vs. JPEG). • The place where JPIP use is particularly justified is pathology WSI (100.000 x 50.000 images to 4 Go compressed) and DICOM has not selected the JPIP approach (vs. JPEG tiles), yet.

  7. JPIP (2) • Lot of vendors are implementing ”gizmos” like "web + JPIP + jpeg2000", most are doing it using proprietary stuffs without really using the “pure” DICOM Jpeg 2000 format. • One of the most important differences between jpeg and jpeg 2000 is that it exists basic jpeg codec on client PC or Mac but not for jpeg 2000 and so the codec shall be incorporated in the workstation software. It’s the same for JPIP.

  8. JPIP (3) • WADO allows to do progressive display in jpeg using an "intelligent" client (like JPIP) controlling the image size and the displayed region. • The most important difference vs. JPIP is that the entire displayed image is send when JPIP allows to send only the difference… IF THE SERVER KEEP TRACK OF THE "CONTEXT" for this specific terminal.

  9. JPIP (4) • WADO allows also to retrieve the DICOM images and to choose the transfer syntax. • So it is possible to do it for a WADO+JPIP: • Retrieve the image in DICOM (contentType=application%2Fdicom&transferSyntax=1.2.840.10008.1.2.4.94 or 95). • Open the JPIP session on the basis of information read in the "image" containing the JPIP URL in place of pixels. • So it is possible to do WADO+JPIP without any WADO specs evolution

  10. Recommendation • The DICOM and ISO joint group can publish an "implementation guide" on the subject but there is not clear reason to revisit the ISO 17432 standard, yet. • Add the multipart option now can be quite controversial and put “trouble” in WADO which is more and more adopted by vendors. • At the opposite, a WADO evolution could be considered next year or in 2 or 3 years • implementing the web services • including the frequently requested function for whole series or study retrieval.

More Related